Hat eigentlich jemand von euch schon von dem aktuellen 0-Day in der Kombination mit Serialisierung/Deserialisierung und apache-commons-collections
Mehr Infos:
Zero-Day-Alarm für viele Server mit Java | heise online
Remotely Exploitable Java Zero Day Exploits through Deserialization
Erstens nicht neu, das Problem ist seit Jahren bekannt, zweitens NIEMALS NIE NICHT serialisierte Daten von Usern (egal von wem oder wo) die extern eingespielt wurden deserialisieren, an eine Datenbank weitergeben (nicht un-escaped), ausführen oder sonst etwas! Never trust the fucking users, nicht nur für Gameserver sondern bei jedem Serversystem die richtige Einstellung.
Dass das immer noch nicht allgemeines Grundwissen ist erschreckt mich immer wieder - siehe wie oft noch SQL Injections möglich sind… aber naja jeder darf sich ja Software Developer oder Software Engineer nennen (auch wenn die meisten sich Frickler schimpfen müssten).
das geht auch einfacher 
[EVIL]traue keinem Bit das Du nicht selbst erzeugt hast[/EVIL]
ist allerdings schwer immer an alle Möglichkeiten zu denken
Unabhängig was man von Serialisierung halten möchte, hat man mit diesem Code ein Problem, wenn commons-collections im CP vorhanden ist.
try (ObjectInputStream ois = new ObjectInputStream(is)) {
Object obj = ois.readObject();
String msg = (String) obj;
if(!validate(msg)) return;
System.out.println("Msg " + msg);
}
}```
In Zeile 4 geht man davon aus, dass wenn das Object kein String ist, dann verabschiedet sich das ganze mit einer ClassCastException und gut ist.
In Zeile 6 kann man schon von String ausgehen und eine entsprechende Validierung sollte hier ja auch Sicherstellen, dass die letzten Zweifel beseitigt sind.
Das Problem ist allerdings schon in Zeile 3 beim Aufruf von readObject() perfekt, da hier mit dem entsprechenden Input nahezu beliebiger Code ausgeführt werden kann.
Und das hat für mich schon eine gewisse Qualität.
Wie handhabt das eigentlich Hazelcast?
Dort müssen ja auch die einzelnen Knoten miteinander Daten austauschen und diese in irgend einer Art und Weise serialisieren.
Das Gefahrenpotential dürfte da ja ähnlich aussehen.beziehst du dich speziell hier auf commons-collections, also das mit InvokerTransformer?
in der Heise-Meldung freilich genauso, nicht gerade Jahre, aber fast schon ein Jahr:
Admins, die Server mit Java-Anwendungen betreiben, müssen somit sich auf einiges an Arbeit einrichten. Denn obwohl das Problem bereits seit neun Monaten bekannt ist, gibt es immer noch keinen richtigen Fix. Tests der eigenen Installationen und eine zumindest provisorische Absicherung des Server sind somit weitgehend Handarbeit.
Einen ersten Überblick kann sich ein verunsicherter Admin mit einem Befehl wie
grep -Rl InvokerTransformer .
./webapps/ROOT/WEB-INF/lib/commons-collections-3.2.1.jar
und doch gerade auch bei
https://issues.apache.org/jira/browse/COLLECTIONS-580
vorbeigekommen,
was nach dem offziellen einen Thread beim ‚Hersteller‘ von commons-collections zu InvokerTransformer klingt,
und da erst seit halber Woche ein Thema und nun energisch angegangen?!
wie passt denn das zusammen…
*** Edit ***
eine Art Schutz, LookAheadDeserializer …
Look-ahead Java deserialization
(im heise-Forum genannt)
Wo ist die Umfrageoption „Schon ausgenutzt“ ?
Wie immer beunruhigend solche Meldungen, aber wie gesagt
Der Code wird immer größer, umfassender und schlechter von Menschen kontrollierbar. Ich warte immernoch auf den Tag an dem Maschinen Maschinen programmieren.
Hier finde ich es nur ziemlich krass, weil das eine solche offensichtliche Sicherheitslücke im Code ist.
Hätte man wenigstens einen gelben Zettel mit ein paar Ausrufezeichen hinterlassen oder zumindest eine weitere Zeile eingefügt die vorher überprüft ob die Quelle vertrauenswürdig oder die NSA ist.
[QUOTE=ionutbaiu]Wie handhabt das eigentlich Hazelcast?
Dort müssen ja auch die einzelnen Knoten miteinander Daten austauschen und diese in irgend einer Art und Weise serialisieren.
Das Gefahrenpotential dürfte da ja ähnlich aussehen.[/QUOTE]
Eine interessante Frage und die Antwort ist etwas länger. Nach Aufkommen der letzten Ergebnisse, und das sich alle darauf gestürzt haben, gab es natürlich intern Diskussion. Leider nicht soviel wie ich gerne gesehen habe, aber vermutlich habe ich die Diskussion einfach im Keim erstickt.
Also gut, etwas ausholen:
Wir haben tatsächlich Kunden, man glaube es kaum aus der Finanzwelt heul, die fragen allen Ernstes nach einem Distributed Classloader, weil Classes deployen auf Servern ja immer so lästig ist, besonders in Zeiten von Docker und fertigen Appliances. Wäre es nicht cool man könnte Klassen einfach von irgendwo laden? HOLY C… wer will das schon in einer Bank? Außer den Entwicklern dort?
So also diskutiere ich seit Jahren gegen Distributed Classloadern und erkläre / indoktriniere Entwickler wieso man das nicht will.
Soweit so gut, mit der De-Serialization wäre das Problem noch größer - obviously 
Das Problem ist aber wie gesagt nicht neu, schon vor mind. 3 Jahren habe ich gezeigt wie ich mit etwas Langeweile und Bytecode Enhancement/Runtime Generation (das ist was der Transformer ja auch tut) lustige Spielchen treiben kann. Dank Runtime Javascript Engine, ASM oder BCEL (IBM) embedded in der JVM und einigen anderen Tricks (z.B. sun.misc.Unsafe, der SUN Http Client Lib usw) kann man ähnliche Effekte erzielen. Der aktuelle Case zeigt nur wie gefährlich es ist Code UND Daten aus unbekannter Quelle zu vertrauen.
Soviel dazu, zurück zu Hazelcast: Hazelcast kann Java Serialization nutzen, trotzdem - aufgrund der Größe des resultierenden Streams und der Geschwindigkeit … sorry Langsamkeit, raten wir grundsätzlich davon ab. Ich erwähne meistens auch beiläufig die Sicherheitsprobleme, glaube aber nicht, dass die jemand wirklich wahrnimmt - Performance ist ja das Totschlagargument. Ok heißt: Leute sollten keine Java Serialization nutzen, dann eben Kryo - ähnliches Problem - nicht aber soooooo tragisch.
Hazelcast bietet eigene Serialisierungsmechanism an, die erstens auf die beiden Probleme Stream-Größe und Geschwindigkeit optimiert sind aber andererseits (ohne Distributed Classloader) auch keinen unbekannten Code einschleusen können (wenn richtig eingesetzt und ohne Fallback auf Java Serialization). Tradeoff: man schreibt den Serialization Code selber (ähnlich java.io.Externalizable) oder lässt ihn mit Tools generieren (hoffentlich). Aus dem Grund von unbeabsichtigter Java Serialization haben wir in einer der früheren Versionen bewusst das Interface DataSerializable nicht mehr von Serializable abgeleitet. Davor wurde nämlich ein Hazelcast DataSerializable Object mit Java Serialization serialisiert, sobald es in ein Serializable Object gewrapped war. Jetzt fliegt eine NotSerializableException.
Also Conclusion: Hazelcast hat einen eigenen Mechanismus, nicht unbedingt entwickelt für Sicherheit aber spielt dem Ganzen zu. Hazelcast hat weiterhin keinen Distributed Classloader (wie z.B. Apache Ignite/Gridgain und andere) for reasons. Allerdings kann immer noch JavaScript Code eingeschleust werden mit den entsprechenden Vorarbeiten auf Seiten des Entwicklerteams, da man ja „erweiterbar“ sein möchte 
Also hat ein Team die Möglichkeit JS Code auf der Serverseite auszuführen hab ich jede Sicherheit verloren und wir sind zurück auf „Never trust any external Code / Data“!
*** Edit ***
[QUOTE=SlaterB;125674]beziehst du dich speziell hier auf commons-collections, also das mit InvokerTransformer?
in der Heise-Meldung freilich genauso, nicht gerade Jahre, aber fast schon ein Jahr:[/QUOTE]
Generell, siehe vorherige Antwort
PS: Hier ist eine Lösung für exakt diesen Exploit https://github.com/contrast-security-oss/contrast-ro0