CVE-2014-7284: Lack of randomness in Linux kernel network secrets | Hacker News Reader

CVE-2014-7284: Lack of randomness in Linux kernel network secrets

secondlookforensics.com

99 pointsmukyu19 comments

> 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...

[2] http://meetings-archive.debian.net/pub/debian-meetings/2014/...

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

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

I feel you. Let's talk about our feels. Language butchers.

It has been fixed a while ago.

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

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.

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.

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.

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.

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.

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

Spoofed TCP disconnections can be annoying too.

Denial of service is a legitimate "security" concern in most contexts. No, this isn't shellshock, but it's worth fixing.

Many, many, many systems (like CDNs, or high-profile financial firms) depend mostly on IP whitelisting for their public-facing origin security. Whenever there's "partners" or "3rd parties" that need access to some service but they want to generally keep people from the internet off it, they just get lazy and IP whitelist instead of creating a VPN like they should. There's probably tens of thousands of organizations with setups like this.

Depending on the required level of security, that is probably fine. Protecting the origin server of a CDN via IP whitelisting is fine, if the content is publicly available via the CDN anyways and you treat that as a "we don't want everyone to use the origin, please use the CDN"-level of security. Using whitelisting to really keep people off the origin, however is probably not.

For something like CloudFlare which in itself is designed to be a security filter as well as a CDN, having people able to touch the origin server (if they can find it) would be highly undesirable.

Kevin Mitnick is rather famous for this type of attack [1]. These are dangerous attacks and we do depend on this working correctly. Phrack also has some interesting reading about spoofing attacks [2, 3].

[1] http://wiki.cas.mcmaster.ca/index.php/The_Mitnick_attack

[2] http://phrack.org/issues/48/14.html

[3] http://phrack.org/issues/53/6.html

Random TCP ISN is about all the security that the cheap CAs require before signing a certificate.

Reply on news.ycombinator.com