4 ms·

It seems json-c uses a random number generator to get a seed that it then uses for string hashing. This is one way of protecting yourself against hash denial-of

by dajoh 6y ago

It seems json-c uses a random number generator to get a seed that it then uses for string hashing. This is one way of protecting yourself against hash denial-of-service attacks. https://github.com/json-c/json-c/blob/df27756491abf9ecce648c3aa85d6a70feb4c600/linkhash.c#L469 https://github.com/json-c/json-c/blob/df27756491abf9ecce648c...

benlivengood 6y ago
> This is one way of protecting yourself against hash denial-of-service attacks. Ironic, in this case. And the fix isn't much better; there's no guarantee that RDRAND won't revert to the -1 behavior after the check runs, perhaps after a VM migration or resume from suspend or what-not. Overall RDRAND seems to be a terrible userspace instruction. Special-casing its use sounds more complicated then proper multi-platform support for system RNGs.
- fluix 6y ago
  > [...] there's no guarantee that RDRAND won't revert to the -1 behavior after the check runs, perhaps after a VM migration or resume from suspend or what-not. Author here. This is true and is an issue with some CPUs (breaking RDRAND after resume), but every call to RDRAND is guarded[1] by a check that it works. [1]: https://github.com/json-c/json-c/blob/041cef434afe0d0c6da8b6ac1d1fa26087246dda/random_seed.c#L324 https://github.com/json-c/json-c/blob/041cef434afe0d0c6da8b6... Edit: Ah, I just realized you stated "after the check runs" and you're correct, there's no way that can be guaranteed. Edit 2: Well, if RDRAND returns a value json-c can't use (-1) it won't be used.
  - benlivengood 6y ago
    Most unixes on x86 optionally use RDRAND to add entropy to the /dev/random pool and I see that Win32 is also covered in json-c, so I don't see the benefit of explicit support for RDRAND in the critical path at least. RDRAND may also be slow: https://www.phoronix.com/scan.php?page=news_item&px=RdRand-3-Percent https://www.phoronix.com/scan.php?page=news_item&px=RdRand-3... Ultimately I think it was a mistake for Intel to try to provide user-level hardware random number generation. It's apparently not an easily solved problem and requires complete trust in the hardware and a fallback TRNG/HRNG that's just as secure if the hardware reports that it's not working. Why not just use the fallback all the time? System-level entropy pools are pretty well-studied at this point.
    - PhantomGremlin 6y ago
      I think it was a mistake for Intel to try to provide user-level hardware random number generation. They probably did this for speed. Faster than library calls or system calls. It's apparently not an easily solved problem Apparently too hard for the clowns at AMD. AFAIK it's a "solved problem" on Intel hardware. (Has there ever been a problem with the hardware in any Intel CPU?) We wouldn't be having this discussion if AMD hadn't royally fucked this up.
      - bigiain 6y ago
        > (Has there ever been a problem with the hardware in any Intel CPU?) FOOF... ( https://en.wikipedia.org/wiki/Pentium_F00F_bug https://en.wikipedia.org/wiki/Pentium_F00F_bug Admittedly that was in the 90s... )
        PhantomGremlin 6y ago
        Sorry about that. FOOF did cause some people headaches. I should have more specifically said, "has there been a problem with RDRAND hardware in any Intel CPU?" FOOF wasn't a "real" problem for an average user, it had some workarounds. It wasn't even triggered unless you tried to execute an invalid instruction. Much much much worse was the Intel FDIV bug. That one caused Intel to recall processors and cost them $475 million. https://en.wikipedia.org/wiki/Pentium_FDIV_bug https://en.wikipedia.org/wiki/Pentium_FDIV_bug Lots of jokes resulted. E.g.: We are Pentium of Borg. Division is futile. You will be approximated. As for RDRAND, Intel put a lot of thought into it. It wasn't just a hack. Here's a high level presentation. (A friend of mine at Intel thought highly of Dr. George Cox, who was a long time Intel employee). https://old.hotchips.org/wp-content/uploads/hc_archives/hc23/HC23.18.2-security/HC23.18.210-Random-Numbers-Cox-Intel-e.pdf https://old.hotchips.org/wp-content/uploads/hc_archives/hc23... Here's a little more detail: https://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator https://spectrum.ieee.org/computing/hardware/behind-intels-n...
      - rurban 6y ago
        rdrand besides most likely backdoored is not fast. It's like 1000x slower than the slowest prng call on an unpatched Ryzen. https://rurban.github.io/dieharder/QUALITY.html https://rurban.github.io/dieharder/QUALITY.html
  - kelnos 6y ago
    Ugh, this is... unfortunate. Are there really any systems for which all the other options for randomness are not available? I really think there aren't. RDRAND should be near the bottom of the list of things it tries (or just be dropped entirely), not the top. Wasting time trying to patch over its misbehaviors is just overengineering.

by dajoh 6y ago

benlivengood 6y ago

> This is one way of protecting yourself against hash denial-of-service attacks. Ironic, in this case. And the fix isn't much better; there's no guarantee that RDRAND won't revert to the -1 behavior after the check runs, perhaps after a VM migration or resume from suspend or what-not. Overall RDRAND seems to be a terrible userspace instruction. Special-casing its use sounds more complicated then proper multi-platform support for system RNGs.

fluix 6y ago
> [...] there's no guarantee that RDRAND won't revert to the -1 behavior after the check runs, perhaps after a VM migration or resume from suspend or what-not. Author here. This is true and is an issue with some CPUs (breaking RDRAND after resume), but every call to RDRAND is guarded[1] by a check that it works. [1]: https://github.com/json-c/json-c/blob/041cef434afe0d0c6da8b6ac1d1fa26087246dda/random_seed.c#L324 https://github.com/json-c/json-c/blob/041cef434afe0d0c6da8b6... Edit: Ah, I just realized you stated "after the check runs" and you're correct, there's no way that can be guaranteed. Edit 2: Well, if RDRAND returns a value json-c can't use (-1) it won't be used.
- benlivengood 6y ago
  Most unixes on x86 optionally use RDRAND to add entropy to the /dev/random pool and I see that Win32 is also covered in json-c, so I don't see the benefit of explicit support for RDRAND in the critical path at least. RDRAND may also be slow: https://www.phoronix.com/scan.php?page=news_item&px=RdRand-3-Percent https://www.phoronix.com/scan.php?page=news_item&px=RdRand-3... Ultimately I think it was a mistake for Intel to try to provide user-level hardware random number generation. It's apparently not an easily solved problem and requires complete trust in the hardware and a fallback TRNG/HRNG that's just as secure if the hardware reports that it's not working. Why not just use the fallback all the time? System-level entropy pools are pretty well-studied at this point.
  - PhantomGremlin 6y ago
    I think it was a mistake for Intel to try to provide user-level hardware random number generation. They probably did this for speed. Faster than library calls or system calls. It's apparently not an easily solved problem Apparently too hard for the clowns at AMD. AFAIK it's a "solved problem" on Intel hardware. (Has there ever been a problem with the hardware in any Intel CPU?) We wouldn't be having this discussion if AMD hadn't royally fucked this up.
    - bigiain 6y ago
      > (Has there ever been a problem with the hardware in any Intel CPU?) FOOF... ( https://en.wikipedia.org/wiki/Pentium_F00F_bug https://en.wikipedia.org/wiki/Pentium_F00F_bug Admittedly that was in the 90s... )
      - PhantomGremlin 6y ago
        Sorry about that. FOOF did cause some people headaches. I should have more specifically said, "has there been a problem with RDRAND hardware in any Intel CPU?" FOOF wasn't a "real" problem for an average user, it had some workarounds. It wasn't even triggered unless you tried to execute an invalid instruction. Much much much worse was the Intel FDIV bug. That one caused Intel to recall processors and cost them $475 million. https://en.wikipedia.org/wiki/Pentium_FDIV_bug https://en.wikipedia.org/wiki/Pentium_FDIV_bug Lots of jokes resulted. E.g.: We are Pentium of Borg. Division is futile. You will be approximated. As for RDRAND, Intel put a lot of thought into it. It wasn't just a hack. Here's a high level presentation. (A friend of mine at Intel thought highly of Dr. George Cox, who was a long time Intel employee). https://old.hotchips.org/wp-content/uploads/hc_archives/hc23/HC23.18.2-security/HC23.18.210-Random-Numbers-Cox-Intel-e.pdf https://old.hotchips.org/wp-content/uploads/hc_archives/hc23... Here's a little more detail: https://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator https://spectrum.ieee.org/computing/hardware/behind-intels-n...
    - rurban 6y ago
      rdrand besides most likely backdoored is not fast. It's like 1000x slower than the slowest prng call on an unpatched Ryzen. https://rurban.github.io/dieharder/QUALITY.html https://rurban.github.io/dieharder/QUALITY.html
- kelnos 6y ago
  Ugh, this is... unfortunate. Are there really any systems for which all the other options for randomness are not available? I really think there aren't. RDRAND should be near the bottom of the list of things it tries (or just be dropped entirely), not the top. Wasting time trying to patch over its misbehaviors is just overengineering.