full-disclosure - Re: Linux's unofficial security-through-coverup policy

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: <29111.1216238817@turing-police.cc.vt.edu>
Date: Wed, 16 Jul 2008 16:06:57 -0400
From: Valdis.Kletnieks@...edu
To: spender@...ecurity.net (Brad Spengler)
Cc: full-disclosure@...ts.grok.org.uk, dailydave@...ts.immunitysec.com
Subject: Re: Linux's unofficial security-through-coverup
	policy

On Wed, 16 Jul 2008 09:44:37 EDT, Brad Spengler said:

> To illustrate the point, in the 2.6.25.10 kernel, the following fix was
> included with the commit message of:
> Roland McGrath (1):
>       x86_64 ptrace: fix sys32_ptrace task_struct leak
> 
> The kernel was released with no mention of security vulnerabilities in
> the announcement, only "assorted bugfixes".
> 
> Put simply, it only took about an hour or so to develop a PoC for this
> exploitable vulnerability which affects 64bit x86_64 kernels since
> January. 

So tell me Brad - if Roland fixed a bug, *and didn't even realize it was
a security-exploitable* issue, how do you propose we proceed?  Do you suggest
that we stop and look at *every single commit* that fixes a bug, and see if
there's some corner case that makes it exploitable?  (Hint - I suggest you
go look at the number of git commits done during the average -rc1 kernel
lately, and figure out where the manpower will come from).

Or go trawling through the linux-kernel archives, and see how many times I've
reported an Oops or panic or hang (the answer is "so many I've lost count").
Yes, I probably should have (in your world) gotten some big splashy "security
advisory" out.

But you know what?  *IT* *DOESN'T* *ACTUALLY* *MATTER* *IN* *THE* *REAL* *WORLD*.
Just yesterday, I was talking on IRC to a rather clued individual, who was
still running 2.6.18 or so - because he had mission-critical custom patches
that hadn't been migrated to 2.6.25 yet.

And that's the *clued* user.  The *average* user, even a non-Windows one,
wouldn't know how to correctly deal with a security advisory unless it bit
them on the ass.  Literally.  The vast majority of them simply install updates
when they show up from their distro.  They don't know how to build their own
kernel, they can't analyze the threat model coherently, so it basically
changes into "I'll install it when it shows up in the GUI window of my distro's
patch manager".

The percentage of users that a more detailed bug announcement would actually
help is probably on the order of 0.05% or so.  The *other* 99.95% of them,
it's "A new update is available. Install? ( ) Yes   ( ) No".

OK, so we do Linux bugfix announcements the way *you* recommend.

Now suggest something *workable* for the *other* 99.95% that will *still*
be vulnerable.

Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/