Oracle patcht 0-Day-Schwachstelle und provoziert Entdeckung weiterer Schwachstellen
Es geht weiter mit der Entwicklung rund um die aktuellen 0-Day-Schwachstellen. Oracle hat die am 28. Februar entdeckte 0-Day-Schwachstelle in Java behoben - und außerdem einen Sicherheitsforscher provoziert, der auf Oracles trotziges "Das da ist aber keine Schwachstelle!!!" noch mal genauer hin gesehen und dabei gleich fünf weitere Schwachstellen entdeckt hat. Zusammen erlauben sie den Ausbruch aus der Sandbox. Vielleicht sollte man besser mal die Java-Entwickler in einen Standkasten stecken?
1. März: Apple blockiert alte Flash Player in Safari
Apple hat bekannt gegeben, dass alte Versionen des Flash Players in Safari blockiert werden. Betroffen sind alle Versionen vor der aktuellen Version 11.6.602.171 (alles andere wäre ja auch kontraproduktiv). Das Update ist seit dem 28. Februar verfügbar. Hat man Angst, selbst wieder zum Opfer zu werden?
4. März: Oracle patcht CVE-2013-1493
Oracle hat Updates auf Java 5 Update 41 (nicht öffentlich verfügbar), Java 6 Update 43 (das letzte öffentliche Update für Java 6) und Java 7 Update 17 veröffentlicht, um die 0-Day-Schwachstelle CVE-2013-1493 und eine weitere Schwachstelle zu beheben. Beide Schwachstellen betreffen nur das Browser-Plug-In.
Oracle konnte die Schwachstelle so zügig beheben, weil sie dort bereits seit dem 1. Februar bekannt war. Ohne die aktuellen Angriffe wäre der Patch im Rahmen des nächsten Patchdays (bei Oracle "Critical Patch Update" genannt) am 16. April veröffentlicht worden. Möchte irgend jemand über den Unsinn von Patchdays diskutieren? Vor allem, wenn sie wie bei Oracle im Normal nur vierteljährlich stattfinden? Der 16. April wurde nur ausnahmsweise zusätzlich aufgenommen. Vermutlich, weil man noch reichlich Patches auf Lager hat und langsam merkt, dass zu langes Warten Java irgendwann den Todesstoß versetzen könnte. Wer will schon eine Software, wenn er weiß, dass der Entwickler ihn wissentlich der Gefahr von Angriffen aussetzt? Es ist ja schön, wenn Oracle erklärt
"... Oracle is committed to accelerating the release of security fixes for Java SE, particularly to help address the security-worthiness of Java running in browsers. The quick release of this Security Alert, the higher number of Java SE fixes included in recent Critical Patch Updates, and the announcement of an additional security release date for Java SE (the April 16th Critical Patch Update for Java SE) are examples of this commitment."
aber meines Erachtens reicht das bei weitem nicht aus. Da muss schon mindestens ein monatlicher Patchday her, und dann sollte man mal überlegen, ob man vielleicht Bill Gates um einen aufrüttelnde E-Mail bittet, damit da endlich sowas wie ein Security Development Lifecycle aufgebaut wird. Von alleine schafft man das wohl nicht, denn mit dem Anerkennen bzw. Erkennen von gemeldeten Schwachstellen hapert es noch gewaltig. Vom Patchen ganz zu schweigen. Der Beweis:
4. März: Weitere Schwachstellen in Java entdeckt
Adam Gowdiak von Security Explorations berichtet, dass Oracle bei einer der beiden am 25. Februar gemeldeten Schwachstellen abstreitet, dass es sich um eine solche handelt. Was ziemlich dumm war, denn daraufhin hat Adam Gowdiak sich das Ganze noch mal genauer angesehen und dabei fünf weitere Schwachstellen entdeckt. Alle gemeinsam erlauben den Ausbruch aus der Java-Sandbox. Unter anderem wurde eine Abweichung zwischen JVM-Spezifikation und -Implementierung entdeckt. Wieso wundert mich das jetzt gar nicht? Ach ja: Weil es bei der umstrittenen Schwachstelle auch um die Frage geht, wie denn die Spezifikation auszulegen sei.
4. März: Apple aktualisiert Java und blockiert alte Java Plug-Ins
Apple hat Updates für Java für Mac OS X 10.6.8 und eine Anleitung zum Aktualisieren von Java 7 für Mac OS X 10.7.5 und 10.8.2 veröffentlicht und hilft auch etwas nach. Außerdem wurde angekündigt, alte Java Plug-Ins in Safari zu blockieren.
Kleiner Kommentar am Rande: Bis zum 4. März wurde unter dem URL
http://support.apple.com/kb/HT5660
angekündigt, dass der
Flash Player blockiert wird. Seit dem 4. März wurde das Support-Dokument
geändert, so dass nun verkündet wird, dass alte Java Plug-Ins blockiert
werden. Besonders nett ist so ein Austauschen der Inhalte nicht.
5. März: Java-Schutzfunktion dank Defaulteinstellung nutzlos
Signierte Java-Applets sind vertrauenswürdig und dürfen die Sandbox verlassen. So weit, so gut. Eric Romang berichtet über einen Java-Schädling, der mit der Signatur eines vertrauenswürdigen Entwicklers versehen ist. Also darf der Code weiteren Code nachladen und die Sandbox verlassen. Das Problem dabei: Der zugehörige private Schlüssel ist schon vor einiger Zeit ausgespäht worden, das Zertifikat wurde am 7. Dezember zurückgezogen. Was Java aber nicht weiter stört, da die Zertifikate in der Defaulteinstellung nicht auf Gültigkeit geprüft werden. Und laut Jindrich Kubec von Avast wird außerdem auch noch per Default auch selbstsignierten Apps vertraut. Wollte man damit vielleicht störenden Supportanfragen zuvor kommen?
Die 0-Day-Exploits im Überblick
Kommen wir noch zur aktualisierten Übersicht über die aktuellen 0-Day-Exploits:
Nummer | Veröffentlicht | Gepatcht | Programm (Link zum Blog-Artikel) |
CVE-ID |
---|---|---|---|---|
1 | 28. Dezember 2012 | 14. Januar 2013 | Internet Explorer | CVE-2012-4792 |
2 | 10. Januar 2013 | 13. Januar 2013 | Java | CVE-2013-0422 |
3 | 1. Februar 2013 | 1. Februar 2013 | Java | unbekannt |
4 + 5 | 7. Februar 2013 | 7. Februar 2013 | Flash Player | CVE-2013-0633 und CVE-2013-0634 |
6 + 7 | 12. Februar 2013 | 20. Februar 2013 | Adobe Reader | CVE-2013-0640 und CVE-2013-0641 |
8 | 25. Februar 2013 | unbekannt | Ichitaro | CVE-2013-0707 |
9 + 10 | 26. Februar 2013 | 26. Februar 2013 | Flash Player | CVE-2013-0643 und CVE-2013-0648 |
11 | 28. Februar 2013 | 4. März 2013 | Java | CVE-2013-1493 |
Trackbacks
Dipl.-Inform. Carsten Eilers am : Programmierfehler oder erlaubtes Verhalten?
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Code Signing - Auch Schadsoftware kann signiert sein
Vorschau anzeigen