Zum Inhalt springen

Computernerds unter sich - Der Computerschwampf


Empfohlene Beiträge

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 :silly: ) 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.

Link zu diesem Kommentar
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 :silly: ) 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.

Link zu diesem Kommentar
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 :silly: ) 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?

Link zu diesem Kommentar
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.

Link zu diesem Kommentar
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?

Link zu diesem Kommentar
@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.

Link zu diesem Kommentar

 

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

Link zu diesem Kommentar

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 von Lukarnam
Link zu diesem Kommentar
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 :notify:

Link zu diesem Kommentar
@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.

Link zu diesem Kommentar

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.

Link zu diesem Kommentar
@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.

Link zu diesem Kommentar
  • 2 Wochen später...
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 :sigh:

Bei mir sah das Prgramm dann aber eher so aus:

 

10 ? "HELLO WORLD"
20 GOTO 10
RUN

 

:D

Und wie sicherst Du, daß Du ganz genau nach 50 Wiederholungen den Resetknopf drückst?

Link zu diesem Kommentar

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 erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
  • Wer ist Online   0 Benutzer

    • Keine registrierten Benutzer online.
×
×
  • Neu erstellen...