Java und Sicherheit?

[xdavidx]

Hey,

wie siehts eigentlich mit Java und Bufferoverflows und dadurch mögliche Überschreibung von Adressen im Speicher aus?

Geht so etwas?

vlg

 

[SlaterB]

..

http://www.google.de/search?hl=de&q=+Java+und+Bufferoverflows+&btnG=Google-Suche&meta=
->
http://www.faqs.org/docs/javap/c9/s1.html
->

For software written completely in Java, buffer overflow errors are impossible. The language simply does not provide any way to store data into memory that has not been properly allocated. To do that, you would need a pointer that points to unallocated memory or you would have to refer to an array location that lies outside the range allocated for the array. As explained above, neither of these is possible in Java. (However, there could conceivably still be errors in Java's standard classes, since some of the methods in these classes are actually written in the C programming language rather than in Java.)

 

[xdavidx]

Welche potenziellen Schwachstellen hat Software die in Java geschrieben wurde?

Mich würden euere Erfahrungen interessieren!

 

[Wildcard]

Schau dir die Bugs an.

 

[xdavidx]

Welche Bugs?

 

[Wildcard]

Für die SUN VM/Klassenbibliothek, oder welche VM interessiert dich?

 

[xdavidx]

Ja!

Ist Java Software von außen angreifbar?

Bsp. viele FTP Server Programme die in C++ geschrieben wurden sind können über Bufferoverflows den Angreifer Shellcode usw. einschleusen lassen.

In Java gibt es keine Möglichkeit dies zutun aber es gibt ja noch viele andere Möglichkeiten und ich frage mich einfach wie sicher Java Software gegen solche Angriffe ist.

 

[Wildcard]

Schau dir die Bugs an.

 

[Gast2]

Moin,

In Java gibt es keine Möglichkeit dies zutun[...]

da wäre ich mir nicht so sicher ... vor ein paar Jahren hatte ich mal einen Artikel gelesen wo der Sicherheitskontext für Klassen ausgehebelt wurde ... sprich - in einem Applet konntest Du auf lokale Dateien zugreifen/verändert (wenn der Surfer Admin war) ... der Fehler dürfte zwar inzwischen behoben sein ... aber die VM ist einfach zu Komplex als das sie keine weiteren Fehler hätte ... ich zitiere mal kurz Wildcard "Schau dir die Bugs an." - da dürften solche Fehler auch weiterhin (nicht direkt) drinnen stehen

das schöne an Java (und auch .NET) ist das der Index-Zugriff geprüft wird ... damit ist (eigentlich) ein Zugriff - die für Buffer-Overflows nötig sind - nicht mehr möglich ... Heap-Overflow dürfte auch ein Problem darstellen ... allerdings weis ich nicht so genau wie die funktionieren

wenn ich jetzt mal einfach so Orakle ... Du willst Dir einen FTP-Server in Java basteln?

hand, mogel

 

[xdavidx]

Danke mogel für deinen Beitrag!

Nein es war nur ein Beispiel ich möchte einfach nur irgendwann mal in Richtung IT-Sicherheit gehn und mich evtl. unter anderem auf Java spezialisieren.

Gibt es evtl. ein Buch das dieses Thema behandelt?

 

[Der Müde Joe]

Gibt es evtl. ein Buch das dieses Thema behandelt?

Nicht Java bezogen aber sehr zu empfehlen:

Security Patterns

Habs mal gelesen und ist recht gut.

 

[Wildcard]

Jedes Problem das die JVM selbst angreifbar macht, ist ein Bug. Ein Buch zum Thema wäre also niemals aktuell, da die Bugs in regelmäßigen Abständen gefixt werden.
Ausserdem gibt es sehr viele Hersteller von JVMs und Java Klassenbibliotheken, jede hat ihre eigenen Bugs aber für das Client Programm macht es keinen Unterschied.

 

[SlaterB]

aber sowas wie ein BufferOverflow ist doch kein einzelner Bug sondern ein konkretes Sicherheits-Un-Feature (oder Unsicherheits-Feature ),
das für alle Zeiten in einer Sprache interessant bleiben wird, die es hat,

um solche Dinge gehts wohl hauptsächlich, und die passen dann auch in Bücher?

 

[Gast]

Hey SlaterB

Du rederst bisschen viel

 

[moormaster]

Zu so einem Thema gabe es zum letzten Chaos-Congress nen Vortrag:

http://events.ccc.de/congress/2007/Fahrplan/events/2247.en.html

 

[Wildcard]

aber sowas wie ein BufferOverflow ist doch kein einzelner Bug sondern ein konkretes Sicherheits-Un-Feature (oder Unsicherheits-Feature ),
das für alle Zeiten in einer Sprache interessant bleiben wird, die es hat,

Wo soll der auftreten? Doch nur in der VM selbst, oder den nativ implementierten Methoden. Beides kann (und wird) problemlos ersetzt werden solange die Schnittstelle sich nicht verändert.

 

[moormaster]

... und auch bei C/C++ gibt es compiler, die gegen bestimmte Angriffe Schutzmaßnahmen einbauen... zum Beispiel gibt es beim gcc die Möglichkeit, einen Stack-Protector zu aktivieren, der verhindern kann, dass überlaufende lokale Puffer die Rücksprungadresse verändern.

 

[SlaterB]

ich meine immer noch was anderes,

bei Cxy oder sonst einer Sprache gibt es Pointer,
das bedeutet, dass es dort eine prinzipielle Fehlerursache 'BufferOverflow' gibt,
nicht in Programm X oder Bibliothek Y sondern generell in der gesamten Sprache,

selbst wenn man erst in 10 Jahren ein Programm Z schreiben wird,
dann kann man heute schon wissen, dass man dann daran denken muss

anderes Beispiel: Problem SQL-Injections, welches auch Java immer haben wird,
solange man SQL-Strings im Programm per String-Konkatenation zusammenbauen kann

es geht nicht um irgendeine bestimmte Stelle, irgendeinen Bug 453 im Bug-Log,
sondern um allgemeine Sicherheits-Eigenschaften (wenn ich es richtig interpretiere)

 

[moormaster]

Man kann in jeder Sprache schlechte Programme schreiben, die nicht immer das machen, was sie sollen...

 

[SlaterB]

aber in Java keine Bufferoverflows haben, jedenfalls nicht im herkömmlichen Sinne

 

[Wildcard]

Aber welche sind das im Falle von Java?
Pointer -> gibt es nicht für den Entwickler
Speicher -> gibt es nicht für den Entwickler
SQL-Injection -> PreparedStatements/Frameworks
Im Fall von SQL ist es übrigens tatsächlich wieder ein Problem der Bibliothek, nicht der Sprache.
Für Java wüsste ich, bei perfekter VM/API Implementierung keinen Ansatzpunkt.

 

[SlaterB]

ich sag nicht, dass ich eine Antwort weiß,
ich weise nur darauf hin, dass das mehrfache 'siehe Bugs/ Bücher gibts nicht' irgendwie am Thema vorbei geht, meiner Meinung nach

 

[Wildcard]

ich sag nicht, dass ich eine Antwort weiß,
ich weise nur darauf hin, dass das mehrfache 'siehe Bugs/ Bücher gibts nicht' irgendwie am Thema vorbei geht, meiner Meinung nach

Aber genau darauf läuft es doch hinaus. Die bekannten Schwachstellen sind allesamt Bugs.

 

[moormaster]

Nunja im Falle von C/C++ und dem Überschreiben von Rücksprungadressen sind es aber zum Beispiel keine Bugs, sondern Probleme, die sich aus der Calling Convention für Funktionen ergeben... diese Calling Convention wird ja Linux-weit eingehalten ^^

 

[Wildcard]

Schon klar, aber es geht speziell um Java und Java läuft sozusagen auf einem eigenen virtuellen Rechner. Wenn der virtuelle Rechner eine perfekte Umsetzung der Spec ist, gibt es keine solchen Probleme, ergo ist alles andere eine Abweichung von der Spezifikation und daher ein Bug.

 

[xdavidx]

Schon klar, aber es geht speziell um Java und Java läuft sozusagen auf einem eigenen virtuellen Rechner. Wenn der virtuelle Rechner eine perfekte Umsetzung der Spec ist, gibt es keine solchen Probleme, ergo ist alles andere eine Abweichung von der Spezifikation und daher ein Bug.

Ist die JVM eine perfekte Umsetzung?

 

[maki]

Ist die JVM eine perfekte Umsetzung?Ist die JVM eine perfekte Umsetzung?

Ja klar, bis auf die Bugs eben... :roll:

 

[xdavidx]

http://www.infosecblog.org/2004/09/sun-jvm-exploit.html

 

[xdavidx]

Also wäre es sinnvoller soweit möglich Software in Java zu schreiben weil die Sicherheit mehr gegeben ist als bei C++?

 

[maki]

Ja.

 

[xdavidx]

Stimmen dem alle zu?

 

[maki]

In einem Javaforum? Bestimmt

 

[SlaterB]

hey, in Java gibts einen SecurityManager,
welche sonstige Sprache hat den schon?

 

[Gast2]

Moin,

hey, in Java gibts einen SecurityManager,
welche sonstige Sprache hat den schon?

öhm .NET?

In einem Javaforum? Bestimmt

da ich Java im Moment nur private einsetze und vorwiegend mit .NET arbeite, erlaube ich mir die Aussage zu erweitern ... mit Managed Sprachen (Java/.NET/$WHATEVER) ist es immer sicherer (sofern kein Bug vorliegt) als mit nativen Sprachen

hand, mogel

 

[xdavidx]

da ich Java im Moment nur private einsetze und vorwiegend mit .NET arbeite, erlaube ich mir die Aussage zu erweitern ... mit Managed Sprachen (Java/.NET/$WHATEVER) ist es immer sicherer (sofern kein Bug vorliegt) als mit nativen Sprachen

:toll:

Das gute ist die Bugs in Java scheinen fast garnichts für Exploits herzugeben bzw. die Bösen befassen sich nicht richtig damit!

Java ist toll.

 

[Wildcard]

Das gute ist die Bugs in Java scheinen fast garnichts für Exploits herzugeben bzw. die Bösen befassen sich nicht richtig damit!

Weil es nur wenig nativen Code gibt und die VM sehr 'mature' und hervorragend getestet ist. Aber es gab natürlich schon Exploits. Insbesondere bei Applets um aus der Sandbox auszubrechen.