> 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].
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.
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].
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.
Linus did mention his policy on this [1].
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/...