Wenn das trotz JPA der Fall ist, ist’s sicher ein Framework-Issue. Generell hast du schon recht, das Java als Sprache hier einiges abnnimmt. Aber solange keine Zauberwolke zwischen JVM und Betriebssystem sitzt in der böse Absichten unmöglich sind, bleibt Java als Plattform angreifbar.
dein Stichwort läßt mich gleich nochmal antworten, ich sehe auch selber dass ich mich nur wiederhole und gar schon Zuspruch bekomme 
:
das zum SQL kann kein Fehler sein und kann nicht entfernt werden, weil das eine respektable Funktion ist, die auch gebraucht wird,
wenn ich in der GUI „Select X“ eintippe, muss es auch immer einen Weg geben, das in die DB zu transportieren,
im Falle des Speichers ist es aber einfach, das kann nie zu etwas zu gebrauchen sein (außer extreme Optimierungen unterhalb OO)
daher gilt es in diesem Fall tatsächlich: eine Zauberwolke ist möglich und vorhanden:
man kann nicht mit normalen Java-Befehlen if else modulo int Array-index an Speicher anderer Variablen herankommen,
ich glaube kein Exploit geht in diese Richtung, oder bitte zeigen,
dass man mit 30 Zeilen bösartigen aktiven Angriff SecurityManager/ Reflection/ native-Methodenaufruf/ allocate Speicherbereich/ was auch immer noch irgendwo hinkommt kann da natürlich nicht drunter fallen
das ist ein so simpler wie selbstverständlicher aber dann auch extremer Schutz, eine echte Zauberwolke, es gibt sie! (wenn auch an anderer Stelle, aber dort auch wichtig)
wie kann eine Programmiersprache nur ohne bestehen?
und dann jede einfache offiziell in guter Absicht eingefügte Codezeile einen Jahrhundert-Bug ermöglichen?
Nein.
Am Ende des Tages ist’s dann aber so Bufferoverflow/ReturnToLibC Fehler.
Das stimmt ja leider nicht. Solange man aus der Wolke ausbrechen kann, ist’s weit weg von einer „echten“ Zauberwolke.
Beispiel Beispiel bitte?!
‚ReturnToLibC java‘ findet als erstes
http://lasithh.wordpress.com/2013/06/23/how-to-carry-out-a-return-to-libc-attack/
also wieder vollkommen C-Frage während in Java erstmal unmöglich,
man muss das gar nicht als zweite Zauberwolke anführen, einfach alles was an komischen nicht erlaubten ausgedacht wird gibt es schlicht nicht im normalen Code,
denn der Code und die offizielle Ausführung (jede JVM kann theoretisch auch anders arbeiten) ist in jeder Hinsicht sicher gebaut,
dieser Bau freilich wohl aus schlechter Erfahrung heraus,
aber wenn man sich von null auf eine Programmiersprache ausdenkt, dann kommt man eigentlich auch nicht auf die Idee der Speicher-Pointer oder Stack-Sprünge,
nicht wenn man gleich Objektorientierung im Sinn hat
‚Integer-Overflow‘ gibt es immerhin auch in Java, Alternative Exception?
als Gefahr nicht völlig ohne, aber doch relativ brav im Vergleich
Das stimmt ja leider nicht. Solange man aus der Wolke ausbrechen kann, ist’s weit weg von einer „echten“ Zauberwolke.
wie kann man bitte?, außer durch Angriff auf C+±Implementierungen oder evtl. noch komplizierten Angriffs-Code innerhalb Java?
letzteres will ich auch erstmal noch sehen, aber selbst wenn, dann ist damit ist doch nicht der Eigenschutz der Sprache ausgehebelt
nur weil jemand auch eine Schere dabei haben kann, ist doch nicht ein Netz unter dem Schwebeseil auf einmal sinnlos, sondern voll funktionsfähig
Das ist deine Fehlkonzeption. Der Fehler ist nicht C, der Fehler ist die Hardware-Architektur. Die ist anfällig. Punkt. Schau einfach mal rein, welche Angriffsvektoren es gibt. Da wird einem schlecht. Siehe z.B. diese LVA-Folien.
Wie gesagt. Ich rede von der Plattform. Und genau dort wo die Wolke die Betriebssystemebene berührt ist’s aus. Game Over.
Sagt ja keiner. Es hat nur nicht den Vorteil den du da gerade behauptest im Vergleich zu einer sauberen C-Entwicklungsumgebung. (mit Sicherungsmechanismen, Codeanalyse, etc.)
[QUOTE=schlingel]Das ist deine Fehlkonzeption. Der Fehler ist nicht C, der Fehler ist die Hardware-Architektur. Die ist anfällig. Punkt. Schau einfach mal rein, welche Angriffsvektoren es gibt. Da wird einem schlecht. Siehe z.B. diese LVA-Folien.
[/quote]
ich habe nicht gleich alles gelesen,
bei „String spills out of buffer, overwrites saved return address.“ und natürlich dann dem obligatorischen C-Programm dazu kann ich erstmal aufhören,
das ist doch auch das bekannte Pointer-Problem (für Stack-Programmfluss in der Tat auch sehr interessant) und genau das ist in Java U N M Ö G L I C H ?
(ich setze die Steigerungen von Posting zu Posting ein, um vielleicht doch endlich ein Gegenbeispiel zu bekommen, dann könnte ich meine Meinung korrigieren 
)
edit:
wobei ‚Der Fehler ist nicht C‘ ein zuvor nicht genannter Punkt ist,
halte ich schon für den Fehler von C,
es ist offiziell erlaubt so und so viel Bytes weiteren Speicher zu lesen, warum keine Exception oder ähnliches?
was dahinter im Speicher steht kann man wohl nicht wissen (ich wundere mich auch dass der Bug hier bei OpenSSL wirklich sinnvolle Daten liefern soll),
schon gar nicht bei Festlegung der Programmiersprache, aber irgendwas wird zu lesen sein, das kann man nicht offen lassen
Wie gesagt. Ich rede von der Plattform. Und genau dort wo die Wolke die Betriebssystemebene berührt ist’s aus. Game Over.
das klingt jetzt so als wäre Verschlüsselung von Nachrichten im Internet sinnlos wenn man den lokalen Bildschirm per Trojaner direkt ablesen kann,
man kann nicht die ganze Welt aufeinmal retten,
für eine Programmiersprache ist nur wichtig, dass sie in sich korrekt ist, keine derartigen Bugs einbaut,
andere Ebenen sind andere Fragen
Es hat nur nicht den Vorteil den du da gerade behauptest im Vergleich zu einer sauberen C-Entwicklungsumgebung. (mit Sicherungsmechanismen, Codeanalyse, etc.)
äh ja, da fällt mir dann auch spitzfindig ein:
wenn man mit C an sich aufhört und zu einem Java-ähnlichen C übergeht (alles läßt sich umbiegen, eben die kritischen Befehle verbieten usw.)
dann sicherlich ähnlich gut wie gleich in Java?
Wenn du das „sinnlos“ durch „nicht 100%ig sicher“ ersetzt, dann ist das genau richtig. Das ist einer der Angriffsvektoren, die gegen über das Internet übertragene Daten eingesetzt wird.
Das mit dem „sinnlos“ geht an @schlingel s Argumentation vorbei:
Es geht hier um die theoretische Sicherheit. Und Java ist nicht 100%ig sicher, weil die darunter liegende Architektur eben „gefährliche“ Operationen erlaubt (die aber in vielen Fällen benötigt werden).
[quote=SlaterB;92116]wenn man mit C an sich aufhört und zu einem Java-ähnlichen C übergeht (alles läßt sich umbiegen, eben die kritischen Befehle verbieten usw.)
dann sicherlich ähnlich gut wie gleich in Java?[/quote]
Das trifft den Kern der Sache schon eher. Wenn man sich den OpenBSD gcc mal ansieht, dann stellt man dort einige Anpassungen fest. Es werden bei malloc, strcpy und Konsorten Warnings geworfen und OpenBSD spezifische Alternativen empfohlen.
[QUOTE=cmrudolph]Wenn du das “sinnlos” durch “nicht 100%ig sicher” ersetzt, dann ist das genau richtig. Das ist einer der Angriffsvektoren, die gegen über das Internet übertragene Daten eingesetzt wird.
[/QUOTE]
aber es stellt sich dann doch die Frage nach dem Sinn solcher Aussagen?
meine Bank kann mir den Kontostand auf einer Postkarte schicken und ich bin empört,
oder sie nimmt einen Brief, ob noch mit lustigen schwarz-weiß-Krisselpapier oder nicht, in jedem Fall eine sinnvolle erste Maßnahme
natürlich ist auch dies wie jeder Mega-Tresor-Kurierdienst nie 100%ig sicher…,
für das beabsichtigte Ziel ‘ohne Manipulation mit bloßen Auge nichts zu erkennen’ aber genau richtig funktional,
so wie Java-Code das beabsichtigte Ziel ‘keinerlei falsche Speicherzugriffe direkt im Quellcode selbst ausgelöst’ ohne Wenn und Aber erfüllt
von
[quote=mogel;91920]Es ist egal welche Sprache verwendet wird,[/quote] zu nun “nicht 100%ig sicher” wäre aber schon ein Fortschritt, puh
Der Sinn ist es falsche Sicherheitsversprechen zu enttarnen. Nur weil ein bestimmter Angriffsvektor entschärft (allerdings nicht völlig ausgeschaltet, siehe Plattformproblematik)
Der Punkt dabei ist - wie gesagt - dass es eben gleich sichere Lösungen in anderen Sprache gibt die Hardware nahe Programmierung zulassen. Der Effekt ist der gleiche.
Ändert aber nichts, dass man nicht dennoch die VM knacken kann. Muss dann eben über Umwege passieren indem man sich z.B. ein JAR in den Temp-Files erstellt und dann diese ausführen lässt um einzubrechen. Genau so in Java möglich.
‚geben könnte‘ statt ‚gibt‘, wie man sieht hier in diesem wichtigen Programm in dieser Programmiersprache nicht der Fall,
wäre es in Java programmiert müsste man über einen solchen Fehler gar nicht erst nachdenken,
konzeptionelle Sicherheit vs ‚hoffentlich gut programmiert‘ ist schon ein gewisser Unterschied,
aber natürlich nur auf diesen Punkt Speicherzugriff bezogen,
dämliche normale Befehle kann man überall einbauen, da muss man bei allen Programmiersprachen auf einigermaßen fähige Programmierer hoffen
Ändert aber nichts, dass man nicht dennoch die VM knacken kann. Muss dann eben über Umwege passieren indem man sich z.B. ein JAR in den Temp-Files erstellt und dann diese ausführen lässt um einzubrechen. Genau so in Java möglich.
das soll mal jemand schaffen,
entweder einen Bug direkt im Programm mit ganz normalen Protokoll-Befehl ausnutzen,
wie JEDER Webserver mit entsprechender OpenSSL-Version weltweit antwortet, ob Dummy-Home-Windows-Hoster oder Mega-Krypto-Server,
oder im Falle Java komplizierten Zugriff auf das System erlangen, Jar-Dateien unterjubeln oder wer weiß was alles,
eigentlich muss man SSL dann gar nicht mehr angreifen, hat schon Komplettzugriff
ich werde heute wohl nicht mehr das Argument an sich verstehen, wieso man zu einer morschen Holzbrücke sagt
‚ja aber, eine 500 Mio.-Stahlbrücke bringt ja nun auch nicht mehr Sicherheit, man nehme nur ein Erdbeben der Stärke 9 und schwupps genauso unsicher‘
[quote=SlaterB]wieso man zu einer morschen Holzbrücke sagt
‚ja aber, eine 500 Mio.-Stahlbrücke bringt ja nun auch nicht mehr Sicherheit, man nehme nur ein Erdbeben der Stärke 9 und schwupps genauso unsicher‘[/quote]
Das hat niemand behauptet. Eher, dass man den Bequemlichkeit und Sicherheit eines Kombis nicht so einfach mit einem Formel 1 Wagen vergleichen kann. Klar ist ersteres bei einem Unfall sicherer aber das heißt noch lange nicht, dass bei zweiterem die Ingenieurleistung weniger ist. Und so lange ein Verbrennungsmotor verwendet wird, wird es zu Problemen kommen die mit einem Verbrennungsmotor zu tun haben.
Das wurde geschafft…
Da hast du schon recht. Das geht in Java nur über Umwege und nicht direkt im Code.
Ja, das stimmt. Ändert aber nichts an deiner übertriebenen Bewertung der Sicherheit der darin geschriebenen Systeme.
Eigentlich geht so etwas auch nicht, denn die Anwendung würde bei so etwas abstürzen (Stichwort ASLR, etc.), weil dabei die Sicherheitsrichtlinie des Betriebssystem umgangen wird. Die OpenSSL Entwickler haben aber durch die Entwicklung eines eigenen Speicherallokators die Sicherheitsrichtlinie des Betriebssystem umgangen. Dies führt dazu, dass die Software bei einem Zugriff auf einen illegalen Speicherbereich nicht abstürzt und dadurch es nicht auffällt, dass Private Keys gestohlen wurden. Menschliches Versagen ist Schuld an diesem Bug. (Der größte Bug sitzt vor dem Computer.)
da ich es jetzt erst lese
[quote=SlaterB]wobei ‘Der Fehler ist nicht C’ ein zuvor nicht genannter Punkt ist,
halte ich schon für den Fehler von C,
es ist offiziell erlaubt so und so viel Bytes weiteren Speicher zu lesen, warum keine Exception oder ähnliches?[/quote]
der Sinn von C ist es eine Speicheradresse direkt adressieren zu können. Ein malloc() liefert irgendwo Speicher der frei ist, RAM. Es ist aber auch nötig direkt auf Register/Adressen der CPU oder weitere Peripherie zuzugreifen. Sont wären Treiber für Hardware gar nicht möglich.
Meeeeh, könnt ihr das Sprachenbashing endlich aufhören, oder könnte das wenigstens in einen Thread abgesplittet werden?
Btw. es ist klar, das es OpenSSL ein wenig an Commitern fehlt, wenn ich mir z.B. meine aktuellen Sachen anschaue wo ich ab und zu mal nen Pull-Request sende, wie z.B. Sylius, ist da wirklich viel los. OpenSSL ist halt historisch gewachsen, sehr viel Makrostuff und sich da erst mal einarbeiten kostet Zeit. Und es fehlt die Testabdeckung…
Und wenn man, dann noch mal schaut, was der werte Hearbleed-Typ noch in OpenSSL eingecheckt hat… Wieder ein Bug ^^ Siehe http://blog.fefe.de/?ts=adb56ec9
Immer dieses nachbohren, fingerzeigen, bloßstellen… Wer drauf steht. Übrigens ist dieser Umgangston auch ein Grund, warum ich mich bei Mitarbeit an OSS schwer tue.
Auch in den Medien gab es ein paar wenige Versuche die Schuld auf einen einzelnen abzuladen (Typisch Deutsch: Wenn das Haus brennt klären wir erst mal wer schuld ist, bevor wir löschen). Fakt ist, Entwickler sind Menschen und Menschen machen Fehler. Wenn du jetzt kleiner Programmierer in einem Betrieb bist, dann ärgert dein Fehler 20-200 Leute, du fixt ihn und das war es. Wenn dir so etwas in einer Software für Kunden passiert, hast du einen wütenden Kunden und eine schwer/umständlich/nicht benutzbare Software ausgerollt, du fixt es und gut ist. Auf reddit.com/r/programming gab es da einen schönes Zitat zu: „Der einzige Grund, warum noch keiner von uns so einen Mist gebaut hat ist, dass wir nicht die Gelegenheit dazu hatten“. Ich würde mich bedanken, wenn mein Chef mich alleine an so ein riesiges Projekt setzt, dann noch einen anderen Mitarbeiter grob drüberschauen lässt und es dann ausrollt.
Wenn dann ein Fehler drinnen ist, wer ist Schuld? Der Entwickler? Der Reviewer? Oder der Projektplaner?
Hehe, klar ist fefe etwas reiserisch in dieser Hinsicht, aber ja, nur der Typ hat sich nie wirklich dafür entschuldigt… Eher so “ja war ein Fehler kann passieren, mir aber egal”. Er steht, wie typisch Deutscher, nicht zu seinen Fehler.
In dem Fall hat auch der Reviewer mitschuld. Ich mein IMHO hat der Fix für einen Bug dann ein DDoS zugelassen…
funktional irgendwo im Computer unumgänglich und wichtig, auch Java braucht ja letztlich den Zugriff für Aufbau eines Speichermanagements,
für Programmierung von JVM und jede sonstige Grundlage richtig
nur man darf mit solchen Experimentaltools keine hochempfindlichen Anwendungen wie OpenSSL schreiben! ist ja auch gar nicht nötig,
für eine Programmiersprache außerhalb von hardwarenahen Treiber und noch Extrem-optimierten Rechnungen, jahrelange dieselben 10 Zeilen Code, diese dann auch 30x geprüft,
ist das ein nicht akzeptabler Zustand
Analogie des Tages:
Strom kommt aus kleinen bunten Drähten, aber wer im Anzug im Büro daran rumspielt kommt bei einem Bug (Kurzschluss) in Teufels Küche,
es gibt genormte Schaltdosen, die alle Drähte verdecken, die hat man zu nutzen,
falls es in den unteren Ebenen was zu tun gibt dann holt man den Elektriker nur für den Sicherungskasten,
genau wie C-Programmiersprache maximal für Implementierung der Speicherverwaltung einer Hochsprache
über Absplitten kann man nachdenken, aber ist schon sehr nahe am Thema, der Kern des Problems/ des Bugs
wo gibts das bei einem Java-Programm? gruselig
interessant, widerspricht aber ein wenig allen allgemeinen Links/ Beispielen im Internet,
ohne es detailliert zu verstehen auch hier z.B. anscheinend ein Programm was jeder hinbekommt
da steht nichts a la ’ Sicherheitsrichtlinie des Betriebssystem extra umgangen’, ganz normales Programm
auch zum Posting von mogel gerade, dass es in C eben nötig ist, etwas widersprüchlich
geht wohl wieder zusammen wenn man
voraussetzt,
also wieder der Punkt: bei einem C-Programm weiß man nicht ob es sicher ist, wie man sieht kann es selbst in so dramatisch wichtigen Programmen nicht so sein,
bei Java ist die Sicherheit unumgehbar eingebaut! (hinsichtlich Code, nicht allgemeine Exploits)
ich will eigentlich gar nicht ständig ‚bei C, bei Java‘ vergleichen, aber wenn so viele Gegenaussagen kommen…
und die Hexenjagd hat begonnen - das wird wie Wikipedia, wo Doktoren auch nichts veröffentlichen wollten (weil Reputation und so) und Wikipedia nicht vorwärts kam
[QUOTE=SlaterB]interessant, widerspricht aber ein wenig allen allgemeinen Links/ Beispielen im Internet,
ohne es detailliert zu verstehen auch hier z.B. anscheinend ein Programm was jeder hinbekommt
da steht nichts a la ’ Sicherheitsrichtlinie des Betriebssystem extra umgangen’, ganz normales Programm[/QUOTE]
Okay, mag sein, aber hast du mal versucht dieses Beispiel mithilfe gcc auf Linux auszuprobieren? Ich vermute nein. GCC verwendet einen Stack Protector um vor so ein Buffer Overflow zu schützen. Somit wird das Beispiel nicht ohne den Flag -fno-stack-protector funktionieren. Siehe http://en.wikipedia.org/wiki/Buffer_overflow_protection. Ein kleiner Irrtum meinerseits, das was ich Sicherheitsrichtlinien genannt habe, sind eigentlich Sicherheitsvorkehrungen, denn es gibt im Grunde genommen keine Sicherheitsrichtlinien für Programme.
Moin,
ich schon:
[mschorn@desktop temp]$ uname -a
Linux desktop.lan 3.13.9-200.fc20.x86_64 #1 SMP Fri Apr 4 12:13:05 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[mschorn@desktop temp]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
[mschorn@desktop temp]$ cat test.cpp
#include <iostream>
#include <cstring>
int main( void )
{
int authentication = 0;
char cUsername[ 10 ];
char cPassword[ 10 ];
std::cout << "Username: ";
std::cin >> cUsername;
std::cout << "Pass: ";
std::cin >> cPassword;
if( std::strcmp( cUsername, "admin" ) == 0 && std::strcmp( cPassword, "adminpass" ) == 0 )
{
authentication = 1;
}
if( authentication )
{
std::cout << "Access granted
";
std::cout << ( char )authentication;
}
else
{
std::cout << "Wrong username and password
";
}
return ( 0 );
}
[mschorn@desktop temp]$ gcc -lstdc++ test.cpp
[mschorn@desktop temp]$ ./a.out
Username: 0123456789abcdef1
Pass: wrong!
Access granted
Mit Java wär das nicht passiert.
Viele Grüße
Fancy