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]
Date: Wed, 16 Jul 2008 15:26:09 -0400
From: "Robert Peaslee" <peasleer@...il.com>
To: "Brad Spengler" <spender@...ecurity.net>
Cc: full-disclosure@...ts.grok.org.uk, dailydave@...ts.immunitysec.com
Subject: Re: Linux's unofficial security-through-coverup
	policy

Hi Brad,

Your comments are kind of misguided. Linus can be quoted as saying: "my
responsibility is to do a good job. And not pander to the people who want to
turn security into a media circus." He was referring to individuals such as
yourself when making the circus comment, as your message was slightly
alarmist and dramatized.

Security is important, of course - but Linus'
opinions<http://kerneltrap.org/mailarchive/linux-kernel/2008/7/15/2497674>are
completely correct in terms of development of the Linux kernel. I
would
agree with you if security bugs were actually being hidden, but they aren't.
They just aren't given special treatment.

--Robert Peaslee
www.robertpeaslee.com

On Wed, Jul 16, 2008 at 9:44 AM, Brad Spengler <spender@...ecurity.net>
wrote:

> Hi all,
>
> I doubt many of you are following the "discussions" (if they can be
> called that) that have been going on on LWN for the past couple weeks
> regarding security fixes being intentionally covered up by the Linux
> kernel developers and -stable maintainers.  Here are some references:
>
> http://lwn.net/Articles/285438/
> http://lwn.net/Articles/286263/
> http://lwn.net/Articles/287339/
> http://lwn.net/Articles/288473/
> http://lwn.net/Articles/289805/
>
> The Linux kernel has a formal policy in Documentation/SecurityBugs which
> states under Section 2 Disclosure:
> "We prefer to fully disclose the bug as soon as possible."
>
> However, their policy in reality is quite different, as you can see for
> yourself in the "discussion" going on now on LKML:
>
> http://marc.info/?t=121507404600023&r=1&w=2
>
> Some choice quotes from Linus that reflect how sad the current state is:
> http://marc.info/?l=linux-kernel&m=121617056910384&w=2
> (on commenting about what he would allow to be included in a commit
> message)
> "I literally draw the line at anything that is simply greppable for. If
> it's not a very public security issue already, I don't want a simple
> "git log + grep" to help find it."
>
> http://marc.info/?l=linux-kernel&m=121613851521898&w=2
> (when talking about the security backports Linux vendors provide for
> customers)
> "And they mostly do a crap job at it, only focusing on a small
> percentage (the ones that were considered to be "big issues")"
>
> They seem to have the impression that people who find an exploit kernel
> vulnerabilities rely on the commit messages fixing the vulnerability
> including some mention of security.  As it should be clear to anyone
> actually involved in the security community, or anyone who has ever
> written an exploit (particularly for the myriad silently fixed
> vulnerabilities in Linux), this is far from reality.  The people who
> *do* rely on these messages and announcements however are the smaller
> distributions and individual users.  Yet Linus et al believe they're
> helping you by pulling the wool over your eyes regarding the exploitable
> vulnerabilities in their OS.
>
> 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 since the time of the fix itself (or even before that if
> someone spotted it before the kernel developers did themselves) users
> have been at risk.  Yet in the imaginary world they live in, these
> kernel developers think they're protecting you from that risk by not
> telling you what you're vulnerable to.
>
> Please let them know what you think of their policy of non-disclosure
> and coverups.  I hope someone also educates them on their ridiculous
> notion of "untrusted local users" like Greg uses in his announcement of
> the 2.6.25.11 kernel:
> http://lwn.net/Articles/289804/
>
> If you remain complacent about the state of affairs, you're only
> enabling them to continue their current misguided foolishness.
>
> -Brad
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIfftEmHm2SUJF1GoRAktWAJ9DAPKD+xOzxwhgG+3jaIEQhZaGLwCfWB1z
> JcW3+i5FirNKEz0JcAEu84o=
> =FE0K
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Content of type "text/html" 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ