CleanPress

Kategorie: Security

  • Stellungnahme der PGP-Entwickler zu EFAIL

     

    PGP-Entwickler zu EFAIL
    Quelle: StockSnap Lizenz: CC0 1.0

    Die Berichterstattung um die Lücken in E-Mail-Clients, die Angreifer nutzen können, um verschlüsselte E-Mails zu entschlüsseln und zu entwenden, rief viel Kritik bei Entwicklern und Sicherheitsexperten hervor. So hatte sich Werner Koch, der Erfinder von GNU Privacy Guard (GnuPG) auf der GnuPG-Mailingliste dahingehend geäußert, in Sachen OpenPGP sei die Panikmache vor allem der EFF übertrieben. Jetzt haben sich auch die PGP-Entwickler in einer gemeinsamen Erklärung zur Ehrenrettung ihrer Software entschieden. Es äußern sich Andy Yen, der Gründer von ProtonMail, Phillip Zimmermann als Erfinder von Pretty Good Privacy (PGP), Patrick Brunschwig als Entwickler von Enigmail sowie der Mailvelope-Gründer Thomas Oberndörfer.

    Unnötig aufgebauscht

    Die Kritik richtet sich auch hier gegen die Berichterstattung der Electronic Frontier Foundation (EFF), die ein Papier der Entdecker der Lücken aufgegriffen hatte und damit ein weltweites Medienecho bis hin zur Tagesschau ausgelöst hatten. Die PGP-Entwickler richten sich gegen einige Aussagen in der Presseberichterstattung und stellen klar:

    [su_quote style=“modern-light“ cite=“PGP-Entwickler“ url=“https://protonmail.com/blog/pgp-efail-statement/“]»Diese Aussagen sind höchst irreführend und potenziell gefährlich. PGP ist nicht defekt. Die von EFail identifizierten Schwachstellen sind keine Fehler des OpenPGP-Protokolls selbst, sondern Fehler in bestimmten Implementierungen von PGP, darunter in Apple Mail, Mozilla Thunderbird und Microsoft Outlook. Viele andere häufig verwendete Software, die auf PGP basiert, sind von der EFail-Schwachstelle in keiner Weise betroffen, wie die Forscher selbst in ihrem Beitrag betonen. Als offener Standard kann jeder PGP implementiere und es überrascht nicht, dass einige Implementierungen Sicherheitslücken aufweisen. Dies bedeutet jedoch nicht, dass PGP selbst defekt ist.«[/su_quote]

    Empfehlung für Anwender

    Die Empfehlung der Verfasser der Stellungnahme geht dahin, stets aktuelle Versionen der jeweiligen Software zu verwenden. So wurde beispielsweise der E-Mail-Client Thunderbird bereits aktualisiert und größtenteils gegen die Lücken immunisiert. Die Entwickler bitten darum, dass jeder auch seine Kommunikationspartner informiert und zur Aktualisierung der Software animiert.

    Software, die auf  PGP, GnuPG, Mailvelope und ProtonMail basiert, war nie gegen EFAIL anfällig. Enigmail und GPGtools waren verwundbar, jedoch ließ sich ein Angriff relativ leicht verhindern. Bei der Verwendung von Enigmail muss Version 2.05 verwendet werden und nur einfaches HTML ohne Nachladen externer Inhalte oder noch besser, reine Textansicht in Thunderbird. Bei GPGTools muss ebenfalls das Nachladen externer Inhalte deaktiviert werden.

    Empfehlung der EFF zu rigide

    Die EFF empfahl Benutzern, PGP-Plugins zu deaktivieren oder die Verwendung von PGP ganz einzustellen. Das sei so ähnlich wie zu sagen: »Einige Schlösser könnten aufgebrochen werden, deshalb müssen wir alle Türen entfernen.« Das sei besonders gefährlich, da es Personen gefährden kann, die sich aus Sicherheitsgründen auf PGP-Verschlüsselung verlassen, so die Entwickler. Somit ist nach EFAIL die Benutzung von E-Mail genauso (un)-sicher wie eh und je.

     

     

  • Intel nennt neue Lücken Spectre 3a und 4

    Spectre 3a und 4
    Bild: Public Domain

     

    Die Anfang des Monats entdeckten acht neuen Sicherheitslücken in Intel-CPUs, die unter dem Sammelbegriff Spectre-NG eingeführt wurden, wurden von Intel damals bestätigt. Bei den von mehreren Forscherteams entdeckten Lücken schätzt der Hersteller die Hälfte als »hochriskant« und den Rest mit der Gefährlichkeitsstufe »mittel« ein. Jetzt wurden zwei der Lücken offiziell mit Spectre 3a und 4 bezeichnet. Die US-Sicherheitsbehörde US-Cert bezeichnet sie offiziell als Side-Channel Vulnerability Variants 3a und 4, nachdem Intel sie am Pfingstmontag öffentlich gemacht hatte. Die neuen Verwundbarkeiten ähneln denen von Spectre, indem sie auch durch Lücken in der spekulativen Ausführung ausgenutzt werden können.

    Nicht nur Intel

    Bei Variante 3a handelt es sich um die als CVE-2018-3640 kategorisierte und in ihrer Gefählichkeit als »moderate« eingestufte »Rogue System Register Read«-Lücke (RSRE). Variante 4, auch »Speculative Store Bypass« (SSB) genannt, trägt die Kennung CVE-2018-3639 und ist als »important« gekennzeichnet. Intel kündigte Updates an und erklärte, die beiden Lücken beträfen wiederum fast alle CPUs des Herstellers aus den letzten zehn Jahren. Damit nicht genug, sind auch Prozessoren von AMD, ARM und IBMs Power8, Power9 und System Z betroffen. Intel hat inzwischen eine Liste seiner betroffenen Prozessoren veröffentlicht. Auch AMD und ARM haben Stellung bezogen.

    Microcode-Updates in der Erprobung

    Wann die Updates verfügbar sind, hat Intel bisher ebenso wenig verraten wie die anderen Hersteller. Es ist lediglich bekannt, dass Microcode-Updates in Beta-Versionen vorliegen, die in den nächsten Monaten stabil verfügbar werden sollen. Die Linux-Kernel-Entwickler haben bereits gestern Patches für Kernel 4.17 eingereicht. So reichte Thomas Gleixner Patches gegen SSB ein. Über Nacht folgten Patches für die PowerPC-Plattform. Die Patches sollen nun auf die weiteren unterstützten Kernel-Versionen rückportiert werden. Allerdings wird eine weitestgehende Entschärfung der Lücken auch diesmal nicht ohne neue Microcodes gehen.

  • Thunderbird 52.8.0 dämmt EFAIL ein

    Bild: Efail | Lizenz: Lizenz: CC0 1.0

     

    Am 18. Mai stellte Mozilla eine neue Version des E-Mail-Clients Thunderbird bereit. Thunderbird 52.8.0 beseitigt mehrere Sicherheitslücken, unter anderem auch in Bezug auf das Auslesen verschlüsselter E-Mails durch EFAIL. Ein Bug, der erst in der nächsten Version behoben werden wird, ist das weiterhin mögliche Darstellen mehrerer Teile einer Mail in einem einzigen HTML-Kontext. Damit besteht weiterhin die Gefahr einer direkten Exfiltration, bei der sich ein Angreifer durch Manipulation recht einfach den Inhalt verschlüsselter Mails übersenden lassen kann.

    Direkte Exfiltration

    Um einen Exfiltrations-Rückkanal zu erstellen, benötigt der Angreifer zunächst Zugriff auf die verschlüsselten E-Mails, etwa durch Abhören des Netzwerkverkehrs, durch Eindringen in E-Mail-Konten, E-Mail-Server oder Client-Computer. Der Angreifer manipuliert eine verschlüsselte E-Mail in einer bestimmten Weise und sendet diese geänderte verschlüsselte E-Mail an das Opfer. Der E-Mail-Client des Opfers entschlüsselt die E-Mail und lädt die manipulativ eingefügten externen Inhalte, wodurch der Klartext an den Angreifer weitergegeben wird.

    Externe Inhalte derzeit meiden

    Das funktioniert bei Thunderbird aber nur, wenn der Anwender selbst die Funktion zum Nachladen externer Inhalte aktiviert hat. Die ist bei Thunderbird von Hause aus deaktiviert. So rät Mozilla dann auch, falls verschlüsselte Mails nachfragen, ob sie externe Inhalte nachladen sollen, dies zurzeit unbedingt zu verneinen. In jedem Fall sollte möglichst zeitnah Thunderbird 52.8.0 installiert werden. Bis zur nächsten Thunderbird-Version 52.8.1 sollten Anwender  auf alle Fälle Vorsicht walten lassen, falls Mail-Verschlüsselung per PGP oder S/MIME verwendet wird. Wann mit Entwarnung durch Thunderbird 52.8.1 zu rechnen ist, hat Mozilla noch nicht erklärt. Standardmäßig wäre das nächste Release erst am 26.6.

  • Canonical äussert sich zu Malware im Snap Store

    Canonical äussert sich zu Malware im Snap Store

    Nachdem vor einigen Tagen Malware im Snap Store von Ubuntu in zwei Apps entdeckt und entfernt worden war, äußert sich nun Mark Shuttleworth ausführlich zu Crypto-Mining-Apps und zur Sicherheit des Snap Stores. Shuttleworth stellt eingangs klar, dass es im Snap Store keine Regel gibt, die Crypto-Mining-Apps verbietet und diese Apps auch weder juristisch noch moralisch verwerflich seien. Allerdings müsse der Anwender informiert werden, dass die entsprechende App im Hintergrund CPU-Ressourcen des Nutzer-PCs verwendet, um Cryptowährungen und somit Gewinn für den Autor der App zu generieren.

    Nicolas Tomb, der Autor der beiden Snaps, die jeweils ein Spiel und den Code zum Crypto-Mining enthielten, hatte an keiner Stelle erwähnt, dass die App im Hintergrund Crypto-Mining betreibt. Im Gegenteil hatte er diese Funktionalität verschleiert und mit einer proprietären Lizenz den Einblick in den Code verhindert. Die entsprechenden Apps werden jetzt von vertrauenswürdiger Seite neu verpackt und wieder in den Snap Store eingestellt.

    Sicherheit gewährleisten

    Eine Herausforderung beim Betrieb eines Software-Repositories ist, sicherzustellen, dass die veröffentlichte Software tatsächlich nur das tut, was sie soll. In den klassischen Ubuntu-Repositories basiert die Software auf einer vertrauenswürdigen Infrastruktur, wo Pakete per Entwickler-Schlüssel abgesichert sind.  Snaps ermöglichen es Publishern, ihre Software über eine Vielzahl von Linux-Distributionen schneller an Benutzer zu verteilen, jedoch bei verminderter Kontrolle. Die meisten App-Stores bieten ein automatisches Review auf technische Funktionalität und zusätzlich eine manuelle Durchsicht auf verdächtige Komponenten. Laut Shuttleworth ist beides auch beim Ubuntu Snap Store der Fall.

    Weiterhin meint Shuttleworth:

    Selbst dann ist es aufgrund der inhärenten Komplexität der Software unmöglich, dass ein großes Repository Software erst dann akzeptiert, wenn jede einzelne Datei im Detail geprüft wurde. Das gilt unabhängig davon, ob Quellcode verfügbar ist oder nicht, denn keine Institution kann es sich leisten, jeden Tag Hunderttausende von eingehenden Quelltextzeilen zu überprüfen. Aus diesem Grund basiert das erfolgreichste Vertrauensmodell auf der Herkunft der Software, nicht auf ihrem Inhalt. Mit anderen Worten, vertrauen Sie dem Herausgeber und nicht der Anwendung selbst.

    Keine Ausreden zulässig

    Der letzte Satz drückt aber genau das aus, was anscheinend im Snap Store bisher nicht angewendet wird. Shuttleworth verspricht im weiteren Text, die Sicherheit schrittweise zu erhöhen. Eine der Maßnahmen dazu soll die Verifizierung von vertrauenswürdigen Publishern sein. Snaps aus solchen Quellen sollen dann speziell als vertrauenswürdig ausgewiesen werden. Es bleibt abzuwarten, wie sich die Situation hier verbessert. Im Endeffekt kann sich aber Shuttleworh nicht reinwaschen, indem er sagt, es sei wegen der Komplexität nicht möglich, einen sicheren Snap Store zu betreiben. Wenn das nicht möglich ist, muss das Angebot so eingeschränkt werden, dass die Sicherheit gewährleistet werden kann oder der Laden sollte schließen.

  • EFAIL – der Tag danach

    EFAIL
    Bild: Efail | Lizenz: CC0 1.0

     

    Erstaunlich ruhig ist es am Tag nach der Panik verbreitenden Enthüllung mit dem Namen EFAIL. Bereits gestern Abend hatte auf Twitter und G+ die Kritik an der Veröffentlichung und der darauf aufbauenden Berichterstattung eingesetzt. Auch dieses Blog muss sich, wie fast alle, diesen Schuh anziehen. Die Tageschau hatte sich sogar dazu verstiegen zu titeln, Forscher hätten die E-Mail-Verschlüsselung geknackt. Nun weiß es die ganze Welt: E-Mails sind unsicher. Das wissen informierte Anwender schon seit mehr als zwei Jahrzehnten. Ebenso ist die Tatsache, dass man in Mails kein HTML nutzen will, kein Geheimnis und jeder kann sich mit ein wenig Google-Suche darüber informieren, warum das so ist.

    Der Erfinder ergreift das Wort

    Werner Koch, der Erfinder von GNU Privacy Guard (GnuPG) äußerte sich bereits gestern Mittag auf der GnuPG-Mailingliste dahingehend, er sehe die Aussagen in Bezug auf PGP als reichlich überzogen. Koch empfiehlt demnach auch, kein HTML in E-Mails zu nutzen. Wenn es unumgänglich ist, solche Mails anzunehmen, solle man sicherstellen, dass der MIME-Parser des E-Mail-Cients es nicht erlaubt, entschlüsselte HTML-MIME-Anteile aneinanderzuhängen, wodurch solche Angriffe erst möglich werden.

    MDC umstritten!?

    Eine weitere Möglichkeit, Angriffe dieser art zu blockieren, ist die Verwendung von authentifizierter Verschlüsselung, die laut Koch bei PGP bereits seit 2001 verfügbar ist. Sie basiert auf Modification Detection Code (MDC) und wurde damals wegen ähnlicher Angriffe eingeführt. Die Methode ist je nach Implementierung im Client nicht zu 100 Prozent zuverlässig, aber wesentlich besser als im Fall von S/MIME, der über keine funktionierende authentifizierte Verschlüsselung verfügt. Korrekt arbeitende E-Mail-Clients geben bei jeder PGP-verschlüsselten Mail, die keinen MDC-Anhang enthält, eine Warnung aus, dass die Authentizität der Mail nicht verifiziert werden konnte und sollten das Öffnen der Mail verweigern. Gleiches gilt bei Anzeichen einer Manipulation der Mail.

    Hanno Böck, Berliner Sicherheitsexperte, der für Golem.de, die »TAZ« und »Die Zeit« schreibt, erklärte gestern auf Golem, die Datenauthentifizierung mit MDC sei mangelhaft. Seine Begründung: »Wenn die MDC-Authentifizierung fehlschlägt, werden die Daten trotzdem von GnuPG entschlüsselt und ausgegeben, erst hinterher erfolgt eine Benachrichtigung, dass die entsprechenden Daten ungültig sind.« Das gilt nach seiner Aussage für einige »naive« Mail-Clients. Er fährt fort: »Korrekt implementiert dürften ungesicherte Daten nie ausgegeben werden, sondern müssten immer verworfen werden.«

    Papier falsch betitelt

    Sicherheitsexperte und Mitentwickler der Thunderbird-Erweiterung Enigmail, Robert J. Hansen haut mit seiner Kritik in die gleiche Kerbe wie Koch und kritisiert den Rat der EFF, Enigmail, die Verschlüsselungserweiterung von Thunderbird sofort zu entfernen. Er sagt, das Papier der Forscher (PDF) sei falsch betitelt, denn die Lücken erlaubten Angriffe auf fehlerhafte E-Mail-Clients, nicht auf die Verschlüsselung selbst.

    Somit erscheint am Tag danach EFAIL als reichlich aufgeblasen und überzogen. Panikmache hilft nicht an der Stelle, wo handfeste Aufklärung und die korrekte Benennung der Schuldigen vonnöten wäre.

  • EFAIL – Brisante Lücken in OpenPGP und S/MIME

    EFAIL
    Bild: Efail | Lizenz: CC0 1.0

     

    Eigentlich sollten weitere Details zu den heute Morgen bekannt gewordenen Sicherheitslücken erst morgen früh veröffentlicht werden. Ob der Brisanz der Situation hat das Ganze aber eine Eigendynamik entwickelt. Mittlerweile wurde die Lücke mit dem Namen EFAIL versehen, erhielt ein Logo und eine eigene Webseite. Also ist außer Fanartikeln bereits alles vertreten, was eine Sicherheitslücke, die etwas auf sich hält, heutzutage braucht.

    BSI seit Monaten informiert

    Wenn aber innerhalb von wenigen Stunden nach Bekanntwerden das Bundesamt für Sicherheit und Informationstechnik  (BSI) mit Verhaltensregeln zur Stelle ist und die Tagesschau in bester Neuland-Manier berichtet, scheint wirklich Gefahr im Verzug zu sein. Was ist also genau passiert? Forscher der Fachhochschule Münster, der Ruhr-Universität Bochum sowie der Universität zu Leuven in Belgien haben schwerwiegende Schwachstellen in den Verschlüsselungsstandards OpenPGP und S/MIME entdeckt, die in vielen E-Mail-Clients ausgenutzt werden können. Das BSI war bereits seit November 2017 eingebunden.

    Der Angriff manipuliert verschlüsselte E-Mails in einer Weise, die es einem Angreifer erlaubt, den vom Empfänger entschlüsselten Text der E-Mail an einen Server unter Kontrolle des Angreifers zu senden. Dazu braucht der Angreifer Zugriff auf den Transportweg der E-Mail, auf den Mailserver oder auf den Rechner des Angegriffenen und somit auf dessen Postfach haben. Das Opfer muss zudem in seinem Mail-Client HTML-Mails und das Nachladen externer Inhalte als active content erlauben.

    Trickreiche Manipulation

    Die Manipulation einer E-Mail könnte etwa folgendermaßen aussehen: Ein auf dem Transportweg abgefangener verschlüsselter Text wird mit einer Anfrage auf das Nachladen einer Ressource, etwa eines Bildes kombiniert und diese Mail an das Opfer gesendet. Dabei wird der zu entschlüsselnde Text zwischen zwei HTML-Blöcke einbgebettet. Der E-Mail-Client des Opfers entschlüsselt den Textblock und bettet ihn in den HTML-Code ein. Daraufhin wird die im HTML eingebundene URL ausgeführt, die die Anfrage zum Nachladen von externen Inhalten enthält, wodurch der Klartext an den Server des Angreifers versendet wird. Sollte Zugriff auf den Mailserver oder den Rechner des Opfers bestehen, so funktioniert der Angriff auch mit dort liegenden älteren E-Mails.

    Verantwortlich dafür, dass diese HTML-Manipulationen funktionieren, sind veraltete Implementationen der Verschlüsselungsmethoden von OpenPGP und besonders bei S/MIME. Die Manipulation per HTML ist aber nur ein Angriffsvektor in einer derzeit etwas unübersichtlichen Situation. Bei S/MIME gibt es auch die Möglichkeit, die Antwortfunktion des OCSP-Protokolls als Rückkanal zu nutzen.

    Es gibt zwei verschiedene Arten von EFAIL-Angriffen. Der direkte Exfiltrations-Angriff nutzt Schwachstellen in Apple Mail, iOS Mail und Mozilla Thunderbird aus, um den Klartext verschlüsselter E-Mails direkt zu exfiltrieren.  Der zweite Angriffsvektor nutzt Schwachstellen direkt in der Spezifikation von OpenPGP und besonders von S/MIME aus. Der Angriff auf S/MIME ist vergleichsweise einfach und ein Angreifer kann laut den Tests der Forscher bis zu 500 S/MIME-verschlüsselte E-Mails knacken, indem er eine einzige S/MIME-E-Mail an das Opfer sendet. Bei PGP hat die zweite Methode nur eine Erfolgsquote von einem Drittel, da PGP den Klartext vor der Verschlüsselung komprimiert.

    Verschlüsselung abschalten

    Derzeit ist der sicherste Weg um sich zu schützen, Erweiterungen zur Mailverschlüsselung in den Mail-Clients abzuschalten und die privaten Schlüssel aus den Clients zu entfernen. Aktualisierungen der E-Mail-Clients sollten zeitnah installiert werden. Verschlüsselte Mails können weiterhin in einer externen Anwendung außerhalb des E-Mail-Clients geöffnet werden.

    Das Abschalten von HTML-Funktionalität und das Öffnen von eingehenden HTML-Mails verhindert einige, aber nicht alle Angriffe. Beseitigt wird das zugrundeliegende Problem nur durch eine Anpassung der Standards bei OpenPGP und S/MIME. Dort müssen authentifizierte Verschlüsselungsmethoden implementiert beziehungsweise aktiviert werden. Das wird seine Zeit brauchen.

    Die genaue Funktionsweise der Lücke beschreibt ein ausführliches  Papier (PDF) der Forscher.  Werner Koch, der Erfinder von GNU Privacy Guard (GnuPG) äußert sich auf der GnuPG-Mailingliste dahingehend, in Sachen OpenPGP sei die Panikmache vor allem der EFF übertrieben.

  • Sicherheitslücken bei PGP- und S/MIME-Tools

    Sicherheitslücken bei PGP- und S/MIME-Tools
    Bild: IMG_3129 | Quelle Andy LFollow | Lizenz: CC BY-2.0

    Die Electronic Frontier Foundation  (EFF) warnt heute vorab Anwender von PGP- und S/MIME-Tools zur Ver- und Entschlüsselung von E-Mails. Diese Tools sollten möglichst sofort deaktiviert werden. Dabei geht es um Enigmail im Zusammenhang mit Thunderbird, GPGTools mit Apple Mail und Gpg4win mit Outlook.

    Enthüllung morgen

    Die Warnung der EFF bezieht sich auf eine Twitter-Meldung, die für morgen früh um 07:00 AM UTC, also um 09:00 unserer Zeit die Enthüllung kritischer Verwundbarkeiten zu den genannten Tools ankündigt. Wer diese Tools verwendet, ist angehalten, sie sofort zu deaktivieren und vor allem keine Mails damit zu entschlüsseln. Bis weitere Klarheit herrscht, rät die EFF, verschlüsselte Kommunikationsmittel wie den Messenger Signal zu verwenden. In der Ankündigung finden sich Links, wie die entsprechenden Tools der Mail-Clients deaktiviert werden können, bis  die Lücken geschlossen sind.

    Wir werden morgen weiter berichten, sobald nähere Informationen vorliegen.

  • Google zwingt Hersteller zu mehr Android-Sicherheit

     

    Android-Sicherheit
    Quelle: Pathum Danthanarayana auf Unsplash

    Google hat auf seiner Entwickler-Messe Google I/O im kalifornischen Mountain View verkündet, Erstausrüster (OEM) von Android-Geräten künftig vertraglich zu regelmäßigen Sicherheits-Updates zu verpflichten. Über die Frequenz und die genauen Bedingungen ist allerdings noch nichts bekannt. Der einzige Hersteller der seine Gerätereihen – Nexus und Pixel – zuverlässig und pünktlich monatlich mit Sicherheits-Updates versorgt ist Google selbst. Alle anderen Hersteller handeln in dieser Hinsicht nach Gutdünken und oft lückenhaft und mit großer Verzögerung.

    Umdenken

    Im Jahr 2015 hatten Lücken in Androids Stagefright-Engine, einer Komponente zum Abspielen und Streamen von Medien auf Android-Geräten, Google zum Umdenken gebracht. Der Konzern beschloss, Android-Sicherheits-Updates künftig monatlich für die Erstausrüster zur Verfügung zu stellen. Viele große Hersteller sagten zu, diese auch zeitnah ausliefern zu wollen. Die vorher sehr schlechte Versorgung mit Updates hat sich seitdem verbessert, jedoch ist es vielfach beim Wollen geblieben.

    In den Jahren 2016 und 2017 wurden immerhin jeweils rund 30 Prozent mehr Geräte mit Updates versorgt als im Jahr zuvor. Trotzdem sind von den mehr als zwei Milliarden Android-Smartphones viele mit gravierenden Sicherheitslücken behaftet, weil die Hersteller die Geräte nicht mehr mit Updates versorgen. Hier will Google nun mit vertraglichem Druck für mehr Sicherheit zumindest bei aktuellen Geräten sorgen.

    Project Treble

    Vor ziemlich genau einem Jahr hatte Google die Bedingungen dafür durch die Ankündigung des Project Treble verbessert. Treble stellt eine stabile Hardware-Abstraktionsschicht für Android dar, die Herstellern bei jeder neuen Android-Version unter anderem alle Treiber portieren zu müssen. Realisiert wird das über eine niedrig angesiedelte Schnittstelle, die Google  schlicht »Vendor Interface« nennt.

    Patches ausgelassen

    Allerdings zeigt eine aktuelle Studie der deutschen Security Research Labs, dass selbst Hersteller, die monatlich Updates ausliefern, oft wichtige Patches auslassen, ihre Anwender aber mit falschen Angaben in Sicherheit wiegen. Nun reagiert Google auf die immer noch katastrophalen Zustände bei der Android-Sicherheit. Auf der Google I/O erklärte David Kleidermacher, Chef der Android-Sicherheit, Änderungen am Sicherheitsmodell der kürzlich vorgestellten nächsten Version Android P würden die Sicherheit von Android wesentlich verbessern.

    [su_quote style=“modern-light“ cite=“David Kleidermacher“]»Wir haben auch daran gearbeitet, Sicherheitspatches in unsere OEM-Verträge einzubauen. Nun wird dies wirklich zu einem massiven Anstieg der Anzahl der Geräte und Benutzer führen, die regelmäßig Sicherheitspatches erhalten.« [/su_quote]

    Solange allerdings die Bedingungen dieser Vertragsklauseln nicht bekannt sind, lässt sich nicht absehehen, wieviel davon Wunschdenken oder Augenwischerei ist und wie viel davon wirklich beim Endkunden ankommt.

     

  • AMD: Sicherheitslücken in Ryzen und Epyc bestätigt

    Quelle: Astaroth: The Processor von Brian Wong Lizenz: CC BY-SA 2.0
      Vor wenigen Tagen machte eine Meldung die Runde, die sehr an Meltdown und Spectre erinnerte. Die bis dahin unbekannte israelische Sicherheitsfirma CTS-Labs Research berichtete über 13 angebliche Lücken in AMDs aktuellen Desktop- und Server-Prozessoren Ryzen und Epyc. Die Aufmachung war reißerisch, inklusive martialischer Namen für die vermeintlichen Lücken. Zudem war die Art und Weise des Disclosure, also der Veröffentlichung äußerst ungewöhnlich, da AMD nur 24 Stunden Zeit hatte, die Richtigkeit der Berichte zu überprüfen, bevor sie veröffentlicht wurden. Geläufig sind hier mindestens 90 Tage.

    Dubioses Disclosure

    Die Sicherheits-Szene fand diese Herangehensweise äußerst verdächtig und hielt das Ganze für eine Promotion-Aktion oder den Versuch, AMDs Aktienkurs in einer konzertierten Aktion zu manipulieren. Allerdings bestätigten am nächsten Tag drei Forscher bekannter Sicherheitslabore die Funde. Jetzt hat auch AMD offiziell reagiert. AMDs CTO und Senior Vice President Mark Papermaster hat die Existenz aller 13 von CTS-Labs in den Prozessoren Ryzen und Epyc sowie in den von AMD verwendeten Promontory-Chipsätzen bestätigt.

    »Any attacker gaining unauthorized administrative access would have a wide range of attacks at their disposal well beyond the exploits identified in this research.« – Mark Papermaster

    Keine Leistungseinbußen

    Die Schwachstellen betreffen die Firmware, die den AMD Secure Processor verwaltet, und die Chips, die in einigen Sockel AM4 und Sockel TR4 Desktop-Plattformen mit AMD-CPUs verwendet werden. Papermaster sagte, jede der Lücken werde in den nächsten Wochen durch neue Microcode-Versionen geschlossen, ohne dass dadurch Leistungseinbußen wie bei Meltdown und Spectre zu befürchten seien. Er stellte zudem klar, dass die Fehler nicht im Silizium der Prozessoren stecken, sondern in der Software, die darauf implementiert ist. Somit können die Lücken vollständig über den Microcode geschlossen werden.

    Schwer auszunutzen

    Papermaster betonte, dass alle gefundenen Lücken zu ihrer Ausbeutung voraussetzen, dass der Angreifer über administrative Rechte verfügt. Hat ein Angreifer diese, gehört der betroffene Rechner sowieso nicht mehr dem eigentlichen Eigner. Von daher sind die Funde von CTS-Lab zwar korrekt, aber wesentlich weniger spektakulär als die Aufmachung der Veröffentlichung vermuten ließ.    

  • Mozillas Passwort-Manager unsicher

    Screenshot: ft

     

    Sowohl Firefox als auch Thunderbird erlauben es Benutzern, in den Einstellungen ein »Master-Passwort«  einzurichten. Dieses Master-Passwort dient der Verschlüsselung von Passwörtern, die in den Anwendungen vom Nutzer gespeichert werden. Generell ist diese Methode unterhalb der von ausgewachsenen Passwort-Managern angesiedelt, aber immer noch besser als keine Passwortverwaltung und daraus meist resultierend, die Mehrfachverwendung einfach zu merkender Passwörter.

    Mozilla Passwort-Manager unsicher

    Wie sich jetzt herausstellte, ist diese Funktion bei den Mozilla-Produkten nur sehr schlecht abgesichert und für jeden Hacker, der jemals den Begriff Brute-Force gehört hat, ein Kinderspiel. Das entdeckte jetzt Wladimir Palant, Entwickler der Adblock-Erweiterung. Herzstück der Verschlüsselung bei Mozilla ist die Funktion  sftkdb_passwordToKey(), die ein Passwort in einen Schlüssel umwandelt, indem es SHA-1-Hashing auf einen String anwendet, der aus einem zufälligen Salt und dem Master-Passwort besteht.

    SHA-1 zum Hashen

    Dieser Ansatz mit SHA-1 und die Implementierung seitens Mozilla hat zwei gewichtige Probleme. Zunächst ist SHA-1 bereits seit 2005 als gebrochen bekannt, wie der Kryptographieexperte Bruce Schneier damals in seinem Blog schrieb. Allerdings rechtfertigte damals der nötige Aufwand die Kosten nicht.

    2017 gelang Forschern bei Google und aus den Niederlanden erstmals ein Kollisionsangriff, bei dem zwei unterschiedliche PDF-Dateien mit demselben SHA-1-Hash erzeugt wurden. Seit 2015 gilt generell die Empfehlung, von SHA-1 auf die Nachfolger SHA-2 und SHA-3 zu wechseln, da es sich durch günstige Rechenkraft mittlerweile durchaus lohnen kann, SHA-1 zu knacken.

    Nur eine Iteration

    Das zweite Problem bei Mozillas Master-Passwort ist, das SHA-1 bei der Erzeugung des Schlüssels genau einmal iteriert. Branchenüblich sind hier Werte zwischen 10.000 und 500.000 Iterationen, je nachdem, was verschlüsselt wird. Das ist grob vergleichbar mit einem Paket, das nur einmal mit Geschenkpapier umwickelt ist, es ist schnell ausgepackt. Mit der Zahl der Lagen steigt auch der Aufwand des Entpackens.

    Bugreport mit Bart

    Nun hat Mozilla seit neun Jahren einen entsprechenden Bugreport vorliegen, dessen Brisanz unverständlicherweise niemand realisiert hat. Dabei ist SHA-2 bereits seit 2001 standardisiert. Mittlerweile kommt durch die Berichterstattung  auf BleepingComputer und der Diskussion auf Reddit wieder Leben in den Bugreport und die Mozillianer fragen sich, wie das passieren konnte. Nun wird hoffentlich schnell eine Lösung erarbeitet, die dieses Problem aus der Welt schafft.