Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › OpenSSL-Schlüssel in Debian sind…

Wie es zu dem Bug kam

  1. Thema

Neues Thema Ansicht wechseln


  1. Wie es zu dem Bug kam

    Autor: Codeman 14.05.08 - 01:50

    Falls es jemanden interessiert - hier ist der Patch, der den Bug eingeführt hat.

    http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c

    Es wurde die Benutzung von unitialisiertem Speicher auskommentiert, der als Seed für den Zufallsgenerator genommen wurde. Das benutzen von uninitialisietem Speicher führte wohl zu Warnings im Debian Build System.

    Derjenige, der den Patch gebaut hat hatte sich aber vorher in der openssl Mailingliste erkundigt, ob das so OK ist und niemand hat Einwand erhoben:

    http://marc.info/?l=openssl-dev&m=114651085826293&w=2

    Der Fix war dann dementsprechend einfach:

    http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/crypto/rand/md_rand.c?rev=300&view=diff&r1=300&r2=299&p1=openssl/trunk/crypto/rand/md_rand.c&p2=/openssl/trunk/crypto/rand/md_rand.c


    In diesem Fall hat die Community nicht funktioniert und man sieht mal, wie schnell man ein Cryptosystem kompromitieren kann (eine Zeile auskommentieren), ohne das es jemand merkt.

  2. Re: Wie es zu dem Bug kam

    Autor: Levi:Shadow 14.05.08 - 08:18

    interessante Geschichte.... erinnert mich an den Spruch, wenn man keine Ahnung hat, einfach mal fresse halten^^.... (halt nur aus progger sicht^^

    mh... wobei.... der jenige der auf die idee kam, uninitialisiserten Speicher als seed zu nutzen (was garnicht mal sone dumme idee ist ;) ) hätte dies auch ganz klar reinkommentiernen können..... was er da tut... und das scheint ja nicht in den codesnipes vorhanden zu sein^^.... und was lernen wir aus der geschichte.... immer schön euren Code kommentieren.....

    Codeman schrieb:
    -------------------------------------------------------
    > Falls es jemanden interessiert - hier ist der
    > Patch, der den Bug eingeführt hat.
    >
    > svn.debian.org
    >
    > Es wurde die Benutzung von unitialisiertem
    > Speicher auskommentiert, der als Seed für den
    > Zufallsgenerator genommen wurde. Das benutzen von
    > uninitialisietem Speicher führte wohl zu Warnings
    > im Debian Build System.
    >
    > Derjenige, der den Patch gebaut hat hatte sich
    > aber vorher in der openssl Mailingliste erkundigt,
    > ob das so OK ist und niemand hat Einwand erhoben:
    >
    > marc.info
    >
    > Der Fix war dann dementsprechend einfach:
    >
    > svn.debian.org
    >
    > In diesem Fall hat die Community nicht
    > funktioniert und man sieht mal, wie schnell man
    > ein Cryptosystem kompromitieren kann (eine Zeile
    > auskommentieren), ohne das es jemand merkt.


  3. Re: Wie es zu dem Bug kam

    Autor: Sebastian Starosielec 14.05.08 - 10:14

    > In diesem Fall hat die Community nicht
    > funktioniert und man sieht mal, wie schnell man
    > ein Cryptosystem kompromitieren kann (eine Zeile
    > auskommentieren), ohne das es jemand merkt.

    Im Prinzip hat die Community ja schon funktioniert, als daß der Fehler gefunden und behoben wurde.

    Das eigentliche Problem war ja eher, daß der Compiler beim Benutzen von uninitialisierten Daten Warnmeldungen ausgespuckt hat (was ja auch sinnvoll ist).
    Der Erstautor hätte einfach für diesen Abschnitt diesen Warnungstyp abschalten sollen.




  4. Re: Wie es zu dem Bug kam

    Autor: Codeman 14.05.08 - 10:20

    Sebastian Starosielec schrieb:
    -------------------------------------------------------
    > Im Prinzip hat die Community ja schon
    > funktioniert, als daß der Fehler gefunden und
    > behoben wurde.

    Nach zwei Jahren!

  5. Re: Wie es zu dem Bug kam

    Autor: Tantalus 14.05.08 - 10:30

    Codeman schrieb:
    -------------------------------------------------------
    > Sebastian Starosielec schrieb:
    > --------------------------------------------------
    > -----
    > > Im Prinzip hat die Community ja schon
    >
    > funktioniert, als daß der Fehler gefunden und
    >
    > behoben wurde.
    >
    > Nach zwei Jahren!

    Naja, mal zum Vergleich ein Auszug aus einer anderen Meldung von eben:

    >Die beiden Sicherheitslecks finden sich in den Word-Versionen von 2000
    >bis 2007, in den Mac-Varianten Word 2004 sowie 2008 und im Word Viewer
    >2003

    Klar ist es nicht so prickelnd, dass ein Fehler erst nach zwei Jahren gefunden wurde, aber die wirklich heikle Zeitspanne ist doch die zwischen der Entdeckung und der veröffentlichung des Fixes.

    Gruß
    Tantalus

  6. Re: Wie es zu dem Bug kam

    Autor: Codeman 14.05.08 - 11:00

    Tantalus schrieb:
    > Klar ist es nicht so prickelnd, dass ein Fehler
    > erst nach zwei Jahren gefunden wurde, aber die
    > wirklich heikle Zeitspanne ist doch die zwischen
    > der Entdeckung und der veröffentlichung des
    > Fixes.

    Ich bin seit 12 Jahren Entwickler und UNIX-Benutzer. Ich gehöre nicht zu der Fraktion, die ein Betriebssystem aus irgendwelchen religiösen Gründen supertoll oder total beschissen findet. In meinem Beruf kommt man ohne einen gewissen Pragmatismus nicht besonders weit.

    Was hier passiert ist ist aber ganz grosser Mist und wird noch viel Probleme bereiten. Wenn ich jetzt z.B. für eine Bank entwickeln würde würde ich nie wieder Debian benutzen, sondern mich eher bei den BSDs umschauen.

    Das kann man nicht mit: "Bei MS dauert das länger" schön reden.

  7. Re: Wie es zu dem Bug kam

    Autor: Kokospalme 14.05.08 - 11:18

    Codeman schrieb:
    -------------------------------------------------------
    > Was hier passiert ist ist aber ganz grosser Mist
    > und wird noch viel Probleme bereiten. Wenn ich
    > jetzt z.B. für eine Bank entwickeln würde würde
    > ich nie wieder Debian benutzen, sondern mich eher
    > bei den BSDs umschauen.

    Dann solltest du dir ganz pragmatisch darüber im klaren sein, dass jedes System Fehler aufweisen kann und das auch mit an Sicherheit grenzender Wahrscheinlichkeit tut.

    In den BSDs ist gerade ein 25 Jahre alter Fehler behoben worden, der zum Glück nicht sicherheitsrelevant ist.

    Trotz allem gehört Debian zu den Distributionen, die relativ wenige Fehler enthalten. Dieser Fehler ist sehr ärgerlich, weil man sämtliche Keys neu generieren und verteilen muss, trotzdem ist das kein Grund die Distribution zu wechseln. Wenn eine Sicherheitslücke für dich ein Grund dazu ist, dann hast du keine Ahnung, sondern lässt dich von Emotionen leiten. Das ist dein gutes Recht, aber alles andere als professionell.

  8. Re: Wie es zu dem Bug kam

    Autor: Tantalus 14.05.08 - 11:40

    Codeman schrieb:
    -------------------------------------------------------

    > Ich bin seit 12 Jahren Entwickler und
    > UNIX-Benutzer. Ich gehöre nicht zu der Fraktion,
    > die ein Betriebssystem aus irgendwelchen
    > religiösen Gründen supertoll oder total beschissen
    > findet. In meinem Beruf kommt man ohne einen
    > gewissen Pragmatismus nicht besonders weit.

    Den sollte man, egal in welchem bereich, im beruflichen Umfeld immer haben.

    > Was hier passiert ist ist aber ganz grosser Mist
    > und wird noch viel Probleme bereiten.

    Das bestreitet niemand. Ist bei aufgefundenen Sicherheitslücken aber oft so. Gehört quasi zum "Berufsrisiko".

    > Wenn ich
    > jetzt z.B. für eine Bank entwickeln würde würde
    > ich nie wieder Debian benutzen, sondern mich eher
    > bei den BSDs umschauen.

    ... und bei der nächsten bekannt gewordenen Sicherheitslücke wieder das System wechseln, und dann wieder...? Wenn Du ausschließlich "garantiert absolut fehlerfreie Software" einsetzen willst, musst Du Dich auf "Hello World"-Progrämmchen beschränken.

    > Das kann man nicht mit: "Bei MS dauert das länger"
    > schön reden.

    Hier wollte ich nichts "schönreden", sondern einem potentiellen Trollversuch den Wind aus den Segeln nehmen.

    Gruß
    Tantalus

  9. Re: Wie es zu dem Bug kam - Nachtrag

    Autor: Tantalus 14.05.08 - 11:57

    Nachtrag:

    Wenn Du für eine Bank arbeiten würdest, würden dort mit Sicherheit die Schlüssel- und Zertifikatsdateien in regelmäßigen Abständen ausgetauscht. Dann stündest Du nur vor der Frage, die neuen Schlüssel sofort zu verteilen, oder den nächsten geplanten Wechsel abzuwarten.

    Gruß
    Tantalus

  10. Re: Wie es zu dem Bug kam

    Autor: Codeman 14.05.08 - 15:39

    Kokospalme schrieb:
    -------------------------------------------------------
    > Wenn eine Sicherheitslücke für dich ein Grund dazu ist, dann
    > hast du keine Ahnung, sondern lässt dich von
    > Emotionen leiten. Das ist dein gutes Recht, aber
    > alles andere als professionell.

    Es geht mir nicht um 'Emotionen'. Durch diesen Vorfall wurde deutlich gemacht, das es bei Debian möglich ist, dass ein Maintainer durch einen Fehler oder mutwillig die Sicherheit des ganzen Systems kompromittiert. Es scheint also keine Kontrollinstanz bei solch kritischen Paketen zu geben. Und es wäre unprofessionell, sowas als Einzelfall abzutun.

  11. Re: Wie es zu dem Bug kam

    Autor: horst_ 16.05.08 - 18:45

    Codeman schrieb:
    -------------------------------------------------------
    > Kokospalme schrieb:
    > --------------------------------------------------
    > -----
    > > Wenn eine Sicherheitslücke für dich ein Grund
    > dazu ist, dann
    > hast du keine Ahnung, sondern
    > lässt dich von
    > Emotionen leiten. Das ist dein
    > gutes Recht, aber
    > alles andere als
    > professionell.
    >
    > Es geht mir nicht um 'Emotionen'. Durch diesen
    > Vorfall wurde deutlich gemacht, das es bei Debian
    > möglich ist, dass ein Maintainer durch einen
    > Fehler oder mutwillig die Sicherheit des ganzen
    > Systems kompromittiert. Es scheint also keine
    > Kontrollinstanz bei solch kritischen Paketen zu
    > geben. Und es wäre unprofessionell, sowas als
    > Einzelfall abzutun.
    >

    Dass Maintainer an Code rumpatchen ist nichts ungewöhnliches, das gibts bei fast allen Distributionen und auch bei den BSDs. Wenn einem das nicht passt muss man LFS nutzen..
    Da, wie du weißt, der Maintainer sogar auf der OpenSSL-Mailingliste nachgefragt hat, ob es problematisch ist, dieses Stück Code auszukommentieren (und ihm dort gesagt wurde, dass es das nicht sei), kann man ihm und dem Debian-Projekt eigentlich keinen großen Vorwurf machen.

    Es wäre natürlich trotzdem vernünftiger gewesen, den Code nicht auszukommentieren, sondern ein #ifndef DEBUG davorzusetzen..
    Ich schätze mal, dass der entsprechende Maintainer (und auch alle anderen Maintainer sämtlicher Distributionen) aus diesem GAU gelernt hat und sich sowas nicht wiederholt.

    - horst, der auch weiterhin debian nutzt

  12. Re: Wie es zu dem Bug kam

    Autor: robinx 16.05.08 - 19:00


    >
    >
    > Dass Maintainer an Code rumpatchen ist nichts
    > ungewöhnliches, das gibts bei fast allen
    > Distributionen und auch bei den BSDs. Wenn einem
    > das nicht passt muss man LFS nutzen..
    > Da, wie du weißt, der Maintainer sogar auf der
    > OpenSSL-Mailingliste nachgefragt hat, ob es
    > problematisch ist, dieses Stück Code
    > auszukommentieren (und ihm dort gesagt wurde, dass
    > es das nicht sei), kann man ihm und dem
    > Debian-Projekt eigentlich keinen großen Vorwurf
    > machen.
    >
    klar kann man dem einen vorwurf machen, wenn man sich den text durchließt
    http://marc.info/?l=openssl-dev&m=114651085826293&w=2
    dann stellt man eigentlich fest das er davon redet dass es beim debuggen von software viele warnmeldungen gibt und eigentlich wurde ihm nur in dem zusammenhang gesagt dass es ok ist
    "Not much. If it helps with debugging, I'm in favor of removing them.
    (However the last time I checked, valgrind reported thousands of bogus
    error messages. Has that situation gotten better?)"

    Er hat ganz privat nachgefragt und es war nie die rede davon dass es ein offizielles paket sein soll. Und wenn er die 2 zeilen nur auf seinem system zum debuggen von software auskommentiert hätte währe nichts passiert

  13. Re: Wie es zu dem Bug kam

    Autor: john.doe 16.05.08 - 19:10

    horst_ schrieb:
    -------------------------------------------------------
    > Da, wie du weißt, der Maintainer sogar auf der
    > OpenSSL-Mailingliste nachgefragt hat, ob es
    > problematisch ist, dieses Stück Code
    > auszukommentieren (und ihm dort gesagt wurde, dass
    > es das nicht sei), kann man ihm und dem
    > Debian-Projekt eigentlich keinen großen Vorwurf
    > machen.

    Dieser Punkt wird doch gerade ausführlich in diversen Blogs diskutiert: Wenn man die Antworten der OpenSSL-Leute genau liest, muss man realisieren, dass diese nur bzgl. des Debuggings ihr OK gegeben haben. Eine simple User-Anfrage (von einer solchen musste das OpenSSL-Team ausgehen, denn der Debian-Maintainer hatte sich nicht als solcher zu erkennen gegeben) ersetzt nicht einen offiziell eingereichten Patch, der entsprechend begutachtet würde.

    Ich will die Schuld nicht ganz vom OpenSSL-Team abweisen. Immerhin wissen diese um die Brisanz und Wichtigkeit ihrer Software und sollten daher (IMHO) lieber einmal mehr als weniger wichtige Hinweise zur Sicherheit in derartigen Threads anhängen. Allgemein können OpenSSL und anderen Upstreamer jedoch nicht verantwortlich gemacht werden, wenn Distributoren eigene Patches schnell und relativ unreflektiert durchwinken.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. CompuGroup Medical Deutschland AG, Kiel, Hamburg
  2. caplog-x GmbH, Leipzig
  3. Evangelischer Presseverband für Bayern e.V. (EPV), München
  4. Deloitte, verschiedene Standorte

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 79,00€
  2. 999,00€ + Versand
  3. (u. a. GTA 5 12,49€, GTA Online Cash Card 1,79€)
  4. (aktuell u. a. Dell-Notebook 519€, Dell USB-DVD-Brenner 34,99€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


FPM-Sicherheitslücke: Daten exfiltrieren mit Facebooks HHVM
FPM-Sicherheitslücke
Daten exfiltrieren mit Facebooks HHVM

Server für den sogenannten FastCGI Process Manager (FPM) können, wenn sie übers Internet erreichbar sind, unbefugten Zugriff auf Dateien eines Systems geben. Das betrifft vor allem HHVM von Facebook, bei PHP sind die Risiken geringer.
Eine Exklusivmeldung von Hanno Böck

  1. HHVM Facebooks PHP-Alternative erscheint ohne PHP

In eigener Sache: Neue Workshops zu agilem Arbeiten und Selbstmanagement
In eigener Sache
Neue Workshops zu agilem Arbeiten und Selbstmanagement

Wir haben in unserer Leserumfrage nach Wünschen für Weiterbildungsangebote gefragt. Hier ist das Ergebnis: Zwei neue Workshops widmen sich der Selbstorganisation und gängigen Fehlern beim agilen Arbeiten - natürlich extra für IT-Profis.

  1. In eigener Sache ITler und Board kommen zusammen
  2. In eigener Sache Herbsttermin für den Kubernetes-Workshop steht
  3. Golem Akademie Golem.de startet Angebote zur beruflichen Weiterbildung

Ryzen 3900X/3700X im Test: AMDs 7-nm-CPUs lassen Intel hinter sich
Ryzen 3900X/3700X im Test
AMDs 7-nm-CPUs lassen Intel hinter sich

Das beste Prozessor-Design seit dem Athlon 64: Mit den Ryzen 3000 alias Matisse bringt AMD sehr leistungsstarke und Energie-effiziente CPUs zu niedrigen Preisen in den Handel. Obendrein laufen die auch auf zwei Jahre alten sowie günstigen Platinen mit schnellem DDR4-Speicher.
Ein Test von Marc Sauter

  1. Ryzen 3000 BIOS-Updates schalten PCIe Gen4 für ältere Boards frei
  2. Mehr Performance Windows 10 v1903 hat besseren Ryzen-Scheduler
  3. Picasso für Sockel AM4 AMD verlötet Ryzen 3400G für flottere iGPU

  1. Versand: Das Smartphone wird für DHL-Packstationen langsam Pflicht
    Versand
    Das Smartphone wird für DHL-Packstationen langsam Pflicht

    Die mTAN, also die Abholcodes, bekommen DHL-Neukunden für die Packstationen nur noch per App. Altkunden haben noch eine Alternative. Für die Nutzer ist das eine zusätzliche Hürde beim Abholen von Paketen.

  2. SpaceX: Feuerball steigt nach Test des Starhopper-Triebswerks auf
    SpaceX
    Feuerball steigt nach Test des Starhopper-Triebswerks auf

    Kurz nach einem statischen Triebwerkstest des Starhopper kam es zu einem unplanmäßigen Feuer, das aber schnell gelöscht werden konnte. Das Raumschiff des US-Raumfahrtunternehmens SpaceX scheint das Feuer aber weitgehend unbeschädigt überstanden zu haben.

  3. Playerunknown's Battlegrounds: Pubg updatet die Updates und Erangel
    Playerunknown's Battlegrounds
    Pubg updatet die Updates und Erangel

    Das Actionspiel Pubg stellt sein Updatesystem um, künftig orientiert man sich wie Fortnite und ähnliche Titel an der Season. Die nächste große Aktualisierung der PC-Version enthält unter anderem eine grafisch überarbeitete Version der ersten Karte Erangel.


  1. 11:20

  2. 11:08

  3. 10:49

  4. 10:35

  5. 10:22

  6. 09:47

  7. 09:20

  8. 09:04