full-disclosure - "Advances in Security" in the Linux Kernel and RedHat idiocy

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: <20050127182144.GC19285@grsecurity.net>
From: spender at grsecurity.net (Brad Spengler)
Subject: "Advances in Security" in the Linux Kernel and
	RedHat idiocy

> I think the joke is on you in this case. There is a large patch series of
> which you judge the first steps only. Those steps introduce the
> infrastructure and concepts into the kernel, and later patches will tweak
> the exact numbers to values with more entropy. ONCE THEY EXISTING
> INFRASTRUCTURE IS ACCEPTED AND DEBUGGED.
> 
> Maybe you don't understand that, I assume a lot of the other readers of this
> list do. You don't plop a huge patch in the linux kernel in one chunk. You
> do it in nice small, incremental and debuggable steps.

If Exec-shield is any model for what you plan to turn this into, my 
comments still apply.  If you like, I'll simply send out the same email 
months from now when you "finalize" this patch into the level of 
security you claim it to be able to provide (which will never happen, 
since you won't be providing any bruteforce deterrence, so it doesn't 
matter if you increase the randomization by a couple more bits).

I should also add that the stack randomization present in this patch and 
that in exec-shield can be bypassed by tossing enough data into the 
stack, like "/bin/sh" over and over, since the amount of randomization 
is smaller than the stack itself.  I should also note that the latest 
output of paxtest I could find against exec-shield shows that the amount 
of randomization for shared libraries is the same as in the patch you 
sent to LKML.  So if your argument is that you agree these values are 
stupidly low, you're not saying much about your own "enterprise-grade" 
software ;)

I would also like to correct a mistake in my previous mail.  The glibc 
issues are indeed fixed in the latest FC3 glibc, which was released on 
December 27th, 2004, nearly 3 1/2 months  after the bug was initially 
reported.  The glibc update was not released as a security update 
however, so many users are still affected (like the two Fedora 
developers I contacted).

-Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050127/1e0dab26/attachment.bin