
“RNG broken for last 4 months” - svoyage
https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054580.html
======
emaste
Note that this is FreeBSD-CURRENT only, i.e. the development branch. This does
not affect FreeBSD releases.

~~~
tptacek
Word on Twitter is that there are some pretty major companies on -CURRENT.

~~~
numbsafari
Then they deserve what they get.

Honestly, this is probably some kind of confusion over a company or two that
has -CURRENT as an upstream to their own fork of the OS because they are
reliant on some kind of new changes in the system that aren't in -STABLE.

Even if that's the case, you'd hope they'd be taking extra special precautions
considering what they are doing.

~~~
javert
No they don't. It's reasonable to trust that FreeBSD is providing decent RNG.
Even in the dev branch. I mean, why would they not?

Don't blame the user for upstream's mistake.

Do FreeBSD developers (I mean, the ones who had nothing to do with this but
also use the dev branch) "deserve" it, too?

In general, do you always blame the victim for someone else's mistakes?

edit: I am not a BSD user. I am reading now that the dev branch is _purposely_
crippled anyway and known to be terribly unstable. If that's the case, maybe
it is idiotic for non-developers to use it. I'll leave this comment here
instead of deleting in so nobody else says the same thing. In the meantime,
I'm glad to be using a rolling release Linux distro that always has bleeding-
edge software without ever having any problems.

~~~
girvo
_> bleeding-edge software without ever having any problems_

Did you seriously just suggest that Arch never has any issues? How did you
manage to achieve that, because I gave up on Arch due to it breaking at least
once a fortnight. The "bleeding edge" is called that for a reason: you're
likely to bleed when using it.

~~~
Tiksi
I run arch with the testing repos on both my work and home desktops, and the
normal repos on one of my servers, and I've had updates break things exactly
once between them (broadcom NIC wouldn't come up on my home desktop), and the
fix was just a matter of rolling back 1 kernel version. So I guess YMMV?

------
tptacek
Approximately the worst possible vulnerability, arguably worse than kernel
RCE, because a kernel RCE requires an active attacker to intersect with the
vulnerable host while it's still there; the broken RNG will leak secrets that
will be usable retroactively.

Ouch.

~~~
drostie
Well, no. It was caught in the CURRENT branch -- i.e. latest-and-greatest
snapshots for developers. Users who use this branch are supposed to accept
some breakage here and there.

Security requires a threat model. Something can only be "the worst possible
vulnerability" if it causes a large amount of damage consistent via the
threats which are in the model. The threats that you're thinking of are not
usually contained within the models of cutting-edge-dev-systems, which will be
protected by firewalls etc. on intranets.

There's really a need in both cases for "an active attacker to intersect with
the vulnerable host while it's still there." A broken RNG in such
circumstances is much, much weaker than kernel RCE.

~~~
tptacek
It's a weird rhetorical position you're putting me in, where to agree with you
I'd have to simultaneously accept that -CURRENT isn't widely deployed
(reasonable!) _and_ that a broken kernel RNG isn't a game-over flaw (not so
reasonable!).

~~~
drostie
The reason that the latter point is reasonable is, it trivially isn't a game-
over flaw for systems which do not have game-overs.

What we know about every system that installed FreeBSD-CURRENT is that the
systems administrators at the time fully accepted an operating system:

1\. That is not in any way "officially supported". (FreeBSD's words, not
mine.)

2\. that may for short periods of time "not be buildable."

3\. that "is not a quick way of getting bug fixes as any given commit is just
as likely to introduce new bugs as to fix existing ones".

4\. that is much weaker in guarantees than the FreeBSD-STABLE branch, which
expressly disclaims, "one should not blindly track FreeBSD-STABLE. It is
particularly important not to update any production servers to FreeBSD-STABLE
without thoroughly testing the code in a development or testing environment."

If someone has signed off on these topics, then there is no such thing as
"game over". The server isn't important enough for "game over". If it is, then
the security vulnerability was not the broken RNG but tracking FreeBSD-CURRENT
in the first place.

~~~
nitrogen
Suppose a developer generated an ssh key while running -current and shared
/home with -stable. Then the vulnerability would long outlast the use of
-current.

------
0x0
Would a broken RNG be a risk to leak private keys? As in, even if the key was
_generated_ on a safe kernel, merely using the key to encrypt or sign data on
the broken kernel would compromise the keys?

This article mentions DSA private keys and poor RNGs:
[http://rdist.root.org/2010/11/19/dsa-requirements-for-
random...](http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-
value/)

~~~
tylersmith
Yes, even with correctly generated keys if you perform DSA signatures with a
broken RNG you risk reusing a k value which will leak your private key.

~~~
caf
You don't even have to re-use a k value - if the attacker can guess your k
value, _one_ signature is enough to recover your private key.

------
autoreleasepool
Reading the comments here is somewhat frustrating. Even the most recent ones
seem to miss the significance of the RNG bug being in the -CURRENT branch
only.

They found a bug, and it will be fixed. The fact that this bug was found in
-CURRENT is a good a thing. This is a pre-alpha, not for production release.
The development model is working as intended, no?

~~~
jsmthrowaway
I think the tide of blaming people running CURRENT and attempting to dismiss
the issue instead of addressing the extremely serious vulnerability is
troubling, since even in the limited Venn diagram of people I know that run
FreeBSD, one of them matches this template:

1\. STABLE prod fleet

2\. CURRENT dev workstation

3\. TLS certificate private keys in prod generated on CURRENT workstation to
be signed by authority

4\. Potentially vulnerable TLS keys existing in STABLE fleet

You folks can twist this to try to deflect severity by pointing to CURRENT,
but in the real world, it existing at all for four months is extremely serious
and must be taken seriously. My production TLS keys were created on my OS X
laptop, because I don't often have to think about a compromised random number
generator and this is a tradeoff I make in my own life.

I guess if I truly cared about my TLS keys, I should have made them on a copy
of airgapped Warty Warthog and run them through a shitload of random analysis
tools before shipping them off to be signed. My bad.

~~~
barkingcat
You might want to ask them again if 2 is true. In reality, I highly doubt they
really use what you described in point 2. (or it's a miscommunication).

Unless they recompile world all the time (a nontrivial amount of work and a
waste of time if you are not actively developing the OS itself) - CURRENT is
actually much much slower because of debugging flags that are enabled by
default. Some of these flags make the kernel panic upon certain types of
errors and drop into kernel debugging mode allowing the examination of kernel
dumps. I can't fathom why anyone would generate real security certificates in
this kind of environment.

You can recompile with the WITNESS (kernel lock counting & validation - incurs
performance loss but useful for counting kernel data structures) and
INVARIANTS (run-time assertion checks and tests for kernel data structures)
options off, but then you would have to spend time recompiling the kernel
instead of working on your software.

[https://www.freebsd.org/doc/en/books/developers-
handbook/ker...](https://www.freebsd.org/doc/en/books/developers-
handbook/kerneldebug-options.html)

Note that CURRENT is packaged as snapshot binaries without binary upgrade
capability - which means that once you install "one day's" -CURRENT the only 2
ways to upgrade are a) download the new iso and reinstall the entire OS or b)
check out the freebsd source code via svn and recompile the system (often
world changes as well so you need to do both kernel + userland).

If 2. is actually true, then the person you know who is doing that, unless
they are being paid to work on freebsd features or perhaps validating and
porting freebsd to a different hardware platform like ARM or PS4 or an
embedded device like a medical imaging device or a router (ie Junos), they are
wasting a lot of their employer's time and foot-gunning themselves massively
in security.

If you show them this post, ask them what they are doing with -CURRENT?

I am open to learning new things so I'd really like to know!

~~~
barkingcat
I spent way too much typing this reply. I should just join the freebsd
development team and learn the answer to my own question.

Thinking about this again - yah - the poster might be referring to some kind
of workflow like this:

production machines are platforms that run -STABLE

there is some kind of device, embedded or otherwise, that they keep locked up
somewhere in a lab. It could be the new xxyz multicore switching fabric
[imaginary name] that is running a new version of BSD-OS variant that's
undergoing verification testing - they run hardware development and need
-CURRENT's capabilities for debugging the system itself. It generates some
keys that will be distributed into the pool of machines running -STABLE so
that in the future, when this new variant comes into the market, there will be
"pre-seeded" keys for compatability (ie. older versions of systems will be
able to interact via signed certs with the new system)

Since FreeBSD _is_ BSD licensed, there can be any number of things people are
doing with it without anyone else knowing - so maybe to give the benefit of
the doubt, I can envision a workflow that needs -CURRENT as a workstation /
dev platform.

I think one weakness to my thinking is that VARIANTS/WITNESS/kdb/ddb can be
enabled on -RELEASE and -STABLE distributions as well! Why not just do
everything on -STABLE even if you need kernel debugging?

If they need -CURRENT for new hardware support, it shouldn't be too hard to
figure out from the svn log and the rolling release notes. It's kinda fun
trying to reverse engineer the job of the thread parent's acquaintance!

------
Someone1234
As a bit of a tangent: Does this happen semi-regularly because proving
"randomness" is so difficult? Is there a system which can, with enough data,
show that something is at least nth degree of randomness or is such a thing
impossible mathematically?

~~~
jackweirdy
I’m curious about that too. How could you unit/regression test `rand`?

~~~
fixermark
Statistic testing seems like it ought to work. However, I believe there's also
the issue of actual uses of the RNG; it's not enough to test the kernel
implementation, one must also test that libraries are using the implementation
correctly (i.e. not using constant or completely-predictable seed), etc.

So it's not a trivial problem, because (among other reasons) nondeterministic,
statistical testing is not well-understood in the testing culture.

~~~
tedunangst
Further complication: many RNGs will produce output as a function of their
seed state (e.g., rc4 or chacha20). That output will look really good, even
with weak seeds. You'll have a hard time detecting that two chacha20 streams
were seeded with gettimeofday() for instance, unless you happen to check the
exact time used.

------
dpkendal
Bears repeating: this does _not_ affect stable versions of FreeBSD. FreeBSD-
CURRENT is the development version.

------
gtirloni
I fail to see how a bug in a development branch that nobody should be using in
production is worth discussing, from a security incident perspective. Perhaps
ways of catching that category of bug in an automated way would be an
interesting topic.

------
comboy
Does that mean that current/boot time was used as seed i.e. there was no seed,
or just that it was something weaker than normally used?

~~~
emaste
There is much less entropy than there should be, but more than none.

------
peterwwillis
Would Dieharder have caught this?

~~~
ReidZB
Probably, yes. Upthread, someone looked at the code and suggested that it fell
back on a linear congruential generator as an RNG. If that is true, I'd expect
the Dieharder tests to fail it.

~~~
mzs
Boy I wish this was up higher, thanks!

[http://en.wikipedia.org/wiki/Diehard_tests](http://en.wikipedia.org/wiki/Diehard_tests)

------
jacquesm
Maybe FreeBSD would do well to rename their 'CURRENT' branch to something
suggesting less that to be with the times you need that one. I'm aware of the
difference between 'CURRENT' and 'STABLE' but I think that name is at a
minimum suggestive enough that people might (and probably have) fall for it.

Something like 'DEVELOPMENT' or 'NOTFORPROD' instead of 'CURRENT'?

~~~
gtirloni
As far as facts go, there is no indication that whoever is using -CURRENT in
production is doing so out of ignorance. I've only seen hearsay so far and I'm
guessing that number is very small and comprises actually knowledgeable people
that know the risks.

Additionally, it's stamped everywhere [1], if one cares to look, that CURRENT
is unsupported, bleeding edge, buggy, "will not build sometimes", etc. Do we
really want to modify a development process that has been in use for over a
decade because of a few clueless/extremely-gifted people?

Another possibility is that this person is a FreeBSD jedi, well aware of the
risks and payoffs. In that case, this bug is no surprise and she/he is
prepared to act on it and regenerate some keys, review commit logs (if a
developer), and look for signs of intrusion etc.

I still think this is a "non-news" and poor attempt to use HN to spread fear
and trigger useless discussions. The usual drama show.

[1]
[https://www.google.com.br/search?q=freebsd+current](https://www.google.com.br/search?q=freebsd+current)

------
citrin_ru
[https://svnweb.freebsd.org/changeset/base/278922](https://svnweb.freebsd.org/changeset/base/278922)

"This does not effect programs that directly used /dev/random or
/dev/urandom."

openssl should use /dev/random for key generation and keys generated by
openssl is not affected?

------
anologwintermut
Is one of /the main prng on FreeBSD actually arc4random? I.e. RC4?

~~~
tedunangst
Libc arc4random still uses rc4. The kernel code is actually kind of tangly. I
think it still uses rc4 for explicit arc4random calls, but I'm not certain
exactly what comes out of /dev/random.

~~~
ygra
/dev/random on FreeBSD uses Yarrow:
[http://en.wikipedia.org/wiki/Yarrow_algorithm](http://en.wikipedia.org/wiki/Yarrow_algorithm)

------
Animats
The big question: who made the change that introduced this major security
hole? This may be an attack, and one that's traceable.

Name?

~~~
tedunangst
Burn the witch! Burn the witch!

~~~
alfiedotwtf
You mean burn the possible government infiltrator. From now on, _all_ changes
at the crypto layer should have double plus eyes looking at every change (and
I don't mean the five-eyes).

------
tete
FYI: CURRENT means master/head/pre-alpha or what you would call it.

------
infruset
Would this affect Bitcoin private keys generated with this kernel?

~~~
ikeboy
It says it would affect openssl, which Bitcoin Core used up until the last
update. IDK about other wallets.

------
louwrentius
It's Debian knocking on the door, they want their RNG back!

------
aaronchall
Will the individual who broke it get the credit?

------
discardorama
... and Whatsapp uses FreeBSD extensively. Could this affect the end-to-end
encryption that Whatsapp uses?

~~~
tptacek
Does WhatsApp run on -CURRENT? That seems unlikely.

~~~
WestCoastJustin
There was a talk + slides about WhatsApp FreeBSD usage [1, 2].

At around 23:50 in the video, Rick Reed talks about slide #17, they say they
are running 9.1 - 9.3, and looking at 10.1 (not in a hurry as 9 works for
them).

[1]
[https://www.youtube.com/watch?v=TneLO5TdW_M](https://www.youtube.com/watch?v=TneLO5TdW_M)

[2] [http://www.slideshare.net/iXsystems/rick-
reed-600-m-unsuspec...](http://www.slideshare.net/iXsystems/rick-
reed-600-m-unsuspecting-freebsd-users)

~~~
barkingcat
-CURRENT is not a single version number - it refers to a development branch. If someone says CURRENT is version xx, then they don't really know what they are talking about - because while CURRENT may become a versioned release down the line, that is very different from what -CURRENT represents (which is a named tree in source control that people develop against)

All of those freebsd versions you refer to (9, 10) are part of the production
release cycles and thus are not -CURRENT.

If whatsapp uses 10.1, then they are NOT using -CURRENT

~~~
WestCoastJustin
Yeah, I think we are both thinking the same thing. I put the links, and
version numbers, in support of tptacek's thought that they were _not_ using
-CURRENT.

