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

Unstimmigkeiten

  1. Thema

Neues Thema Ansicht wechseln


  1. Unstimmigkeiten

    Autor: Oromit 23.08.13 - 16:00

    > Das Problem tritt auf, wenn der Zufallszahlengenerator im Hauptprogramm initialisiert
    > wird und anschließend mehrere per Fork gestartete Unterprozesse Zufallszahlen
    > abrufen. In diesem Fall liefert die Zufallsfunktion in allen Prozessen denselben Wert.
    > Grund dafür: Die einzige zusätzliche Zufallsquelle, die in den Unterprozessen genutzt
    > wird, ist die Prozess-ID (PID) des Hauptprogramms.

    Das verstehe ich anders, es wird sehr wohl die pid des geforkten unterprozesses genutzt. Es geht hier um das Szenario, bei dem ein neuer Child-Prozess die selbe PID bekommt wie ein vorheriger, was auf häufig forkenden systemen wie Android scheinbar recht häufig, oder zumindest nicht ausreichend selten, vorkommt.


    > Bei seinen Tests stellte Martin Boßlet weiterhin fest, dass das Problem in C-Code
    > nur unter bestimmten Umständen auftrat - und zwar in Abhängigkeit von der Linux
    > Distribution. Nur in Debian-basierten Distributionen konnte er das Problem
    > reproduzieren.

    Das Problem tritt sehr wohl auch unter nicht-Debian-Derivaten auf. Wird der userdata-Bereich vor dem aufruf von ssleay_rand_bytes initialisiert, ist die entropie durch diesen nicht mehr vorhanden, da der "zufällige", uninitialisierte speicher als entropiequelle genutzt wurde.
    Genau das tut u.a. der Android OpenSSL wrapper, weshalb das Problem auch unter Android auftritt.

    Einfach den Speicher nicht zu initialisieren ist allerdings auch keine Alternative, da uninitialisieter Speicher nicht unbedingt eine verlässliche Entropiequelle ist.
    Ein wenig Entropie aus /dev/urandom oder die Einberechnung der aktuellen Zeit wären hier zu bevorzugen.

  2. Re: Unstimmigkeiten

    Autor: dura 23.08.13 - 16:47

    Oromit schrieb:
    --------------------------------------------------------------------------------
    > Das verstehe ich anders, es wird sehr wohl die pid des geforkten
    > unterprozesses genutzt. Es geht hier um das Szenario, bei dem ein neuer
    > Child-Prozess die selbe PID bekommt wie ein vorheriger, was auf häufig
    > forkenden systemen wie Android scheinbar recht häufig, oder zumindest nicht
    > ausreichend selten, vorkommt.

    So wie ich das verstanden habe, würde es helfen, die Initialisierung nach dem Fork zu machen und das dürfte bei deiner Erklärung ja keinen Unterschied machen, oder?

  3. Re: Unstimmigkeiten

    Autor: Oromit 23.08.13 - 16:54

    dura schrieb:
    --------------------------------------------------------------------------------
    > Oromit schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Das verstehe ich anders, es wird sehr wohl die pid des geforkten
    > > unterprozesses genutzt. Es geht hier um das Szenario, bei dem ein neuer
    > > Child-Prozess die selbe PID bekommt wie ein vorheriger, was auf häufig
    > > forkenden systemen wie Android scheinbar recht häufig, oder zumindest
    > nicht
    > > ausreichend selten, vorkommt.
    >
    > So wie ich das verstanden habe, würde es helfen, die Initialisierung nach
    > dem Fork zu machen und das dürfte bei deiner Erklärung ja keinen
    > Unterschied machen, oder?

    Doch, da bei der Initialisierung auch andere Entropie Quellen genutzt werden. Allerdings könnte der Eltern Prozess dann keine Zufalls zahlen mehr nutzen, da er den generator nicht initialisiert darf.

  4. Re: Unstimmigkeiten

    Autor: hab (Golem.de) 23.08.13 - 17:39

    Hallo,

    Im ersten Punkt hast Du recht, es geht tatsächlich um die PID des Unterprozesses. Sorry, mein Fehler, ist geändert.

    Im zweiten Punkt stimmt der Artikel schon, wenn man es genau nimmt. Es steht ja nur da, dass Boßlet das Problem nicht reproduzieren konnte, was er in seinem Blogeintrag auch so schreibt. Ich hab das aber nochmals präzisiert, damit es klarer wird.

  5. Re: Unstimmigkeiten

    Autor: a user 23.08.13 - 17:46

    was im artikel aber noch nicht stimmit ist (wobei cih nicht weiß wer daran schuld hat, die quelle oder die mangelnde recherche des autors), auch windows hat eine methode, die ähnliches wie /dev/urandom unter linux leistet.

    ich kann ja gerne nacher nachschaun, wie die hieß.

  6. Re: Unstimmigkeiten

    Autor: hab (Golem.de) 24.08.13 - 11:44

    a user schrieb:
    --------------------------------------------------------------------------------
    > was im artikel aber noch nicht stimmit ist (wobei cih nicht weiß wer daran
    > schuld hat, die quelle oder die mangelnde recherche des autors), auch
    > windows hat eine methode, die ähnliches wie /dev/urandom unter linux
    > leistet.

    Doch, was im Artikel steht stimmt so schon. Natürlich hat Windows auch "irgendwas in der Art", das verhält sich aber nicht unbedingt gleich wie /dev/urandom. Löst also das Problem nicht, weil man sich wiederum als Programmierer nicht darauf verlassen kann, dass alle Lösungen das gleiche Verhalten an den Tag legen. Der Punkt von Boßlet ist ja gerade, dass man einheitliche, gut getestete und überprüfte Lösungen für Zufallszahlen bräuchte.

  7. Re: Unstimmigkeiten

    Autor: petera 26.08.13 - 06:45

    Oromit schrieb:
    > Das verstehe ich anders, es wird sehr wohl die pid des geforkten
    > unterprozesses genutzt. Es geht hier um das Szenario, bei dem ein neuer
    > Child-Prozess die selbe PID bekommt wie ein vorheriger, was auf häufig
    > forkenden systemen wie Android scheinbar recht häufig, oder zumindest nicht
    > ausreichend selten, vorkommt.

    Dafür existieren Patches, die dafür sorgen das die PID zufällig und nicht sequentiell vergeben wird. Das Problem ist wirklich neu, siehe kernel.pid_max (mag von verwendeten Kernel abhängen).

    > Das Problem tritt sehr wohl auch unter nicht-Debian-Derivaten auf. Wird der
    > userdata-Bereich vor dem aufruf von ssleay_rand_bytes initialisiert, ist
    > die entropie durch diesen nicht mehr vorhanden, da der "zufällige",
    > uninitialisierte speicher als entropiequelle genutzt wurde.
    > Genau das tut u.a. der Android OpenSSL wrapper, weshalb das Problem auch
    > unter Android auftritt.
    (...)
    > Einfach den Speicher nicht zu initialisieren ist allerdings auch keine
    > Alternative, da uninitialisieter Speicher nicht unbedingt eine verlässliche
    > Entropiequelle ist.

    Aus der OpenSSL-FAQ
    When OpenSSL's PRNG routines are called to generate random numbers the supplied buffer contents are mixed into the entropy pool: so it technically does not matter whether the buffer is initialized at this point or not. Valgrind (and other test tools) will complain about this. When using Valgrind, make sure the OpenSSL library has been compiled with the PURIFY macro defined (-DPURIFY) to get rid of these warnings.

    > Ein wenig Entropie aus /dev/urandom oder die Einberechnung der aktuellen
    > Zeit wären hier zu bevorzugen.

    Siehe oben, nicht jedes OS oder jeder Kernel stellt einen RNG/PRNG zur Verfügung, aus Sicht von OpenSSL ist die Vorgehensweise okay.
    Man nutzt keine aktuelle Zeit sonderen einen Zeit-Offset, -Modulo oder eine Differenz, das ist weit weniger deterministisch.

    Ich bin vor lachen vom Bürostuhl gefallen als ich (in Matrins Artikel):
    Much to my surprise, I could reproduce the repeated ‘random’ numbers on my laptop (running Linux Mint) but I could not when running it on my desktop (running Fedora).
    gelesen habe, ein Debian-Moment (Mint basiert auf Debian) http://xkcd.com/221/ - einer der Momente die rechtfertigen warum ich Debian und debianbasierte Distros nicht mehr verwende.

  8. Re: Unstimmigkeiten

    Autor: Oromit 26.08.13 - 06:49

    > Dafür existieren Patches, die dafür sorgen das die PID zufällig und nicht
    > sequentiell vergeben wird. Das Problem ist wirklich neu, siehe
    > kernel.pid_max (mag von verwendeten Kernel abhängen).

    Hilft auch nichts, wenn so viele prozesse erzeugt werden, dass die pids sich zwangsläufig irgendwann wiederholen.

    > Siehe oben, nicht jedes OS oder jeder Kernel stellt einen RNG/PRNG zur
    > Verfügung, aus Sicht von OpenSSL ist die Vorgehensweise okay.
    > Man nutzt keine aktuelle Zeit sonderen einen Zeit-Offset, -Modulo oder eine
    > Differenz, das ist weit weniger deterministisch.

    Was genau man jetzt nutzt, spielt absolut keine rolle, solange man es denn tut.

    > Ich bin vor lachen vom Bürostuhl gefallen als ich (in Matrins Artikel):
    > Much to my surprise, I could reproduce the repeated ‘random’
    > numbers on my laptop (running Linux Mint) but I could not when running it
    > on my desktop (running Fedora).
    > gelesen habe, ein Debian-Moment (Mint basiert auf Debian) xkcd.com - einer
    > der Momente die rechtfertigen warum ich Debian und debianbasierte Distros
    > nicht mehr verwende.

    Debian kann in diesem fall nichts dafür, da das problem sich auch sehr einfach unter jeder anderen distro reproduzieren lässt.
    Passiert halt, wenn man sich auf uninitialisierten speicher verlässt.

  9. Re: Unstimmigkeiten

    Autor: petera 26.08.13 - 07:57

    Oromit schrieb:
    > Was genau man jetzt nutzt, spielt absolut keine rolle, solange man es denn
    > tut.

    Jeder PRNG der nicht aussreichend Entropie im Seed oder seinem Akkumulator verwendet, wird ebenfalls versagen.

    > Debian kann in diesem fall nichts dafür, da das problem sich auch sehr
    > einfach unter jeder anderen distro reproduzieren lässt.

    Es war keine direkte Schuldzuweisung und scheinbar nicht immer und ohne weiteres.

    > Passiert halt, wenn man sich auf uninitialisierten speicher verlässt.

    Passiert halt wenn man einen schlechten PRNG und schlechte Entropie implementiert.

  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. Kommunale Unfallversicherung Bayern, München
  2. Vodafone GmbH, Unterföhring
  3. STADT ERLANGEN, Erlangen
  4. Hays AG, Frankfurt am Main

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-67%) 6,66€
  2. (-70%) 17,99€
  3. (-73%) 15,99€
  4. (-53%) 27,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Drohnen in der Stadt: Schneller als jeder Rettungswagen
Drohnen in der Stadt
Schneller als jeder Rettungswagen

Im Hamburg wird getestet, wie sich Drohnen in Städten einsetzen lassen. Unter anderem entsteht hier ein Drohnensystem, das Ärzten helfen soll.
Ein Bericht von Friedrich List

  1. Umweltschutz Schifffahrtsamt will Abgasverstöße mit Drohnen verfolgen
  2. Coronakrise Drohnen liefern Covid-19-Tests auf schottische Insel
  3. Luftfahrt Baden-Württemberg testet Lufttaxis und Drohnen

Realme 6 und 6 Pro im Test: Starke Konkurrenz für Xiaomi
Realme 6 und 6 Pro im Test
Starke Konkurrenz für Xiaomi

Das Realme 6 und 6 Pro bieten eine starke Ausstattung für relativ wenig Geld - und gehören damit aktuell zu den interessantesten Mittelklasse-Smartphones.
Ein Test von Tobias Költzsch


    Zhaoxin KX-U6780A im Test: Das kann Chinas x86-Prozessor
    Zhaoxin KX-U6780A im Test
    Das kann Chinas x86-Prozessor

    Nicht nur AMD und Intel entwickeln x86-Chips, sondern auch Zhaoxin. Deren Achtkern-CPU fasziniert uns trotz oder gerade wegen ihrer Schwächen.
    Ein Test von Marc Sauter und Sebastian Grüner

    1. KH-40000 & KX-7000 Zhaoxin plant x86-Chips mit 32 Kernen