F-Secure Sicherheitsupdates für 7-Zip-Schwachstellen

In mehreren Sicherheitsprodukten des Anbieters F-Secure wurden in älteren Versionen Sicherheitslücken gefunden. Es geht um Memory Corruption Error-Schwachstellen in fehlerhaften 7-ZIP-Bibliotheken, die eine Remote Code-Ausführung ermöglichen und als kritisch eingestuft werden. Der Hersteller hat aber bereits Updates bereitgestellt und diese per Auto-Update verteilt.


Anzeige

Setzt jemand von euch Antivirus- bzw. Sicherheitsprodukte des Anbieters F-Secure ein? Dann solltet ihr überprüfen, ob diese automatisch aktualisiert wurden. Andernfalls sind die Produkte zu aktualisieren. Das betrifft sowohl die Home- als auch die Enterprise-Varianten unter Windows (Linux und macOS scheinen nicht betroffen).

Altes Problem: Der 7-Zip-Packer

Ich hatte hier im Blog ja häufiger über Probleme mit Packbibliotheken in Bezug auf Sicherheitslücken berichtet (siehe Link-Liste am Artikelende). F-Secure setzt in seinen Produkten auf Softwarebibliotheken von 7-Zip zum Entpacken von Archiven. Genau in der 7-Zip-Dateiarchivierungssoftware, mit der F-Secure Archive dekomprimiert, nach Bedrohungen durchsucht und die Originaldatei ggf. neu packt, steckt wohl die Schwachstelle in F-Secure-Produkten.

Durch diverse Bugs in den 7-Zip-Bibliotheken konnten den Entpackern präparierte Archivdateien unterschoben werden. Diese provozierten einen Speicherüberlauf (Memory Corruption Error), der zur Remote Code Execution ausgenutzt werden konnte. Die kritischen Sicherheitslücken CVE-2018-5996 und CVE-2017-17969 waren bereits im Januar 2018 in den 7-Zip-Routinen gefunden und im Landave-Blog veröffentlicht worden.

Ich hatte Ende Januar 2018 im Blog-Beitrag 7-Zip mit Sicherheitslücken – updaten! darüber berichtet. Damals gab es bereits (auch in den Kommentaren) den Hinweis, dass diese Routinen auch in vielen anderen Produkten steckten. Im Mai 2018 gab es Updates von 7-Zip, um dieser Memory Corruption-Sicherheitslücken zu schließen (siehe mein Blog-Beitrag 7-ZIP Version 18.05 veröffentlicht).


Anzeige

Der Betreiber des Landave-Blogs hat sich, kurz nachdem er die Sicherheitslücke im Januar 2018 entdeckte, auch die Produkte diverser Antivirus-Hersteller vorgenommen, da diese oft 7-Zip-Bibliotheken einsetzen. Dabei stieß er bei F-Secure auf die fehlerhaften Funktionen und hat den Hersteller informiert.

In einem Tweet wies landave letzte Woche darauf hin, dass F-Secure nachgebessert habe und ergänzte auch seinen Blog-Beitrag um den entsprechenden Satz – Bleeping Computer hat diese Details hier recherchiert.

Betroffene F-Secure-Produkte und Updates

F-Secure hat dann am Anfang Juni 2018 das Sicherheitsadvisory FSC-2018-2: Remote Code Execution in F-Secure Windows Endpoint Protection Products veröffentlicht und am 7. Juni 2018 nochmals aktualisiert. Betroffen von den, als kritisch eingestuften, Schwachstellen sind folgende F-Secure-Produkte.

Consumer Produkte: 

  • F-Secure SAFE for Windows

Unternehmens Produkte:

  • F-Secure Client Security
  • F-Secure Client Security Premium
  • F-Secure Server Security
  • F-Secure Server Security Premium 
  • F-Secure PSB Server Security
  • F-Secure Email and Server Security
  • F-Secure Email and Server Security Premium
  • F-Secure PSB Email and Server Security
  • F-Secure PSB Workstation Security
  • F-Secure Computer Protection
  • F-Secure Computer Protection Premium

Es sind wohl ausschließlich Produkte für Windows betroffenen. Nicht aktualisierte F-Secure-Produkte führen dazu, dass ein Angreifer über eine präparierte Datei die volle Kontrolle über das System übernehmen kann. Laut F-Secure sind bisher keine Angriffe in der freien Wildbahn beobachtet worden.

F-Secure hat inzwischen Updates für die jeweiligen Produkte bereitgestellt. Details, welche Versionen wann aktualisiert wurden, finden sich im Security Advisory. Die Verteilung erfolgt standardmäßig über die automatische Update-Funktion der Produkte, sofern diese nicht deaktiviert ist.

Meine Gedanken zum 'Schwein gehabt Schutz'

Wenn ich mir dieses Thema so anschaue, drängt sich mir der Verdacht auf, dass die aktuell verfügbare Software, egal von welchem Hersteller, sicherheitstechnisch löchrig wie ein Schweizer Käse sein könnte – wir kennen die Sicherheitslücken schlicht noch nicht. Hier im Blog berichte ich ja häufiger über Sicherheitsprobleme oder es werden entsprechende Kommentare nachgetragen. Das einzige, was uns bisher vor größeren Problemen bewahrt hat, ist schlicht der 'Schwein gehabt Schutz'. Es wird eine Zero-Day-Schwachstelle entdeckt und gefixt, bevor jemand auf die Idee gekommen ist, einen Angriff zu fahren.

Was ich (aus Zeitmangel) zum Beispiel nicht untersucht habe: Wie läuft der Update-Mechanismus bei F-Secure. Werden .msi-Dateien zur Installation verwendet, oder entpackt der Auto-Updater ein Archiv in ein temp-Verzeichnis, um das Ganze zu entpacken. Dann käme ja das im Beitrag Microsoft und die Office 20xx-Sicherheitslücke in ose.exe erwähnte DLL-Hijacking-Szenario zum Tragen. Und der Auto-Update-Prozess läuft ja unter dem Sicherheitskontext des Systems. Es gibt wohl, nach meinen Recherchen, die Möglichkeit für Administratoren, Updates netzwerkweit über .msi-Dateien bereitzustellen. Dann müssen die MSI-Installer aber von den Administratoren erstellt werden (siehe hier). Ich habe mal eine diesbezügliche Anfrage an F-Secure mit der Bitte um Informationen gestellt und werde eine Antwort, sofern ich diese bekomme, hier nachtragen.

Ähnliche Artikel:
7-ZIP Version 18.05 veröffentlicht
Software-Updates: VLC, 7-Zip, LibreOffice
Warnung: Auf 7-Zip verzichten
7-Zip mit Sicherheitslücken – updaten!
Microsoft und die Office 20xx-Sicherheitslücke in ose.exe


Anzeige

Dieser Beitrag wurde unter Sicherheit, Update, Virenschutz abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

11 Antworten zu F-Secure Sicherheitsupdates für 7-Zip-Schwachstellen

  1. Stefan Kanthak sagt:

    Hast Du überprüft, ob F-Secure die Updates über einen sicheren Transportweg holt, also HTTPS verwendet?
    Oder ob sie wie (nicht nur) Kasperlesky HTTP verwenden?
    Siehe http://seclists.org/fulldisclosure/2017/Sep/25
    Wie gewissenhaft Hersteller wie Kasperlesky arbeiten kannst Du auch hieran sehen: http://seclists.org/fulldisclosure/2016/Jan/1
    20 Monate nachdem ich ihnen ihre Anfängerfehler in ihren einzelnen "Cleaner"-Programmen aufgezeigt habe haben sie dieselben Anfängerfehler in (mindestens) einem ihrer anderen Produkte nicht behoben.

  2. Martin Feuerstein sagt:

    MSI-Installer können entweder die Dateien in sich selbst gepackt mitbringen (CAB-Format?) oder aber auch aus einem CAB-Archiv beziehen, hier ist die Sicherheit eher auf den Windows-Installer-Dienst zurückgestellt, was der mit manipulierten Archiven anstellt. Generell aber gut, dass die ausgeführte Datei (msiexec.exe) im System32 vorliegen muss und nicht etwa aus dem TEMP oder durch eine andere Drittanwendung ausgeführt wird.

    MSI-Pakete (Installer) oder auch MSP-Pakete (Patches) kann auch der Hersteller bereitstellen, gelegentlich liefert der Hersteller eine Software (Deployment Tool) mit, um angepasste Installer zu erstellen.

    OT: Was man mit MSI-Paketen alles für Schindluder treiben kann, insbesondere bei Adobe (Flash Player) und Oracle (Java)… Da werden die normalen EXE-Installer einfach mal gekapselt, was nicht nur bei Updates dazu führt, dass bei "Aktualisierung" (per Gruppenrichtlinie) eigentlich eine eigenständige Neuinstallation ausgeführt wird und die alte Version installiert bleibt.

    • Stefan Kanthak sagt:

      Selbstverständlich verwenden .MSI intern oder extern .CAB: es ist das NATIVE Archivformat von Windows.
      Und genau wie .INF bzw. das SetupAPI (nur darüber installiert Windows Treiber; siehe WQHL) muss MSIExec.exe die .CAB NICHT in ein %TEMP%-Verzeichnis entpacken, sondern greift direkt auf die .CAB zu.

      Nicht nur bei Adobe oder Oracle frickeln Volltrottel solche Pseudo-MSI: Google und Intel machen solchen hanebüchenen Blödsinn ebenfalls.

      Die typischen Mißbraucher von Wix (allen voran Microsoft) oder InstallShield etc. machen den Fehler andersrum: die verpacken eigentlich sichere .MSI in unsicheren Selbst-Extraktoren.
      Mozilla (als weiteres abschreckendes Beispiel) verpackt unsichere NSIS-Installer in unsicherem selbst-extrahierenden 7zip Schrott.

      • Martin Feuerstein sagt:

        "die verpacken eigentlich sichere .MSI in unsicheren Selbst-Extraktoren"
        … nennt sich Bootstrapper und enthält neben dem MSI (oder den MSIs, ab VC++ 2012 Runtime sind z. B. in einer EXE 2 MSI enthalten, Minimal und Additional Runtime) auch ggf. andere Runtimes, wie etwa .NET, C++, VSTO, was auch immer.
        Ja, die Bootstrapper und ihre Ableger sind vielleicht nicht des Admins liebstes Kind, für Otto-Normal ist es aber einfacher, wenn eine EXE alles mögliche extrahiert und nacheinander installiert.
        Fürs Geschäft ist es wünschenswert, wenn sich die enthaltenen MSI-Installer möglichst einfach extrahieren lassen – MS macht es einem da aber nicht leicht (sh. VC++- Runtime ab 2012 – einfaches Extrahieren nicht möglich, nach der Installation finden sich die MSIs in c:\Programdata\Package Cache).

        • Stefan Kanthak sagt:

          Bootstrapper sind VÖLLIG überflüssiger Schrott, vor allem da dieses Zeux typischerweise trivial auszunutzende Sicherheitslücken hat!
          1. ich habe bisher noch keinen gefunden, der nicht auf mindestens einer Windows-Version keine DLL aus seinem "application directory" geladen hat. Otto Normalmissbraucher lädt sich diesen Schrott aus dem Netz und speichert ihn im "Downloads"-Verzeichnis … wo jeder die typischerweise geladenen DLLs platzieren kann (zur Not per "drive-by" Download).
          Da Bootstrapper typischerweise administrative Rechte anfordern führt das direkt zur vollständigen Kompromittierung des Systems.
          2. läuft ein solcher Bootstrapper aber ohne administrative Rechte, dann kann der die ausgepackten Dateien nicht vor dem Schreibzugriff durch den unprivilegierten Otto Normalanwender schützen: dieser, oder ein unter dessen Benutzerkonto unprivilegiert laufender Schädling kann die ausgepackten Dateien nach Belieben modifizieren, bevor sie von MSIExec.exe oder einem anderen, mit erhöhten Rechten laufenden Programm verarbeitet werden.
          "catch-22"
          JFTR: laut Microsoft eigenen Telemetriedaten gibt's auf 50% bis 75% aller Windows-Installationen nur eine Benutzerkennung: das ist dann die bei der Installation angelegte Administratorkennung, unter der die Narrenkappe UAC aktiv ist.

          • Martin Feuerstein sagt:

            Na solang Otto-Normal nicht sowieso mit Admin-Rechten arbeitet… (hoffentlich ist wenigstens die UAC aktiviert, aber darauf kommts dann auch nicht mehr an).

            • Stefan Kanthak sagt:

              1. welchen Teil von "die bei der Installation angelegte Administratorkennung, unter der die Narrenkappe UAC aktiv ist." willst Du nicht verstehen?
              2. Otto Normalbenutzer missbraucht Windows so, wie der OEM oder er selbst es installiert hat: im vernarrenkappten Administratorkonto.
              3. wenn er es in einen unprivilegierten Standardbenutzerkonto missbraucht, aber das Kasperltheater UAC für Standardbenutzer nicht deaktiviert hat: sobald er ein Installationsprogramm per Doppelklick ausführt wird er von der UAC gefragt. Lässt er dem Schicksal freien Lauf, dann lädt dieses die herumlungernden DLLs schon wieder mit Administratorrechten.

  3. Dekre sagt:

    Was ich an diesen ganzen nicht verstehe:
    # Warum kommt F-Secure erst im Juni 2018 auf die Idee die seine Dinger von einer anfälligen Packversion von 7-zip auf das gefixte zuerst V 18.01 und dann V 18.05 umzustellen?
    # Wie kann dann die Sicherheitslücke wirklich ausgenutzt werden von Packer zum Entpacker? Wie kommt der Böse da ins Spiel?

    Es benutzen mE sehr viele Hersteller als Packprogramm 7-zip. Man sollte diese mal alle auflisten und schauen, ob diese – wenn schon 7-zip schon die neueste Version verwenden.

    Was ich auch nicht verstehe: Warum verwenden Softwareanbieter, die rein monetär und kapitalistisch interessiert sind ein kostenloses Packprogramm (7-zip) und wenn warum unterstützen diese Igor Pavlov nicht die Lücken zu schließen? Der Witz an der Sache ist doch der, dass wohl viele Anbeiter von Sicherhetissoftware auf 7-zip zurückgreifen.

    Malwarebytes hat mit Version 3.4.4 (06.03.2018) auf 7-Zip V. 18.01 umgestellt, mE auch etwas spät. Und dann mit Version 3.5.1.2522 vom 08.05.2018 auf 7-zip V. 18.05.
    Die Umstellung auf V 18.01 findet sich in der Release History hier:
    https://www.malwarebytes.com/support/releasehistory/
    und die auf Umstellung auf V. 18.05 m Forum erst auf Anfrage hier:
    https://forums.malwarebytes.com/topic/228610-vulnerability-in-7zip-remote-code-execution-and-malwarebytes/

    Irgendwie denke ich bei solchen Problemen, dass es nur Besschäftigungstherapie ist und Sicherheit in diesen ganzen Gedöns nur vorgetäuscht wird. Das ist doch alles schnulli. Softwarehersteller von AV-Programmen verwenden anfällige Produkte. Ich verstehe es nicht. Die Frechheit besteht darin, dass diese ihre Produkte verkaufen und horrende Gelder einnehmen und basteln sich das Ganze aus kostenlosen Open-Source Programmen zusammen. Sie sind aber hinterher, wenn jemand eine getürkte Lizenz verwendet, toll!

  4. Günter Born sagt:

    Antwort vom F-Secure-Support

    Inzwischen hat mir der Support von F-Secure die nachfolgende Antwort im Hinblick auf einige Fragen gegeben.

    Guten Morgen, Ich habe jetzt von der Entwicklung zurück gehört und die Kollegen bedanken sich für das Interesse.
    Es wurde in der letzten Zeit mehre Probleme in dieser Richtung gelöst und kürzlich auch ein Security Advisory hierzu veröffenlicht
    https://www.f-secure.com/en/web/labs_global/fsc-2018-2
    Welches Sie ja schon in Ihrem Blog angemerkt haben.
    Wir arbeiten auch aktiv mit Security Researchers um weitere Probleme zu finden und zu beseitigen. Falls Sie dazu mehr Information haben, bitte Ich Sie direkt mit den Kollegen Kontakt auf zu nehmen. Die würde gerne von Ihnen hören.

    Angehend der Temporären Dateien, Wir entpacken Dateien temporär unter %programdata% welche unter ACL verhindern das andere Programme Änderungen vornehmen und benutzen DAAS2 um Daten zu Verifizieren.
    Falls Sie jedoch eine Möglichkeit des DLL Highjacking gefunden haben würden wir gerne mehr dazu wissen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.