Are you saying you are not using RANDOM_EXTEND_WITH_PSEUDO|RANDOM_DONT_DRAIN|RANDOM_ALLOW_RDRAND for DNS TRXIDs? twitter.com/rfc1459/status
Conversation
Replying to
Yes, we do. But DNS transactions IDs are hardly a cryptographic concept, are they? I mean, if DNS transaction IDs is what you build your security on, then you probably didn't understand security very well. It's a 16bit field, ffs... wherever we pull the transaction ID (cont)
1
1
2
from, it's easily guessable. Hence, yes, we use getrandom() preferably to generate them, but if we can't use that, it's not going to make a crappy security measuer much crappier if we eventually go for rand() for them. This is early boot stuff again, (cont)
1
not quite as early as PID 1, but still quite early, since used for finding remote storage in the initrd, and so on. And no, I dn't think it's worth letting the boot in virtualized environments hang for 5min or more just because you boot from an HTTP image...
1
Replying to
No, you don't use getrandom if RDRAND is available (RANDOM_ALLOW_RDRAND), so on that machine with a broken RDRAND your DNS client is vulnerable to textbook cache poisoning attacks.
Yes, 16 bits is a very slim security margin, but enough for ephemeral values, if it's good random.
2
3
Anything actually depending on the security of DNS such as SPF / DKIM / DMARC for email or Domain Validated certificate issuance should be using DNSSEC. It's not just a slim security margin. It completely doesn't work against an attacker with control / influence over the network.
2
This misses the point. There is no excuse for a random number generator to behave like that in 2019.
1
1
What do you mean specifically? RDRAND? It's specified as possibly failing anyway. If you mean getrandom, it only blocks until there are at least 128 bits of entropy, which is a non-issue in any environment that's not broken. I wouldn't work around it like they're doing.
2
1
But for example, for GrapheneOS, the 1st generation Pixels don't pass entropy in early boot from the bootloader, so there is a point in early init before hw_random is brought up that there isn't enough entropy available for getrandom to avoid blocking.
2
I remember calling into TZ to get randomness during kernel initialization, effectively accessing hardware PRNG before device driver was ready. Should be around Nexus6p timeframe. Not sure what happens in recent kernels.
1
Qualcomm's newer bootloader supports EFI_RNG_PROTOCOL so the kernel can ask it for entropy. The kernel uses it for the kaslr and more recently to seed the CSPRNG. Not really a great trade-off for all the attack surface added by UEFI but at least this issue is largely resolved.
Well one could only push back against UEFI so much. It was also surprisingly challenging to add basic countermeasures like DEP to UEFI.
1