linux-kernel - Re: [stable] Linux 2.6.25.10

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <487D5BD9.3080303@assumpcao.org>
Date:	Tue, 15 Jul 2008 23:24:25 -0300
From:	Tiago Assumpcao <tiago@...umpcao.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	pageexec@...email.hu, Greg KH <greg@...ah.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, stable@...nel.org
Subject: Re: [stable] Linux 2.6.25.10

Linus Torvalds wrote:
> 
> Well, some people keep it secret and track it on vendor-sec or similar, 
> hidden from us.
> 
> But then when they are ready to announce it, they want our help to glorify 
> their corrupt process when they finally deign to let us know. And that 
> really irritates me.
> 

Again, not asking for what you can not provide. You must, however, do 
your part.

> The people who want to track security issues don't run my development 
> kernels. They usually don't even run the _stable_ kernels. They tend to 
> run the kernels from some commercial distribution, and usually one that is 
> more than six months old as far as I - and other kernel developers - are 
> concerned.

Right *there* is where it is born! Right at your development kernels. It 
may or may not survive up to the big market. However, being at the 
source level, it is your duty to a) resolve the source-level issues; b) 
put affordable efforts in order to prevent one known issue to arrive at 
the end point.

> 
> IOW, when we fix security issues, it's simply not even appropriate or 
> relevant to you. More importantly, when we fix them, your vendor probably 
> won't have the fix for at least another week or two in most cases anyway.
> 

There is obviously room for suffering from this delay. It's really 
small, however, if you understand that this is not enough time for 
widely spread exploits to be in the hands of every corner kid. Not.

Thus, consider the following: how many computers are likely to suffer 
from one bug that has been advised (marked as "security related" in your 
bugzilla), and, one week later, fixed? Now, how many computers are 
likely to suffer from one bug that has been advised and fixed 8 weeks 
later? A lot more, I presume.

Ok. Now, imagine this scenario: one bug that has never been identified 
as "security relevant" is assigned and/or fixed by your people. 
Remember, your list is open to public. Do you have a clue of how many 
individuals keep watching every bug/fix, with a "security antenna" 
turned on, expecting for the right bug to show up and... not receive the 
attention it needs so they can do whatever they want, for the amount of 
time they please? Several.

Now, tell me, how many computers are likely to suffer from the last 
scenario; the one that you cultivate?

> So ask yourself - what would happen if I actually made a big deal out of 
> every bug we find that could possibly be a security issue. HONESTLY now!
> 

Just mark it. No big deal.

> 
> I would not actually be helping you. I'd be helping the people you want to 
> protect against!
> 
> 			Linus
> 

Those who can see, and quickly exploit it, do not need your mark. They 
will figure it out right after it was assigned and an exploit will exist 
in the wild not after you fix the bug. So, let's work for the smallest 
pain. Right?

--t
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/