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 for Android: free password hash cracker in your pocket

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

Date: Wed, 16 Jul 2008 17:30:21 -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:

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

What's ridiculous about the concept?  There *do* exist machines that don't
have any untrusted local users - for instance, my laptop.  The only users
on it are me, myself, and I.  My threat model explicitly does *not* include
"One of the other users on the box downloads a vuln and attacks you with it".

Yes, there's *still* an attack surface for me to get whacked by that bug.
However, it's a *much* longer chain for "find a way to get code running on
the box, and then make it do the exploit" than the alternative "the Other User
downloads it and whacks the box".

Yes, there *is* still an exposure to "I get bit in the ass by something that
abuses my web browser or my MUA".  However, that's a *different* issue, as
at that point, they have code running as me - and protecting *my* stuff
from code running *as me* is a different kettle of fish entirely.

At that point, I have other and probably bigger things to worry about than if
my box gets whacked with the bug in 2.6.25.11.  For instance, I worry more
about having a keystroke logger running as me than I do about malicious code
managing to abuse the ldt bug to implement setuid(), simply because the
keystroke logger would be a bigger pain in the ass to clean up after....

Similar reasoning applies to almost all uses of Linux in the embedded
world - if you already have code running on the cell phone, there really
isn't *anything* you can do by abusing something like the setldt() bug
that you couldn't *already* do to the box.

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/