Inventar
-
hustbaer schrieb:
DER Klassiker ist der "unchecked buffer".
Ja das Problem kenn ich zu gut. Hab schon ein paar mal damit Kämpfen müssen. Aber mit der Zeit lernt man glaub ich, wie man diese Fehler nicht mehr macht.
-
Nur weil ich mir nicht sicher bin ob dir das Ausmass des Problems "unchecked buffer" klar ist...
Das "interessante" dabei ist nicht dass dadurch das Programm z.B. abkacken kann.
Das "interessante" dabei ist dass man dadurch ausführbaren Code in z.B. Datenfiles, oder auch Nachrichten die man an einen Server schickt, "verpacken" kann, so dass die "verarbeitung" dieser Files/Nachrichten dazu führt dass der "verpackte" Code ausgeführt wird.
Wenn ich z.B. weiss dass du Programm X zum Angucken von JPEG Files verwendest, und weiss dass Programm X so ein unchecked Buffer Problem hat...
Dann kann ich dir ein speziell präpariertes JPEG File schicken, das dir deine Festplatte formatiert (sobald du es in Programm X aufmachst)
Besonders blöd ist das wenn Programm X z.B. eine Gruppe vieler Windows Anwendungen (Outlook, Outlook Express, Explorer, Internet Explorer, ...) ist, und es wirklich um JPEG Files geht. Die ja in Emails und auch im Web bekanntlich nur extremst selten anzutreffen sind, und daher sofort Verdacht erregen.
Was übrigens nicht erfunden ist
-
Ok, nee das habe ich nicht gewusst. Das ist ja echt übel! Kann ein unchecked puffer eigentlich auch aus welchen Grund auch immer beim Kompilieren unbemerkt bleiben?
-
tomy86 schrieb:
Kann ein unchecked puffer eigentlich auch aus welchen Grund auch immer beim Kompilieren unbemerkt bleiben?
Nein, das kann nicht sein, das ist ganz sicher so.
-
@tomy86
Willst du mich jetzt verarschen?
Natürlich kann der unbemerkt bleiben. Oder meinst du dass alle Firmen die auf Grund von unchecked Buffers verwundbare Produkte ausgeliefert haben das einfach nur absichtlich ignoriert haben?
-
@OP
Vielleicht möchtest du dir das hier mal angucken: RakNet. Ist eine MultiPlayer Network Engine, die jetzt wohl Open Source ist.
-
Buffer-Overflow attacks sind immer noch nen Ding?
Also, in praktischer Realität?!
-
Wut schrieb:
Buffer-Overflow attacks sind immer noch nen Ding?
Also, in praktischer Realität?!
also als erstes geht es hier ja eig um ein praktisch relevantes beispiel
...desweiteren ließ hier mal die ersten Zeilen :
http://de.wikipedia.org/wiki/Pufferüberlaufvll ist dir dann logisch warum das theoretisch wie praktisch relevant ist
...
für die meisten ist das ja "unrelevante" theorie
...lg
-
für die meisten ist das ja "unrelevante" theorie
...den satz hab ich vergessen weg zu machen.
der hat keine bedeutung und kein sinn,
entschuldigung für den doppel-post, aber edit geht nicht.lg
-
hustbaer schrieb:
@tomy86
Willst du mich jetzt verarschen?
Natürlich kann der unbemerkt bleiben. Oder meinst du dass alle Firmen die auf Grund von unchecked Buffers verwundbare Produkte ausgeliefert haben das einfach nur absichtlich ignoriert haben?Die Frage stellte sich mir, weil VS sich ja "eigentlich" bei mir immer beschwert hat. Was ich somit meine ist, unter welchen Voraussetzungen das unbemerkt bleiben kann, und wie man es am besten überprüfen kann?
-
Meh, hört sich für mich eher wie eine uneducated guess Aussage an.
Gleiche wie alle immer Sagen 90% der Websites wären XSS-gefährdet.
Ist doch in heutiger Zeit, wo jede Website auf irgendeinem fertigen Framework aufbaut, totaler Blödsinn.
-
@tomy86
Wenn du die ganzen "..._s" Funktionen meinst...
Erstmal ist es in vielen Projekten quasi unmöglich einfach mal so alle Warnings die da ausgespuckt werden zu fixen indem man auf die "..._s" Funktionen umstellt. Sei's weil es einfach zu viele sind, oder weil das Projekt nicht nur mit VS compilierbar sein muss sondern auch mit anderen Compilern.
Die "Lösung" ist dann meist dass man diese Warnings deaktiviert (_CRT_SECURE_NO_WARNINGS, _SCL_SECURE_NO_WARNINGS).Weiters meckert VS hier natürlich nur für eigene Funktionen. Wenn man selbst irgendwo unsichere Kopierschleifen schreibt meckert VS nicht. Weil es nicht "versteht" dass man hier ein unsicheres Konstrukt gebaut hat. Die Warnings die VS bei Funktionen wie
std::strcpyliefert, werden ja nur ausgespuckt, weil alle "potentiell problematischen" Funktionen, für die es "..._s" Alternativen gibt, speziell in den Header Files "markiert" sind.Und davon abgesehen wird halt auch lange nicht jedes Programm mit VS compiliert. Selbst bei den Windows Programmen gibt es noch viel wo z.B. GCC (MinGW & Co.) zum Einsatz kommt.
Es gibt natürlich Static-Analysis Tools die solche Fehler finden können. Aber die verwendet ja leider auch kaum jemand.
-
wut schrieb:
Meh, hört sich für mich eher wie eine uneducated guess Aussage an.
Gleiche wie alle immer Sagen 90% der Websites wären XSS-gefährdet.
(...)Was meinst du jetzt?
Was genau soll hier ein "uneducated guess" sein?
-
hustbaer schrieb:
wut schrieb:
Meh, hört sich für mich eher wie eine uneducated guess Aussage an.
Gleiche wie alle immer Sagen 90% der Websites wären XSS-gefährdet.
(...)Was meinst du jetzt?
Was genau soll hier ein "uneducated guess" sein?Die Aussage aus Wikipedia, dass es immer noch eine so dramatisch breit vertretene Sicherheit-Lücke wäre.
Meinetwegen wenn man die ganze uralt Software berücksichtigt. Aber Software, die in einem angemessenem Rahmen entwickelt worden sind werden wohl kaum noch sonderlich häufig anfällig gegenüber Buffer-Overflow attacks sein.
Das klingt einfach viel zu sehr nach einer über-Dramatisierung dieses Problems.
-
wut schrieb:
Die Aussage aus Wikipedia, dass es immer noch eine so dramatisch breit vertretene Sicherheit-Lücke wäre.
Ah, OK. Ich dachte nämlich erst du beziehst das auf etwas was hier in diesem Thread geschrieben wurde.
wut schrieb:
Meinetwegen wenn man die ganze uralt Software berücksichtigt. Aber Software, die in einem angemessenem Rahmen entwickelt worden sind werden wohl kaum noch sonderlich häufig anfällig gegenüber Buffer-Overflow attacks sein.
Das klingt einfach viel zu sehr nach einer über-Dramatisierung dieses Problems.
Die Frage ist: was ist ein angemessener Rahmen?
Aber so ziemlich egal wie die Antwort auf diese Frage ausfällt: ich würde auch schätzen dass das immer noch ein echtes Problem darstellt. Software die mit MSVC kompiliert wurde wird dank diverser Technologien wie /GS ("Buffer Security Check") vielleicht nicht mehr so schlimm anfällig sein. Aber das generell als Problem von gestern abzutun... pfuh, mutig.
Mir passiert es selbst öfter dass ich diverse Probleme die für mich sein vielen Jahren keine mehr sind als "das ist ja kein Problem" abtue. Stimmt aber oft genug nicht. Viele Dinge sind nur für mich kein Problem mehr, weil ich die Fehler selbst gemacht und dann (hoffentlich gut) daraus gelernt habe. Andere, speziell neue, jüngere Programmierer, denen diese Erfahrung fehlt, machen heute aber oft die selben Fehler wie ich for 10 Jahren.
Wenn man sich das nicht immer wieder vor Augen hält, kann man schnell in die falsche Vorstellung verfallen dass "Leute die halbwegs Hirn haben" diesen oder jenen Fehler "gar nicht machen können".
Langer Rede kurzer Sinn: so lange mir keiner zeigt dass auch Compiler wie GCC, Clang, Intel C++ und Embarcadero Unchecked Buffer Bugs mit guter Sicherheit durch diverse Runtime Checks erschlagen, bleibe ich mal weiterhin sehr skeptisch.
(Und auch dann bleibt noch ein ausreichend grosser Teil von Software übrig der mit anderen Compilern gebaut wird. Wobei das dann vermutlich weniger Programme sein werden mit denen Otto-Normalverbraucher viel zu tun hat.)
