# Java und Sicherheit?



## xdavidx (2. Sep 2008)

Hey,

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

Geht so etwas?

vlg


----------



## SlaterB (2. Sep 2008)

..

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 (2. Sep 2008)

Welche potenziellen Schwachstellen hat Software die in Java geschrieben wurde?

Mich würden euere Erfahrungen interessieren!


----------



## Wildcard (2. Sep 2008)

Schau dir die Bugs an.


----------



## xdavidx (2. Sep 2008)

Welche Bugs?


----------



## Wildcard (2. Sep 2008)

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


----------



## xdavidx (3. Sep 2008)

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 (3. Sep 2008)

Schau dir die Bugs an.


----------



## Gast2 (3. Sep 2008)

Moin,



			
				xdavidx hat gesagt.:
			
		

> 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 (3. Sep 2008)

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 (3. Sep 2008)

xdavidx hat gesagt.:
			
		

> 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 (3. Sep 2008)

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 (3. Sep 2008)

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 (3. Sep 2008)

Hey SlaterB

Du rederst bisschen viel


----------



## moormaster (3. Sep 2008)

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

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


----------



## Wildcard (3. Sep 2008)

SlaterB hat gesagt.:
			
		

> 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 (3. Sep 2008)

... 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 (3. Sep 2008)

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 (3. Sep 2008)

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


----------



## SlaterB (3. Sep 2008)

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


----------



## Wildcard (3. Sep 2008)

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 (3. Sep 2008)

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 (3. Sep 2008)

SlaterB hat gesagt.:
			
		

> 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 (3. Sep 2008)

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 (3. Sep 2008)

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 (3. Sep 2008)

> 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 (3. Sep 2008)

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


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


----------



## xdavidx (3. Sep 2008)

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


----------



## xdavidx (3. Sep 2008)

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


----------



## maki (3. Sep 2008)

Ja.


----------



## xdavidx (3. Sep 2008)

Stimmen dem alle zu?


----------



## maki (3. Sep 2008)

In einem Javaforum? Bestimmt


----------



## SlaterB (3. Sep 2008)

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


----------



## Gast2 (3. Sep 2008)

Moin,



			
				SlaterB hat gesagt.:
			
		

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


öhm .NET?


			
				make hat gesagt.:
			
		

> 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 (3. Sep 2008)

> 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 (3. Sep 2008)

xdavidx hat gesagt.:
			
		

> 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.


----------

