10 ms·
Critical PRNG Bug in NetBSD Kernel
- jimktrains2 14y ago> Due to a misplaced parenthesis... I know this isn't the (main) take away message, but it does make me feel a little better about some errors I've made in the past to know that even heavily vetted code can have these types of errors.
- CasimirCelerity 14y agoI don't know if this code would qualify as "heavily vetted." Thor Lancelot Simon wrote it himself and imported it himself into the tree for NetBSD v6 and onwards. Probably hasn't seen that many eyes for review.
- jimktrains2 14y agoI just assumed kernel code would have at least someone else looking over it before it's merged in.
- sliverstorm 14y agoMaybe it does, but they won't be looking for misplaced parens.
- asveikau 14y agoBecause in kernel mode it's impossible to make (and subsequently gloss over) simple mistakes? This hasn't been my experience.
- yk 14y agoDue to a misplaced parenthesis, if insufficient GOOD bits were available to satisfy a request, the keying/rekeying code requested either 32 or 64 ANY bits, rather than the balance of bits required to key the stream generator. I think this paragraph is a nice reminder, how hard crypto can be.
- marshray 14y agoA misplaced parenthesis can corrupt output data from an ordinary programs too. But with crypto, severe problems have a much easier time staying silent through QA and interop testing, and widespread usage. I think it's because the concept of "cryptographically secure" is essentially trying to prove a negative. That's hard enough in general, but especially hard to do about an intelligent adversary whom you may not even know anything about. You're trying to prove that no present or future attacker will be able to obtain any information which can allow him to unravel your secrets. Crypto is about building sky castles full of really really long secrets floating on foundations of really small ones, and then tossing them all up in the air to yourself as you run down the street backwards with rabid weasels chasing you.
- caf 14y agoIn particular CSPRNGs, because the output of a fatally flawed CSPRNG and a secure CSPRNG can look very similar. This is also why CSPRNGs are a great place to hide backdoors.
- yk 14y agoBackdoor in the sense of leaking state? And is there a case in the wild ( except the PS3 hack?)?
- simcop2387 14y agoThe debian certificate instance is a good example too. http://digitaloffense.net/tools/debian-openssl/ http://digitaloffense.net/tools/debian-openssl/
- marshray 14y agoBest paper Usenix Security '12. Nadia Heninger, UC San Diego; Zakir Durumeric, University of Michigan; Eric Wustrow and J. Alex Halderman, University of Michigan https://www.usenix.org/conference/usenixsecurity12/mining-your-ps-and-qs-detection-widespread-weak-keys-embedded-devices https://www.usenix.org/conference/usenixsecurity12/mining-yo... "We find that 0.75% of TLS certificates share keys due to insufficient entropy during key generation, and we suspect that another 1.70% come from the same faulty implementations and may be susceptible to compromise. Even more alarmingly, we are able to obtain RSA private keys for 0.50% of TLS hosts and 0.03% of SSH hosts, because their public keys shared nontrivial common factors due to entropy problems, and DSA private keys for 1.03% of SSH hosts, because of insufficient signature randomness." Ron was wrong, Whit is right Arjen K. Lenstra and James P. Hughes and Maxime Augier and Joppe W. Bos and Thorsten Kleinjung and Christophe Wachter http://eprint.iacr.org/2012/064 http://eprint.iacr.org/2012/064
- jey 14y agoAnyone have a link to the actual patch?
- Mithrandir 14y agohttp://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/subr_cprng.c.diff?r1=1.14&r2=1.15&only_with_tag=MAIN&f=h http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/subr_cprng.... Fix a security issue: when we are reseeding a PRNG seeded early in boot before we had ever had any entropy, if something else has consumed the entropy that triggered the immediate reseed, we can reseed with as little as sizeof(int) bytes of entropy.
- jey 14y agoThe misplaced right-paren is in this line: rnd_extract_data(key + r, sizeof(key - r), RND_EXTRACT_ANY);
- deleted 14y ago[deleted]
- beering 14y agoThe advisory says that reading from /dev/random is fine, but reading from /dev/urandom is affected. Shouldn't cryptographic applications be using /dev/random to begin with? I was under the impression that /dev/urandom is only for when low-quality randomness is acceptable.
- handsomeransoms 14y ago/dev/urandom is supposed to provide cryptographic quality randomness. /dev/random does provide "better" randomness, in a sense, but may be blocking - it is typically used for the generation of long-term cryptographic keys (like GPG keys).
- marshray 14y agoThe only time that ought to make a difference in a modern properly-implemented CSPRNG is right after system startup when very little unpredictability has made it into the pool. Consequently, system boot scripts are just about the worst possible place to generate new keys if they didn't already exist.
- gizmo686 14y agoFrom the manpage of /dev/random "If a seed file is saved across reboots as recommended below (all major Linux distributions have done this since 2000 at least), the output is cryptographically secure against attackers without local root access as soon as it is reloaded in the boot sequence, and perfectly adequate for network encryption session keys. Since reads from /dev/random may block, users will usually want to open it in nonblocking mode (or perform a read with timeout), and provide some sort of user notification if the desired entropy is not immediately available."
- marshray 14y agoOnly if the seed file was was generated by a secure kernel during a clean shutdown and kept secret during that whole time. There's a lot to go wrong there, especially if you're an embedded system running on flash. I also seem to recall host keys being generated on first boot. Perhaps some installers are smart enough to prime that seed file.
- kilovoltaire 14y agoI enjoyed the Thanks To section: Thor Lancelot Simon for causing, finding and fixing the bug
- martinced 14y ago"Due to a misplaced parenthesis..." Is this RNG written in Lisp!? Sorry, couldn't resist ; ) (big fan of Clojure and elisp here btw)
- marshray 14y agoERROR: LINE 3, COLUMN 26 ERROR: UNMATCHED RIGHT PARENTHESIS ENCOUNTERED. ERROR: WHILE PROCESSING INPUT: 1 2 3 4 5 6 7 123456789012345678901234567890123456789012345678901234567890123456789012 Sorry, couldn't resist ; ) (big fan of Clojure and elisp here btw) ^ | ERROR: PROCESSING WILL CONTINUE WITH THE NEXT AVAILABLE INPUT TOKEN. ERROR: ALL YOUR BASE ARE BELONG TO US.
- vincie 14y agoDoes vim have a plugin to detect unbalanced parens/brackets/braces etc?
- quacker 14y agoDoesn't need a plugin: http://stackoverflow.com/questions/232274/how-do-i-get-vim-to-highlight-matching-parenthesis http://stackoverflow.com/questions/232274/how-do-i-get-vim-t... There's also some info and some plugins listed here: http://vim.wikia.com/wiki/VimTip630 http://vim.wikia.com/wiki/VimTip630 Although, a misplaced parentheses could still be balanced. For example, if ((!x < y)) ... versus if (!(x < y)) ...
- ams6110 14y agoThe parens were not unbalanced, that would very likely not even compile. They were misplaced, a much more subtle mistake.
- xkcdfanboy 14y agoJust in case anyone is curious, the error was having `sizeof(key - r)` instead of `sizeof(key) - r` Rookie mistake!
- riffraff 14y agoI wonder, what sort of technology would have avoided this? The "key -r" bit seems a bit suspicious type wise
- marshray 14y agoYeah, why would you care about the size of a temporary arithmetic expression?
- ElectroPrime 14y agoWell... sizeof of an expression is mostly useful for not repeating yourself in cases when you need the size of a type you already have some way of referencing, as in a = malloc(sizeof(*a)); It's also useful for various hacks (stuff like compile-time assert macros), since it doesn't evaluate the expression, only its type.
- marshray 14y agoSure, I can think of plenty of ways it could arise via metaprogramming. I don't know if I would want such a warning enabled in my own template-heavy C++ code. But it perhaps it could be useful for those following the NetBSD style. :-)
- pizza_ 14y agosizeof is an operator, no need for the inner parens.
- Tobu 14y ago-Wsizeof-pointer-memaccess (Clang and GCC 4.8) is the only sizeof-related warning I know of, which warns about some cases where both pointer and size are immediately passed to a handful of builtin functions (in GCC, some among mem…, str…, s…printf). C's typing is much too weak for -Wsizeof-pointer-memaccess to be generally useful. Without getting into typing, a simple warning: arithmetic inside sizeof would catch this. I don't think it would catch much noise, I don't see any useful uses of pointer arithmetic immediately inside a sizeof. It's a bit specific though, are there more functions that would benefit as well?