5 ms·

FYI - I signed up and the email confirmation page showed me someone else's canary URL

jstanley 9y ago
That's not good! Taking a look. EDIT: I believe it's because the CSPRNG state ( https://metacpan.org/pod/Bytes::Random::Secure::Tiny https://metacpan.org/pod/Bytes::Random::Secure::Tiny ) was created before the process forks, so they shared the initial state and generated the same token. I've reduced it to 1 worker pending an actual fix. Sorry about that, and thanks for pointing it out.
- beefhash 9y ago
  Given this kind of disaster potential, wouldn't it be a rather attractive option to use /dev/urandom?
  - jstanley 9y ago
    Bytes::Random::Secure::Tiny seeds itself from /dev/urandom, I just need to make sure to initialise it on first use, instead of when my program first starts (which I've now done). In general I suspect if anything you'd be more likely to mess it up by reading bytes from /dev/urandom manually than by using a library.
    - rocqua 9y ago
      I though the main issue of reading bytes from /dev/urandom was performance (ignoring the issue of ensuring /dev/urandom has been initialized since boot.) So instead, we use them to seed CPRNGs, and use them for speed.
    - stouset 9y ago
      How exactly can one mess up reading bytes from `/dev/urandom`? Serious question. Open the file. Read from it. If no failures on open or read, you have random bytes. In essence, there is already a library for this: `open` and `read`, which seems to be the same API surface area as this library.
      - beefhash 9y ago
        Here's all the ways this can possibly go wrong: https://insanecoding.blogspot.com/2014/05/a-good-idea-with-bad-usage-devurandom.html https://insanecoding.blogspot.com/2014/05/a-good-idea-with-b...
        stouset 9y ago
        Most of these are ridiculous. First, the author mentions that a `read` from urandom can be interrupted. I am unaware of any system where this is actually possible. And even if it were, the author's original code (and my description of an implementation) already works! The `read` call will return an error, and that error is handled. His "improved" code is simply an optimization around retrying from this device, but it's not an improvement in safety. His second argument is that /dev/urandom might not have enough randomness in it. This is, quite simply, not a concern for anyone not writing code for specific embedded devices or for extremely early in the kernel boot process. Anyone who is writing code for these environments is almost certainly already aware of these limitations. And even then, using a library like the one the GP is using doesn't actually help, since it's virtually guaranteed to just be reading bytes from `/dev/urandom` for its seed in the first place. The rest go into situations that — quite frankly — border on ludicrous. If someone has replaced your `/dev/random` with `/dev/zero`, you have already lost and there is nothing you can or should reasonably do besides nuke the machine from orbit.
- bmm6o 9y ago
  There was a recent discussion about (not) sharing CSPRNG state with fork-ed processes: https://news.ycombinator.com/item?id=15759855 https://news.ycombinator.com/item?id=15759855
- moltar 9y ago
  +1 for using Perl Care to share your stack?
  - jstanley 9y ago
    Hey, sorry for the late reply. Not sure if you'll read this... It's mostly http://mojolicious.org/ http://mojolicious.org/ SQLite for the database (for now; that'll change if it gets too big), and nginx as a reverse proxy in front of Mojolicious. CentOS 7.
    - moltar 9y ago
      Cool thank you for response.
- pinum 9y ago
  This implies that you should probably invalidate all URLs created before you applied that mitigation, right? Or do you have some way (logs?) of knowing which ones were compromised?
oh_sigh 9y ago
Well, did you go to the URL so that that user will know they used an insecure service?
- brianwawok 9y ago
  They forgot to dogfood their own product

That's not good! Taking a look. EDIT: I believe it's because the CSPRNG state ( https://metacpan.org/pod/Bytes::Random::Secure::Tiny https://metacpan.org/pod/Bytes::Random::Secure::Tiny ) was created before the process forks, so they shared the initial state and generated the same token. I've reduced it to 1 worker pending an actual fix. Sorry about that, and thanks for pointing it out.

beefhash 9y ago
Given this kind of disaster potential, wouldn't it be a rather attractive option to use /dev/urandom?
- jstanley 9y ago
  Bytes::Random::Secure::Tiny seeds itself from /dev/urandom, I just need to make sure to initialise it on first use, instead of when my program first starts (which I've now done). In general I suspect if anything you'd be more likely to mess it up by reading bytes from /dev/urandom manually than by using a library.
  - rocqua 9y ago
    I though the main issue of reading bytes from /dev/urandom was performance (ignoring the issue of ensuring /dev/urandom has been initialized since boot.) So instead, we use them to seed CPRNGs, and use them for speed.
  - stouset 9y ago
    How exactly can one mess up reading bytes from `/dev/urandom`? Serious question. Open the file. Read from it. If no failures on open or read, you have random bytes. In essence, there is already a library for this: `open` and `read`, which seems to be the same API surface area as this library.
    - beefhash 9y ago
      Here's all the ways this can possibly go wrong: https://insanecoding.blogspot.com/2014/05/a-good-idea-with-bad-usage-devurandom.html https://insanecoding.blogspot.com/2014/05/a-good-idea-with-b...
      - stouset 9y ago
        Most of these are ridiculous. First, the author mentions that a `read` from urandom can be interrupted. I am unaware of any system where this is actually possible. And even if it were, the author's original code (and my description of an implementation) already works! The `read` call will return an error, and that error is handled. His "improved" code is simply an optimization around retrying from this device, but it's not an improvement in safety. His second argument is that /dev/urandom might not have enough randomness in it. This is, quite simply, not a concern for anyone not writing code for specific embedded devices or for extremely early in the kernel boot process. Anyone who is writing code for these environments is almost certainly already aware of these limitations. And even then, using a library like the one the GP is using doesn't actually help, since it's virtually guaranteed to just be reading bytes from `/dev/urandom` for its seed in the first place. The rest go into situations that — quite frankly — border on ludicrous. If someone has replaced your `/dev/random` with `/dev/zero`, you have already lost and there is nothing you can or should reasonably do besides nuke the machine from orbit.
bmm6o 9y ago
There was a recent discussion about (not) sharing CSPRNG state with fork-ed processes: https://news.ycombinator.com/item?id=15759855 https://news.ycombinator.com/item?id=15759855
moltar 9y ago
+1 for using Perl Care to share your stack?
- jstanley 9y ago
  Hey, sorry for the late reply. Not sure if you'll read this... It's mostly http://mojolicious.org/ http://mojolicious.org/ SQLite for the database (for now; that'll change if it gets too big), and nginx as a reverse proxy in front of Mojolicious. CentOS 7.
  - moltar 9y ago
    Cool thank you for response.
pinum 9y ago
This implies that you should probably invalidate all URLs created before you applied that mitigation, right? Or do you have some way (logs?) of knowing which ones were compromised?

oh_sigh 9y ago

Well, did you go to the URL so that that user will know they used an insecure service?

brianwawok 9y ago
They forgot to dogfood their own product