
CVE-2014-7284: Lack of randomness in Linux kernel network secrets - mukyu
http://secondlookforensics.com/ngro-linux-kernel-bug/
======
WestCoastJustin
> _The commit was made in May 2014. It was applied to the Ubuntu trusty kernel
> tree in June 2014. There was no mention of the security implications of the
> bug in the commit message, or elsewhere, so far as we can tell._

Linus did mention his policy on this [1].

    
    
      On Tue, 15 Jul 2008, pageexec <at> freemail.hu wrote:
      > 
      > by 'cover up' i meant that even when you know better, you quite
      > consciously do *not* report the security impact of said bugs
    
      Yes. Because the only place I consider appropriate is the kernel 
      changelogs, and since those get published with the sources, there is no 
      way I can convince myself that it's a good idea to say "Hey script 
      kiddies, try this" unless it's already very public indeed.
    

He also talked about this recently at debconf14 [2].

[1]
[http://thread.gmane.org/gmane.linux.kernel/701694/focus=7069...](http://thread.gmane.org/gmane.linux.kernel/701694/focus=706947)

[2] [http://meetings-archive.debian.net/pub/debian-
meetings/2014/...](http://meetings-archive.debian.net/pub/debian-
meetings/2014/debconf14/webm/QA_with_Linus_Torvalds.webm)

~~~
dandelany
For those watching the video and looking for his discussion of this - it's
near the end, around 1:05:30

------
sauere
That feel when you open up HN and the top post is about some new CVE. Being a
sysadmin isn't fun these days.

~~~
forgottenpass
If you're a sysadmin, you should be more responsible over your infrastructure
than to first hear about CVEs on Hacker News.

~~~
spindritf
Important CVEs, updates, and announcements hit HN minutes after they drop on
the relevant mailing list. Unless you're an insider, it's really hard to
outrun HN.

------
Animats
Look at that code change. An incredibly obscure feature of GCC was used to
save two machine instruction times in security-critical code. That was either
stupid or a deliberate insertion of a security hole.

~~~
peterwwillis
While I normally appreciate paranoia and hyperbole, in this case I doubt it's
warranted. The commit was designed to use features specific to the kernel. It
had never been used this way before, and so of course the guy got bit by a
bug. It was even fixed 7 months later when it created a bug in the LTSP
project. I think if it was intentional it could have been done in a way that
wasn't so "suspicious", such as implementing something so new it needs an
explanation before hand-off.

~~~
tedunangst
Here's an idea: don't use a one off custom feature in a new untested way to
seed your random number generator. if "of course the guy got bit by a bug"
describes what you are doing, don't do it.

------
bartc
If your system security depends in any way on a randomly initialized TCP
sequence number, you're asking for trouble.

It seems it would be preferable to use predictable values so people don't get
the impression that random values are somehow more secure.

~~~
0x0
Spoofed TCP connections can be annoying even if they don't actually breach the
security of a system?

~~~
mnw21cam
Spoofed TCP _disconnections_ can be annoying too.

