1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › OpenSSL: Fork und der Zufall

Paradebeispiel für ein Generelles Problem.

  1. Thema

Neues Thema Ansicht wechseln


  1. Paradebeispiel für ein Generelles Problem.

    Autor: nille02 23.08.13 - 15:59

    Ständig halten sich Projekte für irgendetwas nicht zuständig oder schieben den Schwarzen Peter zum nächsten. Seit über 5 Jahren ist also bekannt das es hier ein Potenzielles Problem gibt und sich für nicht zuständig gehalten.

    OpenSSL liefert auf Grund dieses Problems also Unsichere Schlüssel, und sie halten sich nicht für zuständig? Seit 5 Jahren?

  2. Re: Paradebeispiel für ein Generelles Problem.

    Autor: Oromit 23.08.13 - 16:06

    Es liefert nur unter äußerst unwahrscheinlichen Bedingungen identische Zufallszahlen für Unterprozesse.
    Genauer gesagt, wenn zwei mal nacheinander ein Kind-Prozess die selbe PID hat, werden, unter der bedingung, dass man eine Debian-Version von OpenSSL verwendet oder den userdata buffer bereits initialisiert hat, in diesen beiden prozessen identische Zufallszahlen erzeugt.

    Ein Problem ist das scheinbar nur ernsthaft unter Android, da hier sowohl der userdata buffer initialisiert wird, als auch massiv gebrauch von fork() gemacht wird, sodass es nicht mehr unwahrscheinlich ist, dass ein child irgendwann zwei mal die selbe PID erwischt.

  3. Re: Paradebeispiel für ein Generelles Problem.

    Autor: registrierter_schreiber 23.08.13 - 16:11

    Wenn ich den Artikel richtig verstanden habe geht es eben nicht im die PID der Kindsprozesse, sondern um die des Hauptprozesses (somit konstant), weil dort die Initialisierung von OpenSSL erfolgt.
    Edit: Gerade erst gesehen, dass Du genau diese Thematik in dem anderen Thread ansprichst. Diskussion also ggfs besser dort.



    1 mal bearbeitet, zuletzt am 23.08.13 16:13 durch registrierter_schreiber.

  4. Re: Paradebeispiel für ein Generelles Problem.

    Autor: mushroomer 23.08.13 - 17:02

    Aber ist es nicht generell so, das es bisher noch keinen Algorithmus gibt, der wirklich richtige Zufallszahlen generiert?

  5. Re: Paradebeispiel für ein Generelles Problem.

    Autor: a user 23.08.13 - 17:43

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > Ständig halten sich Projekte für irgendetwas nicht zuständig oder schieben
    > den Schwarzen Peter zum nächsten. Seit über 5 Jahren ist also bekannt das
    > es hier ein Potenzielles Problem gibt und sich für nicht zuständig
    > gehalten.
    >
    > OpenSSL liefert auf Grund dieses Problems also Unsichere Schlüssel, und sie
    > halten sich nicht für zuständig? Seit 5 Jahren?
    und sie haben recht. openssl liefert keine unsicheren schlüssel, bzw. deren zufallsgenerator.

    wenn du aber einen zufallsgenerator mit demselben seed initialisierst, dann hast du natürlich auch gleiche schlüsselfolgen.

    das ist auch das problem: der entwickler, der die lib nutzt initialisierst den randomgenerator einmalig mit dem gleichen seed für mehrere prozesse. das das dämlich ist sollte man eigentlich schon wissen, wenn man als anfänger das erste mal die c-funktion rand (oder war's random?) nutzt.

    die systemzeit hier dazu zu nehmen bringt so gut wie gar nichts, ganz besonders nicht, wenn geforkt wird. der zeit unterschied ist so gering, dass man mit nur sehr wenig brute force den seed der anderen prozesse bestimmen kann.

    es ist eben kein problem von openssl. es ist ein problem der nutztung dessen.

    was aber im artikel offenbar unterschlagen wurde (ich nehme mal unwissenheit an), es gibt auch für windows etwas ähnliches wie das /dev/random bzw. /dev/urandom unter linux.

    windows hat in seiner crypto-api eine funktion zur erstellung sicherer seeds (frag mich nicht mehr wie die heißt, müsste mal in meinem quellcode daheim schauen).

  6. Re: Paradebeispiel für ein Generelles Problem.

    Autor: Moe479 23.08.13 - 18:06

    korrekt, dass das dämlich ist hat jeder der sich mit prozedural generierten zufallsbildern auseinandergesetzt hat eigentlich begriffen ... in den seedwert z.b. die systemzeit einfliessen zu lassen schafft mitunter schon abhilfe ... nur so als simpelster lösungsansatz ...

    function myrand (a,b,steps=1) {
    seed(getTheFuckingTimeInMillisecs());
    return rand(a,b,steps);
    }

    irgenwie so einfach ...



    1 mal bearbeitet, zuletzt am 23.08.13 18:08 durch Moe479.

  7. Re: Paradebeispiel für ein Generelles Problem.

    Autor: theonlyone 23.08.13 - 18:16

    Moe479 schrieb:
    --------------------------------------------------------------------------------
    > korrekt, dass das dämlich ist hat jeder der sich mit prozedural generierten
    > zufallsbildern auseinandergesetzt hat eigentlich begriffen ... in den
    > seedwert z.b. die systemzeit einfliessen zu lassen schafft mitunter schon
    > abhilfe ... nur so als simpelster lösungsansatz ...
    >
    > function myrand (a,b,steps=1) {
    > seed(getTheFuckingTimeInMillisecs());
    > return rand(a,b,steps);
    > }
    >
    > irgenwie so einfach ...

    Klar umso mehr Werte du nutzt für deinen Zufallswert umso besser, aber wird eben auch immer unperformanter oder ist schlicht unnötig.

    Den wie in der mathematik, du bevorzugst die Lösung mit den wenigsten variablen, künstlich aufblasen kann man alles, ob das sinnvoll ist bleibt auf einem anderen Blatt.


    Systemzeit zu nehmen ist wie im Artikel auch steht ein valider Ansatz, will man das ganze verteilt haben und man hat keine einheitliche Systemzeit mehr, wird das schon wieder zum Problem.

  8. Re: Paradebeispiel für ein Generelles Problem.

    Autor: theonlyone 23.08.13 - 18:24

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > Ständig halten sich Projekte für irgendetwas nicht zuständig oder schieben
    > den Schwarzen Peter zum nächsten. Seit über 5 Jahren ist also bekannt das
    > es hier ein Potenzielles Problem gibt und sich für nicht zuständig
    > gehalten.
    >
    > OpenSSL liefert auf Grund dieses Problems also Unsichere Schlüssel, und sie
    > halten sich nicht für zuständig? Seit 5 Jahren?

    Klar im nachhinein sagt sich das leicht.

    Du musst aber im Kopf behalten das viele Leute, gerade in OpenSource einen "fehler" im Code finden, der schlichtweg darauf basiert das sie den Code für etwas brauchen wollen für das der garnicht vorgesehen ist.

    Wenn der Fehler hier also nur durch die Unterprozesse und enormen Fork entsteht, dann ist der Zufallsgenerator eben für diese Plattformen nicht geeignet ; was nicht bedeutet das es ein Fehler ist, sondern er wird genutzt wo es nicht sinnvoll ist.

    Diese Ausnahmen können ihren Code ja selbstständig anpassen wenn sie um diesen Fehler wissen.


    Es macht übrigens keinen Sinn einen allgemeinen Code anzupassen nur weil ein paar Plattformen probleme damit haben, was im blödsten Fall wieder Probleem auf anderen Plattformen auslöst.


    Im 0815 Programmcode macht man das natürlich, wenn dein Code aber von vielen anderen Plattformen und vielen anderen Code-Baustellen genutzt wird, kannst du nicht einfach so eine Änderung vollziehen, deshalb muss man das kritischer betrachten als einfach nur einen "vermeintlichen" Bug zu fixen, der am Ende garkeiner ist (sondern nur aus unsachgemäßer Nutzung des Codes entsteht).


    Was immer geht ist eine weitere Option anzubieten im Code die eben genau diese "geänderte" Funktion aufruft, die von mir aus noch die Systemzeit nutzt ; aber dann hast du direkt wieder das Problem das dein Code sich aufbläst und Sonderlösungen will man ja eben auch nicht ständig einbauen.



    Was sich eben erst herausstellen muss ist das der fehler wirklich die gleiche Ursache hat, gerade wenn er in vielen Plattformen vorkommt, genau dann (wie eben jetzt bekannt) kann man das Problem auch identifizieren und im Basis Code ändern (vorschnelle Lösungen sind aber viel zu gefährlich, das richtet mehr Schaden an als es nutzt, demnach Systemzeit hinzufügen ? Sollte erstmal klar sein das dadurch das Problem auch wirklich gelöst wird und nicht nur wieder verschleiert wird als Pseudo Bugfix, der am Ende garkeiner ist, oder wieder neue Probleme erzeugt, oder noch größere).

  9. Re: Paradebeispiel für ein Generelles Problem.

    Autor: Airblader 24.08.13 - 02:24

    mushroomer schrieb:
    --------------------------------------------------------------------------------
    > Aber ist es nicht generell so, das es bisher noch keinen Algorithmus gibt,
    > der wirklich richtige Zufallszahlen generiert?

    In einem deterministischem System geht das auch einfach gar nicht. Es gibt aber Lösungen, die auf Messwerten der Natur beruhen, z.B. hochenergetische Teilchen in der Atmosphäre. Sowas ist für den Alltagsgebrauch im Rechner aber noch Zukunftsmusik.

  10. Re: Paradebeispiel für ein Generelles Problem.

    Autor: krutius 24.08.13 - 15:49

    Naja, bereits die Bewegung eines Doppelpendels o.ä. verstärkt den "echten" quantenzufall gut genug. Sowas hat man aber halt meistens in einem Computer nicht zur Verfügung.

    Gut ist auch die Mausbewegung zu nutzen um einen seed zu erzeugen, man muss es halt machen.

  11. Re: Paradebeispiel für ein Generelles Problem.

    Autor: Oromit 24.08.13 - 15:52

    krutius schrieb:
    --------------------------------------------------------------------------------
    > Naja, bereits die Bewegung eines Doppelpendels o.ä. verstärkt den "echten"
    > quantenzufall gut genug. Sowas hat man aber halt meistens in einem Computer
    > nicht zur Verfügung.
    >
    > Gut ist auch die Mausbewegung zu nutzen um einen seed zu erzeugen, man muss
    > es halt machen.

    Der kernel nutzt alle ihm zur verfügung stehenden quellen für die entropie von /dev/random, u.a. auch eine maus, sofern vorhanden, was dann von OpenSSL für den initialen seed verwendet wird.

  12. Re: Paradebeispiel für ein Generelles Problem.

    Autor: tehsre 26.08.13 - 11:02

    Um es einfach mal deutlich zu formulieren:

    Laufzeit sollte bei prngs IMMER an zweiter Stelle stehen.

    Was passiert wenn das nicht der Fall ist sieht man ja nun.

    IMO ist es schon ein Problem von OpenSSL.
    Man verlässt sich in der entropie auf einen Zufall der nicht garantiert einer ist (uninitialisierter Speicherbereich) und benötigt nur noch eine weitere Bedingung damit genau das zum PRNG-Supergau führt. Ich finde Argumentation, dass das ja eigtl eine Fehlbedienung ist ehrlich gesagt recht mutig.
    Oder steht das irgendwo groß und fett in der Dokumentation? Ich vermute ja nicht...

    Wenn bei einem PRNG der Zufall zum Glücksfall werden kann, kann das doch beim besten Willen nicht in Sinne des Erfinders sein.



    1 mal bearbeitet, zuletzt am 26.08.13 11:04 durch tehsre.

  13. Re: Paradebeispiel für ein Generelles Problem.

    Autor: petera 26.08.13 - 13:32

    tehsre schrieb:
    > IMO ist es schon ein Problem von OpenSSL.

    Nimm den PoC, und teste es:
    wget https://raw.github.com/emboss/openssl-prng/master/c/recycle_pid.c
    gcc recycle_pid.c -lssl -o recycle_pid

    > Man verlässt sich in der entropie auf einen Zufall der nicht garantiert
    > einer ist (uninitialisierter Speicherbereich) und benötigt nur noch eine
    > weitere Bedingung damit genau das zum PRNG-Supergau führt.

    OpenSSL hat eine lange und traurige Historie in dieser und vielerlei ander Hinsicht.

    Ich komme zu ganz unterschiedlichen Ergebnissen:
    - Programm terminiert nach 2-15 Sekunden mit identischen Zufallszahlen (Vanilla)
    - Programm terminiert nach 15 Minuten mit identischen Zufallszahlen (Vanilla SE)
    - Programm terminiert nicht (Kernel-Patch)
    - Programm terminiert mit unterschiedlichen Zufallszahlen (Hardware RNG)

    > Ich finde Argumentation, dass das ja eigtl eine Fehlbedienung ist ehrlich gesagt
    > recht mutig.

    Das kommt drauf an von welcher Seite Du das Problem betrachtest.

    > Wenn bei einem PRNG der Zufall zum Glücksfall werden kann, kann das doch
    > beim besten Willen nicht in Sinne des Erfinders sein.

    Ich bekomme Zweifel an deinem Verständnis für PRNGs, denn der PRNG kann nix dafür.

  14. Re: Paradebeispiel für ein Generelles Problem.

    Autor: tehsre 26.08.13 - 15:55

    Ich kann hier mit default Unbuntu mit "identischen Zufallszahlen dienen" was aber auf Basis des Wissenstandes nicht weiter überraschend ist ;).

    Der PRNG kann nichts dafür weil?
    Du kannst mich jetzt gerne aufklären denn entweder hab ich etwas nicht richtig verstanden oder du mich nicht ;).
    In meinen Augen patzt hier eben der PRNG.

    Oder nochmal ganz anders gesagt:

    Wenn man es in openssl fixen kann, sollte man das auch tun.

    Nachtrag: Sollte diese Verhalten in der OpenSSL Doku klar beschrieben sein nehme ich alles zurück und erkläre OpenSSL für völlig unschuldig ;).

    Nachtrag aus der Openssl manpage:
    > The contents of buf is mixed into the entropy pool before retrieving the new pseudo-random bytes unless disabled at compile time (see FAQ).

    Es wird also darauf hingewiesen. Von daher kann man schon sagen dass OpenSSL keine ungeteilte Schuld trifft.
    Dummerweise verleitet der "unless disabled at compile time" Hinweis sehr dazu anzunehmen, dass es "ohne auch funktionieren wird".



    4 mal bearbeitet, zuletzt am 26.08.13 16:02 durch tehsre.

  15. Re: Paradebeispiel für ein Generelles Problem.

    Autor: petera 26.08.13 - 18:33

    tehsre schrieb:
    --------------------------------------------------------------------------------
    > Ich kann hier mit default Unbuntu mit "identischen Zufallszahlen dienen"
    > was aber auf Basis des Wissenstandes nicht weiter überraschend ist ;).
    > Der PRNG kann nichts dafür weil?

    Weil er dort nicht hingehört, also ein PRNG gehört nicht ins OpenSSL Paket. Idealerweise löst man sowas beim build mit

    configure \
    --with-entrophy-src=egd|urandom|random|broken-internal \
    --with-prng passthru|ranmar|fortune|fips-whatever|broken-internal \

    D.h. wird idealerweise automatisch systemspezifischer Code für eine Entropiequelle und PRNG erzeugt, und/oder eine bekannte PRNG Impementation genutzt.

    > Du kannst mich jetzt gerne aufklären denn entweder hab ich etwas nicht
    > richtig verstanden oder du mich nicht ;).
    > In meinen Augen patzt hier eben der PRNG.
    (...)
    > Es wird also darauf hingewiesen. Von daher kann man schon sagen dass
    > OpenSSL keine ungeteilte Schuld trifft.
    > Dummerweise verleitet der "unless disabled at compile time" Hinweis sehr
    > dazu anzunehmen, dass es "ohne auch funktionieren wird".

    Wenn der PRNG nicht patzt, patzt irgendein Maintainer. Wenn Du dich lange und ernsthaft mit OpenSSL (oder NSS) auseinandersetzt fängst Du früher oder später an den Kram selbst zu bauen, weil Dir je nach Distribution, Maintainer und/oder Platform eh "Ciphers" aus ECC wie z.B. ECDHE oder Betriebsmodi (wie Counter) für Blockchiffren (wie AES) fehlen, bzw. diese distributionsspezifisch ausgelassen wurden, dafür ist da noch antiker Kram drin, den niemand wirklich mehr einsetzen möchte (wie rc2), davon kannst Du dich mit

    openssl list-cipher-algorithms
    openssl list-public-key-algorithms

    überzeugen. Kollisionsfreie Hashfunktionen diskutieren wir besser garnicht erst. Man möchte keine sequentiellen Werte aus einem Namensraum (wie einer PID) mit niedriger Entropie. Der ganze Kram fällt einem dann später in der virtualisieren Umgebung erneut auf die Füsse.

  16. Re: Paradebeispiel für ein Generelles Problem.

    Autor: petera 26.08.13 - 19:03

    Moe479 schrieb:
    > function myrand (a,b,steps=1) {
    > seed(getTheFuckingTimeInMillisecs());
    > return rand(a,b,steps);
    > }
    >
    > irgenwie so einfach ...

    Btw. Timer =/= Uhrzeit/Zeitstempel, sequentielle, korrelierbare Informationen haben keinerlei Entropie.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Hays AG, Dortmund
  2. über duerenhoff GmbH, Münster
  3. Verkehrsbetriebe Karlsruhe GmbH, Karlsruhe
  4. Elektrobit Automotive GmbH, Erlangen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 129€ (Bestpreis mit Saturn. Vergleichspreis 159,99€ + Versand)
  2. (u. a. Total War: Warhammer II für 24,99€, Halo Wars 2 (Xbox One / Windows 10) für 10,49€ und...
  3. 1,99€
  4. (u. a. Ecovacs Robotics Deebot Ozmo 905 heute für 333€, Philips 58PUS6504/12 für 399€, JBL...


Haben wir etwas übersehen?

E-Mail an news@golem.de