metallian1 Geschrieben 11. April 2014 report Geschrieben 11. April 2014 Wahnsinn, wenn man sich mal die simple technische Implementierung des Fehlers anschaut. Ich dachte immer, Open Source ist deshalb so sicher, weil so viele Leute auf den Code gucken. Ein solch zentraler Fehler ist so lange unentdeckt geblieben... Mir vollkommen unverständlich, warum man bei einem simplen Heartbeat ping 16 KB Daten austauschen muß... Und der Empfänger so dämlich ist, einfach seine eigenen Daten (entschlüsselte Passworter, private Keys ) in das Bestätgungspaket zu stopfen, wenn der Sender die Längenangabe des Pakets mutwillig verändert. Unfassbar dämlich von dem Entwickler und den Leuten, die seinen Code nicht Kontrollgelesen haben.
draco2111 Geschrieben 11. April 2014 Autor report Geschrieben 11. April 2014 (bearbeitet) Ich dachte immer, Open Source ist deshalb so sicher, weil so viele Leute auf den Code gucken. Wird immer gesagt. Ich habe das schon immer angezweifelt. Wirklich sicher ist aber eh nichts... Bearbeitet 11. April 2014 von draco2111
Bernward Geschrieben 11. April 2014 report Geschrieben 11. April 2014 Wahnsinn, wenn man sich mal die simple technische Implementierung des Fehlers anschaut. Ich dachte immer, Open Source ist deshalb so sicher, weil so viele Leute auf den Code gucken. Ein solch zentraler Fehler ist so lange unentdeckt geblieben... Mir vollkommen unverständlich, warum man bei einem simplen Heartbeat ping 16 KB Daten austauschen muß... Und der Empfänger so dämlich ist, einfach seine eigenen Daten (entschlüsselte Passworter, private Keys ) in das Bestätgungspaket zu stopfen, wenn der Sender die Längenangabe des Pakets mutwillig verändert. Unfassbar dämlich von dem Entwickler und den Leuten, die seinen Code nicht Kontrollgelesen haben. Der Empfänger gibt das zurück was er empfangen hat (davon geht er nach der Längenangabe aus). Dass defensives Programmieren anders aussieht wissen wir alle. Was in dem Speicherbereich steht, ist Glück- (bzw. Pech-)sache Mit Begriffen wie unfassbar dämlich würde ich sehr vorsichtig sein. Ich möchte nicht wissen, was Dir schon alles passiert ist. Dass noch niemand den Fehler früher bemerkt hat ist schon verwunderlich.
metallian1 Geschrieben 12. April 2014 report Geschrieben 12. April 2014 Wahnsinn, wenn man sich mal die simple technische Implementierung des Fehlers anschaut. Ich dachte immer, Open Source ist deshalb so sicher, weil so viele Leute auf den Code gucken. Ein solch zentraler Fehler ist so lange unentdeckt geblieben... Mir vollkommen unverständlich, warum man bei einem simplen Heartbeat ping 16 KB Daten austauschen muß... Und der Empfänger so dämlich ist, einfach seine eigenen Daten (entschlüsselte Passworter, private Keys ) in das Bestätgungspaket zu stopfen, wenn der Sender die Längenangabe des Pakets mutwillig verändert. Unfassbar dämlich von dem Entwickler und den Leuten, die seinen Code nicht Kontrollgelesen haben. Der Empfänger gibt das zurück was er empfangen hat (davon geht er nach der Längenangabe aus). Dass defensives Programmieren anders aussieht wissen wir alle. Was in dem Speicherbereich steht, ist Glück- (bzw. Pech-)sache Mit Begriffen wie unfassbar dämlich würde ich sehr vorsichtig sein. Ich möchte nicht wissen, was Dir schon alles passiert ist. Dass noch niemand den Fehler früher bemerkt hat ist schon verwunderlich. Es geht nich darum, dass das mir passiert ist oder nicht. Klar hab ich beim Entwickeln dämliche Fehler in meinen Code eingebaut. Aber da ging es um harmlose Sachen. Wir reden hier über ein absolutes DEFCON 5 Projekt. Wie gesagt, ich kenne mich mit SSL und TLS (darum ging es ja hier) Entwicklung nicht aus, aber mir ist trotzdem nicht klar, warum man 16 KB Daten austauschen muß , um sich gegenseitig zu sagen, dass man noch lebt?
Akeem al Harun Geschrieben 12. April 2014 report Geschrieben 12. April 2014 Wahnsinn, wenn man sich mal die simple technische Implementierung des Fehlers anschaut. Ich dachte immer, Open Source ist deshalb so sicher, weil so viele Leute auf den Code gucken. Ein solch zentraler Fehler ist so lange unentdeckt geblieben... Das ist a) kein Automatismus und b) der Optimalfall. Was Open Source von Closed Source unterscheidet ist, dass zumindest die generelle Möglichkeit besteht, dass es unabhängig reviewed werden kann.
Sulvahir Geschrieben 13. April 2014 report Geschrieben 13. April 2014 XKCD hat den Bug mal wieder treffend dargestellt
metallian1 Geschrieben 14. April 2014 report Geschrieben 14. April 2014 XKCD hat den Bug mal wieder treffend dargestellt Grossartige, auch für Laien verständliche Darstellung. @Akeem: Das Argument habe ich erwartet, aber auf der anderen Seite führt das auch dazu, dass die "falsche Seite" es recht einfach hat, Fehler in Systemen zu finden und auszunutzen. Man ist nicht auf Trial-and-Error Versuche angewiesen wie gegen System, bei denen man keine Einsicht in den Quellcode hat und auch nicht dekompilieren kann. Und wenn das Argument zählt, wieso dauert es fast 2 Jahre, bis jemand diesen elementaren Fehler entdeckt?
Akeem al Harun Geschrieben 14. April 2014 report Geschrieben 14. April 2014 @Akeem: Das Argument habe ich erwartet, aber auf der anderen Seite führt das auch dazu, dass die "falsche Seite" es recht einfach hat, Fehler in Systemen zu finden und auszunutzen. Man ist nicht auf Trial-and-Error Versuche angewiesen wie gegen System, bei denen man keine Einsicht in den Quellcode hat und auch nicht dekompilieren kann. Und wenn das Argument zählt, wieso dauert es fast 2 Jahre, bis jemand diesen elementaren Fehler entdeckt? Weil es a) kein Automatismus und b) der Optimalfall ist. Ich hatte angenommen, mit diesen beiden Aussagen ausgedrückt zu haben, dass es eben nicht überall so läuft. Auch an sicherheitsrelevanten Stellen. Das Argument, man habe es bei Open Source leichter, Fehler zu finden und das gelte auch für die Gegenseite ist ebenfalls ein altes Argument, welches im oben angeführten Optimalfall gar nicht eintreffen sollte. Nicht umsonst gibt es bei Open Source Beta-Phasen, die dazu führen sollten, zumindest die sicherheitsrelevanten Fehler in der Beta-Phase zu entdecken, nicht erst nach jahrelangem Betrieb. Wie wir sehen, ist das in der Praxis weder bei Open Source noch bei Closed Source immer der Fall. Ein weiterer Faktor der nicht zu unterschätzen ist, ist die Verbreitung einer Software. Fehler zu finden macht für Profis nur für Software Sinn, die eine bestimmte Verbreitung erreicht haben - oder wie im Fall von Stuxnet an gewissen, sicherheitskritischen Stellen eingesetzt werden. Daher sollte (!) weit verbreitete Software wie Open SSL immer gut reviewed werden, bevor ein neues Release den Produktionsstatus erreicht. Das ist ebenfalls wie wir gelernt haben weder bei Open noch bei Closed Source immer gegeben. Open oder Closed Source ist, wie wir in der vergangenen Jahren gelernt haben, beides keine Garantie dafür, dass Sicherheitslücken nicht zuerst von den "falschen" gefunden und ausgenutzt werden. Wenn man deiner Argumentationslinie folgt hieße das, dass am Ende des Tages Open Source keine Daseinsberechtigung habe, oder zumindest nur in sicherheitstechnisch unbedenklichen Fällen. Das sehe ich allerdings absolut anders.
Sulvahir Geschrieben 14. April 2014 report Geschrieben 14. April 2014 @Akeem: Das Argument habe ich erwartet, aber auf der anderen Seite führt das auch dazu, dass die "falsche Seite" es recht einfach hat, Fehler in Systemen zu finden und auszunutzen. Man ist nicht auf Trial-and-Error Versuche angewiesen wie gegen System, bei denen man keine Einsicht in den Quellcode hat und auch nicht dekompilieren kann. Und wenn das Argument zählt, wieso dauert es fast 2 Jahre, bis jemand diesen elementaren Fehler entdeckt? Fefe erklärt, warum er OpenSSL nicht auditiert hat. Wenn er sich das schon nicht freiwillig antut, dann werden andere das noch weniger können und wollen. Unabhängig davon, ob ein möglicher Fehler behoben oder ausgenutzt werden soll; der Aufwand einen Fehler zu finden ist beide Male der gleiche.
Lukarnam Geschrieben 14. April 2014 report Geschrieben 14. April 2014 (bearbeitet) Wer Algorithmentheorie beherrscht und Korrektheitsbeweise von Algorithmen anwenden kann, der mag sich gleich mal bei Flugzeugherstellern, AKW- Softwareentwicklern usw. bewerben. Die zahlen gute 6-stellige Gehälter für anerkannte Experten. Weil's kaum einer kann oder kaum einer so irre ist, mathematisch und vollständig zu beweisen, das eine wenn-dann-sonst Anweisung oder eine solange (wahr) Schleife oder eine 1=1 Anweisung deterministisch und gültig ist. Und dazu noch das Risiko der Gewährleistung auf sich zu nehmen. Außerdem dauert der Beweis einer Software mit Tausenden / Millionen von Zeilen Code länger als die Veröffentlichung des nächsten Upgrades. In der Pharma- IT dürfen wir Softwarekomponenten "validieren". Der Validierungs- Aufwand für einen 20 zeiler Quellcode (z.B. ein FTP Skript in unix/bash zur Datenübertragung zwischen zwei internen Rechnern) sind ca. 200 Seiten formales Papier. Warum? [ _ ] Weil es Spaß macht [ _ ] Behörden das so wollen Bearbeitet 14. April 2014 von Lukarnam
Akeem al Harun Geschrieben 14. April 2014 report Geschrieben 14. April 2014 Außerdem halte ich es für albern, wenn einer strikter Verfechter von Open oder Closed Source Software ist. Beide Ansätze haben ihre Daseinsberechtigung.
Lukarnam Geschrieben 14. April 2014 report Geschrieben 14. April 2014 Außerdem halte ich es für albern, wenn einer strikter Verfechter von Open oder Closed Source Software ist. Beide Ansätze haben ihre Daseinsberechtigung. Was!? Atari war schon immer besser als Amiga!
Bernward Geschrieben 14. April 2014 report Geschrieben 14. April 2014 Wer Algorithmentheorie beherrscht und Korrektheitsbeweise von Algorithmen anwenden kann, der mag sich gleich mal bei Flugzeugherstellern, AKW- Softwareentwicklern usw. bewerben.Die zahlen gute 6-stellige Gehälter für anerkannte Experten. Weil's kaum einer kann oder kaum einer so irre ist, mathematisch und vollständig zu beweisen, das eine wenn-dann-sonst Anweisung oder eine solange (wahr) Schleife oder eine 1=1 Anweisung deterministisch und gültig ist. Und dazu noch das Risiko der Gewährleistung auf sich zu nehmen. Außerdem dauert der Beweis einer Software mit Tausenden / Millionen von Zeilen Code länger als die Veröffentlichung des nächsten Upgrades. In der Pharma- IT dürfen wir Softwarekomponenten "validieren". Der Validierungs- Aufwand für einen 20 zeiler Quellcode (z.B. ein FTP Skript in unix/bash zur Datenübertragung zwischen zwei internen Rechnern) sind ca. 200 Seiten formales Papier. Warum? [ _ ] Weil es Spaß macht [ _ ] Behörden das so wollen [ _ ] Behörden daran Spaß haben
Bernward Geschrieben 14. April 2014 report Geschrieben 14. April 2014 Außerdem halte ich es für albern, wenn einer strikter Verfechter von Open oder Closed Source Software ist. Beide Ansätze haben ihre Daseinsberechtigung. Was!? Atari war schon immer besser als Amiga! +1
Gast Geschrieben 14. April 2014 report Geschrieben 14. April 2014 "Beware of bugs in the above code; I have only proved it correct, not tried it." (Donald Ervin Knuth)
Akeem al Harun Geschrieben 15. April 2014 report Geschrieben 15. April 2014 @Akeem: Das Argument habe ich erwartet, aber auf der anderen Seite führt das auch dazu, dass die "falsche Seite" es recht einfach hat, Fehler in Systemen zu finden und auszunutzen. Man ist nicht auf Trial-and-Error Versuche angewiesen wie gegen System, bei denen man keine Einsicht in den Quellcode hat und auch nicht dekompilieren kann. Und wenn das Argument zählt, wieso dauert es fast 2 Jahre, bis jemand diesen elementaren Fehler entdeckt? Fefes Meinung zu dem Thema. Er kommt eher aus der Ecke der Open Source Verfechter. Aber ganz unrecht hat er sicher nicht.
metallian1 Geschrieben 15. April 2014 report Geschrieben 15. April 2014 Wenn man deiner Argumentationslinie folgt hieße das, dass am Ende des Tages Open Source keine Daseinsberechtigung habe, oder zumindest nur in sicherheitstechnisch unbedenklichen Fällen. Das sehe ich allerdings absolut anders. Auf keinen Fall. Meine Windows System basieren (fast) komplett auf kleinen, aber feinen Open Source Lösungen und ich habe in meinen privat entwickelten Anwendungen auch schon reichlich Open Source Content eingesetzt. Es war nicht meine Absicht, die Existenzberechtigung von Open Source Software anzuzweifeln. Nur war ich wirklich überrascht, dass eine essentielle Open Source Secukomponente, die auf 70% aller Webserver läuft, die eine solche scheunentorartige Lücke beinhaltet.
Akeem al Harun Geschrieben 15. April 2014 report Geschrieben 15. April 2014 Nur war ich wirklich überrascht, dass eine essentielle Open Source Secukomponente, die auf 70% aller Webserver läuft, die eine solche scheunentorartige Lücke beinhaltet. Ich schätze, da warst du nicht als einziger überrascht.
metallian1 Geschrieben 15. April 2014 report Geschrieben 15. April 2014 @Akeem: Das Argument habe ich erwartet, aber auf der anderen Seite führt das auch dazu, dass die "falsche Seite" es recht einfach hat, Fehler in Systemen zu finden und auszunutzen. Man ist nicht auf Trial-and-Error Versuche angewiesen wie gegen System, bei denen man keine Einsicht in den Quellcode hat und auch nicht dekompilieren kann. Und wenn das Argument zählt, wieso dauert es fast 2 Jahre, bis jemand diesen elementaren Fehler entdeckt? Fefes Meinung zu dem Thema. Er kommt eher aus der Ecke der Open Source Verfechter. Aber ganz unrecht hat er sicher nicht. Ganz ehrlich. Ich mußte den Blog dreimal lesen, um ihn zu verstehen. Aber der Autor sagt einiges, was wahr ist, aber auch jede Menge Müll. Der Mensch hat anscheinend noch nie in einer "bezahlten" Entwicklungsabteilung gearbeitet. Open Source als Bewegung ist das Konzept, dass man Leute Code schreiben lässt, deren Herzensblut dranhängt. Die es eben nicht kurz herunterpfuschen, weil sie dafür bezahlt werden. Open Source ist die Beobachtung, dass manche Menschen es lieben, Code zu schreiben. Und wenn man sie nicht mit Deadlines und Deliverables und dem monatlichen Paycheck unter Druck setzt, dann nehmen sie sich die Zeit und machen ihr Projekt ordentlich. Viel ordentlicher jedenfalls als die durchschnittliche kommerzielle Software. Das ist ja wohl dermaßen hanebüchen. Ich arbeite mit 150 Entwicklern in den verschiedensten Bereichen hier an unseren zentralen Unternehmenskomponenten. Wir werden alle gut bezahlt und wenn wir etwas nicht tun, dann "herunterpfuschen, wofür wir bezahlt werden". So ein Dünnsinn. Im Gegenteil. In vielen Bereichen "lieben" wir unseren Code genauso, wie er es von Open Source Entwicklern beschreibt. Und das wird in anderen Unternehmen nicht anders sein. Wie du schon gesagt hast, beide Modelle haben ihre Berechtigung. Und ja, viele Entwicklungsmodelle und gute Ansätze sind aus dem Open Source Bereich in den Closed Source Bereich gekommen. Aber die Vehemenz, in welcher dieser Felix irgendwas seinem Open Source Modell huldigt, hat schon etwas Manisches. Ohne ihn zu kennen würde ich mal tippen, dass der Mensch ein Microsoft / Apple Hater ist.
Nixonian Geschrieben 18. April 2014 report Geschrieben 18. April 2014 Das war's dann wohl mit den Captchas. Google wollte was für Streetview ausarbeiten, damit Aufschriften auslesbar sind. Und dabei haben sie festgestellt, daß die Software auch 97,84% aller Captchas löst. Das sind mehr als der Mensch. Ooops. http://derstandard.at/1397520995453/Algorithmus-macht-Captchas-ueberfluessig
Sulvahir Geschrieben 1. Mai 2014 report Geschrieben 1. Mai 2014 10 FOR I = 1 TO 50 20 PRINT "HELLO WORLD" 30 NEXT RUN
Bernward Geschrieben 1. Mai 2014 report Geschrieben 1. Mai 2014 10 FOR I = 1 TO 50 20 PRINT "HELLO WORLD" 30 NEXT RUN Was will uns der Autor damit sagen? [ ] Ich kann Basic [ ] Ich will wirklich alles grüßen [ ] wer das lesen und verstehen kann ist ein Dinosaurier?
Sulvahir Geschrieben 1. Mai 2014 report Geschrieben 1. Mai 2014 10 FOR I = 1 TO 50 20 PRINT "HELLO WORLD" 30 NEXT RUN Was will uns der Autor damit sagen? [ ] Ich kann Basic [ ] Ich will wirklich alles grüßen [ ] wer das lesen und verstehen kann ist ein Dinosaurier? BASIC wird 50
draco2111 Geschrieben 2. Mai 2014 Autor report Geschrieben 2. Mai 2014 10 FOR I = 1 TO 50 20 PRINT "HELLO WORLD" 30 NEXT RUN Was will uns der Autor damit sagen? [ ] Ich kann Basic [ ] Ich will wirklich alles grüßen [ ] wer das lesen und verstehen kann ist ein Dinosaurier? BASIC wird 50 Das waren noch Zeiten Bei mir sah das Prgramm dann aber eher so aus: 10 ? "HELLO WORLD" 20 GOTO 10 RUN
Krayon Geschrieben 2. Mai 2014 report Geschrieben 2. Mai 2014 10 FOR I = 1 TO 50 20 PRINT "HELLO WORLD" 30 NEXT RUN Was will uns der Autor damit sagen? [ ] Ich kann Basic [ ] Ich will wirklich alles grüßen [ ] wer das lesen und verstehen kann ist ein Dinosaurier? BASIC wird 50 Das waren noch Zeiten Bei mir sah das Prgramm dann aber eher so aus: 10 ? "HELLO WORLD" 20 GOTO 10 RUN Und wie sicherst Du, daß Du ganz genau nach 50 Wiederholungen den Resetknopf drückst?
Empfohlene Beiträge
Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren
Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde Dich hier an.
Jetzt anmelden