Deutsch | English
Dieser Blog enthält keine offiziellen Aussagen von CERT.at, sondern persönliche Meinungen einzelner Mitarbeiter.
Und jetzt noch ein DoS-Bug in libxml2
16. Oktober 2014

Nach Poodle und Drupal, und dem diesmal doch ausgiebigen Patch Tuesday (Microsoft, Adobe, Oracle Java) jetzt auch noch ein Bug in libxml2.

Ist zwar (nach aktuellem Wissensstand) "nur" zu Denial-of-Service zu gebrauchen, hätte es diese Woche aber wirklich nicht mehr gebraucht. Ausserdem scheinen die üblichen Distributionen noch keine gepatchten Pakete fertig zu haben (was sich aber wohl bald ändern wird).

Die Kollegen aus den Niederlanden (NCSC.nl) haben einen guten Factsheet zu dem libxml2-Problem.

Autor: Robert Waldner

Auf Beast folgt Poodle
15. Oktober 2014

Es geht mal wieder ein Angriff auf SSL um: Dieses mal erwischt es SSLv3, der Angriff selber läuft ähnlich wie Beast oder Crime: Javascript im Browser löst viele, clever konstruierte Requests auf eine Webseite aus, in die der User eingeloggt ist. Das erlaubt es jemanden, der am Kabel mitlauscht, den Klartext von konstanten HTTP-Headern zu ermitteln.

Das Angriffsziel ist auch hier wieder das Session-Cookie für eine aktive Session des Browsers bei einer anderen Webseite.

Technisch gesehen handelt es sich um einen Designfehler von SSLv3 in bei der Verwendung von CBC-Mode mit dem dort nötigen Padding.

Was hat das für Auswirkungen?

SSLv3 ist alt. Sehr alt. Nur noch ein kleiner Bruchteil (0,3%) der verschlüsselten Kommunikation im Web verwendet SSLv3. Aber: ein Angreifer am Kabel kann den Aufbau einer TLS-Verschlüsselung so stören, dass viele Browser auf SSLv3 zurückfallen. Damit sind deutlich mehr Verbindungen angreifbar, als die aktuelle Rate an SSLv3-Verbindungen vermuten lässt.

Der Angriff ist auch nicht wirklich massentauglich. Er braucht einen man-in-the middle, was beim typischen Websurfen zuhause (DSL, Kabel, 3G) oder in der Firma (hoffentlich kein Angreifer im Netz) nicht leicht der Fall ist. Heikler sind offene WLANs oder andere nicht vertrauenswürdige Zugangsnetze.

Was soll man tun?

  • Don't Panic!
  • SSLv3 hat im aktuellen Web nichts mehr verloren und sollte verschwinden. Das sagt sich leicht, und ist auch in vielen Fällen problemlos machbar. Chrome und Firefox werden demnächst per Default SSLv3 abdrehen, in den meisten Browsern lässt sich der SSLv3 Support abschalten.

    Ja, es mag hier und da noch einzelne Legacy-Webserver geben, die kein TLS können, aber der geballte Druck durch Chrome und Firefox wird diese schnell zum Upgrade treiben. Ich sehe Probleme vor allem bei ausgefallenen Browsern: Alte Tablets/Smartphones, Smart-TVs, Medienboxen, Appliances, ...

  • Serverseitig kann man SSLv3 auch abdrehen, hier gibt es im wesentlichen nur folgendes zu berücksichtigen: Internet Explorer 6 unter Windows XP kann nicht mehr. Da aber das seit 8 Monaten eine von Microsoft nicht mehr betreute Platform ist, ist mein persönliches Verständnis für diese User nur noch marginal. (Wenn schon XP, dann bitte wenigstens einen Browser, für den es noch Updates gibt!)

    Es wird stark drauf ankommen, um welche Webseite es geht: Kann man es sich leisten, einen kleinen Anteil an Usern mit obsoleten Browsern auszuschließen? Wie stark wiegt das gegen einen Sicherheitsgewinn für die Mehrzahl der Besucher? Diese Abwägung ist nicht neu, siehe dazu die Diskussion auf www.bettercrypto.org.

  • Generischer Schutz gegen Downgrade-Angriffe: Google standardisiert gerade in der IETF mit SCSV einen allgemeinen Schutz gegen Manipulationen im TLS-Handshake. Das hilft hier (so der Software-Support dafür da ist), aber vor allem vor zukünftige, ähnliche Angriffe. Man sollte also SCSV aktivieren, sobald Support dafür in der Server- oder Clientsoftware verfügbar wird.

Links:

Autor: Otmar Lendl

Gedanken nach meinem shellshock
30. September 2014

Zum Thema Shellshock ist mir heute nach diesem Artikel wiederholt richtig klar geworden, dass das ganze dieses mal nicht so einfach ist wie Heartbleed - die Diversität mit der sich bash bugs (bzw. shell mis-interpretationen) verstecken ist interessant!

Nach lesen des Artikels kann man sich jetzt fragen, ob auch OpenVPN betroffen ist und alle VPNs der Welt unsicher sind. Aber das dürfte hier nicht so trivial und häufig ausnutzbar sein wie beim ersten bash-bug.

Zitat aus dem Artikel:

"Gert Doering, speaking on behalf of the OpenVPN open source community version, said that OpenVPN is vulnerable only on systems where /bin/sh points to /bin/bash, or if a script that runs using bash as an interpreter is called explicity."

Sprich: da muss man schon üblicherweise ein shell script bei OpenVPN angeben und dann noch explizit die bash als Interpreter angeben (und weiters geht's auch nicht, wenn man client certificates verwendet). Aber egal... das ändert nichts an der Diversität , mit der sich der bash-bug in Software zeigt. Es ist vielmehr ein schönes Beispiel, wie viele diverse Stellen wir noch mit dem bash-bug entdecken werden.

Ich sehe kaum einen Weg, systematisch alle verwundbaren Systeme zu finden und die Betroffenen zu informieren. Und schon gar nicht, ohne ein System aktiv zu überreden, fremden shellcode auszuführen. Auf github ist eine nette Übersicht zu finden, was potentiell alles von shellshock betroffen sein kann (PoC code!).

Wie Matt Blaze vor kurzem sagte:

"That said, our practice of using Turing-complete interpreters to parse network input is giving a scorpion a ride as we swim across the pond."

Erinnert mich verdammt an das Thema langsec am 28. CCC

Hmm...

Autor: L. Aaron Kaplan

Abgeschlossen: Wartungsarbeiten Dienstag 30. September 2014
29. September 2014

Wir werden am Dienstag, 30. Sep. 2014, ab etwa 9h, Wartungsarbeiten an unserer Firewall vornehmen. Dadurch wird es zu Ausfällen aller öffentlich erreichbaren Internet-Services von CERT.at (zum Beispiel Webserver, Mail, Mailing-Listen, RSS-/Atom-Feeds etc.) kommen.

Mails gehen selbstverständlich in dieser Zeit nicht verloren, es kann nur zu Verzögerungen bei Zustellung/Beantwortung kommen. Für die Webseite wird eine Ausfalls-Seite mit eingeschränkter Funktionalität zur Verfügung stehen.

In dringenden Fällen sind wir aber natürlich wie gewohnt per Telephon (+43 1 505 64 16 78) erreichbar.

Sobald die Arbeiten abgeschlossen sind, werden wir diesen Post entsprechend anpassen.

Update: Die Wartungsarbeiten wurden gegen 10h abgeschlossen; insgesamt kam es zu Ausfallszeiten von etwa 15 Minuten.

Autor: Robert Waldner

Nächste >>
Email: reports@cert.at
Tel.: +43 1 5056416 78
mehr ...
Schwerwiegende Sicherheitslücke in Microsoft OLE - aktiv ausgenützt
22. Oktober 2014 | Beschreibung Microsoft ...
Kritische Sicherheitslücke in Drupal
16. Oktober 2014 | Beschreibung In ...
mehr ...
Und jetzt noch ein DoS-Bug in libxml2
16. Oktober 2014 | Nach ...
Auf Beast folgt Poodle
15. Oktober 2014 | Es ...
mehr ...
Jahresbericht 2013
Ein Resumee zur digitalen Sicherheitslage in Österreich.
Letzte Änderung: 2014/10/21 - 11:59:56
Haftungsausschluss