Java und security des tages

Java ist ja „sicher“, weil von vornherein an sicherheit gedacht wurde und zum beispiel java-applets in einem sandkasten laufen. Eventuelle fehler in der implementazjon, die diesen „schutz“ aushebeln, können da ruhig mal etwas hastig geflickt werden, so dass sie auf milljonen rechnern drinbleiben.

Der neue Exploit ermöglicht es, aus der Java-Sandbox auszubrechen („A complete Java security escape could be achieved with it.“). Damit steht zwischen einem saubern System und einer Infektion mit Schadprogrammen nur noch die Zwangsverzögerung „Click-to-Play“, die dafür sorgt, dass Java-Applets nicht automatisch ausgeführt werden)

Aber hej, oräkel, hauptsache deine verkackte ask-tuhlbar wird als legaler trojaner in den brauser reingestopft, wenn jemand bei der sicherheitsaktualisierung ohne genaues lesen immer schnell auf „weiter“ klickt.

Eine Antwort zu “Java und security des tages

  1. Heute gerade wieder ein Aha-Erlebnis mit Java 1.8 gehabt.Setze Jetty und GitBlit auf. Einfach wie immer: Eine Woche lang die Dokumentationen und das WWW durchforsten; einen Wald von XML- und INI-Konfigurationen zu begreifen versuchen; tolle neue Begriffe wie JNDI lernen (für die bahnbrechende Idee, eine Konfigurationsdatei außerhalb des damit konfigurierten Software-Pakets ablegen zu können); und am Schluss einfach zwei Archive an bestimmte Stellen kopieren, eine kurze XML-Datei anlegen, einen Keystore mit Server-Schlüssel und Letsencrypt-Zertifikat erzeugen, Pfadnamen in INI-Dateien eintragen, und fertig. Läuft!Außer, dass mein TenFourFox nicht auf die HTTPS-Seite will:

    The connection […] was interrupted while the page was loading.

    HTTP geht. curl auf HTTPS geht. openssl s_client geht. Mein Firefox-Derivat hingegen schickt laut Web-Konsole zwei gleiche Anfragen (warum?) an die selbe URL los und kriegt keine Antwort zurück. Die gleiche Anfrage als curl-Kommando (Copy as cURL) liefert die Seite ordnungsgemäß. Zertifikat OK, alles wunderbar. Was ist mit dem Firefox los?Browser-Security-Einstellungen in der about:config untersucht. Bei der Gelegenheit Googles TLS False Start (unsicher) und NPN (überholt) abgestellt. Die anderen Nicht-Standard-Einstellungen zur Kenntnis genommen und auf meinem Paranoia-Niveau belassen: Nur die Perfect Forward Secrecy-Verfahren (ohne RC4) aktiviert und keine Fallbacks zugelassen.Neuer Versuch: Firefox schickt die Anfrage nur noch einmal (Mozilla und Google, verdammt, was denkt Ihr Euch eigentlich?), aber mit dem gleichen leeren Ergebnis. Könnte es die eingeschrânkte Chiffren-Auswahl sein?Server debugged: java -Djavax.net.debug=all etc. Folgendes passiert beim Bearbeiten der Firefox-Anfrage:

    java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available

    Super. Bietet ECDHE-Chiffren an, aber kann sie nicht verwenden.Websuche ergibt, dass das eine Macke von OpenJDK 1.8 ist. Eigentlich eine dokumentierte Macke der SunCE, die nur dann ECDHE anbietet, wenn sie die eigene JRE vorfindet. Also funktioniert das bei OpenJDK nicht, und die Reaktion der OpenJDK-Paketierer war typisch: Lieber amputieren, als einen häretischen Workaround anbieten. Mit Oracles JRE klappt’s. Die Besucher des Servers können jetzt also sicher sein, dass ihre Daten an eine proprietäre JVM gehen. Muss das sein?

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.