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-next>] [day] [month] [year] [list]

From: spender at grsecurity.net (Brad Spengler)
Subject: "Advances in Security" in the Linux Kernel and
	RedHat idiocy

Just wanted to point out to you guys the INCREDIBLE advances in Linux 
security underway on LKML from security expert Arjan van de Ven:

http://lkml.org/lkml/2005/1/27/62

On the subject of his i386-only mmap randomization patch:

The randomisation range is 1 megabyte (this is bigger than the stack
randomisation since the stack randomisation only needs 16 bytes alignment
while the mmap needs page alignment, a 64kb range would not have given
enough entropy to be effective)

If we do a little math..
1048576 / 4096 = 256
65536 / 16 = 4096

256 different locations for the mmap base, 4096 different locations for 
the stack (and apparently argv/envp pages get no randomization)

Anyone with half a brain would see this is a joke, but not security 
expert Arjan van de Ven:

http://lkml.org/lkml/2005/1/27/56

"full randomisation makes it not possible to use absolute addresses in 
the exploit."

I guess anyone who thinks that taking a hardcoded exploit and running it 
256 times would always result in a successful exploit is stupid.

In true non-hackery fashion, it has a sysctl entry that will disable 
randomization entirely if for instance a single developer on the system 
needs to debug a single application:

http://lkml.org/lkml/2005/1/27/57

But then someone complained that it should be more fine-grained, so now 
if PT_GNU_STACK is disabled on the app, randomization will be turned off 
as well.  I guess that's RedHat's definition of it.

And remember kids, if you're owning Fedora or RHEL, you can bypass all 
this "randomization" (the junk in Exec-shield isn't any better) for suid 
apps by abusing a vuln in RedHat's glibc that leaks randomization info 
by using LD_DEBUG=files or LD_DEBUG=all or LD_TRACE_PRELINKING
BTW, this remains unfixed since *AUGUST* of last year.  Bugzilla reports 
were filed, even an LWN article was posted about the problem:

http://lwn.net/Articles/99137/

3 months later, on December 7th, Jakub committed a "fix" to glibc that I 
guess he never tested.  The only change made was to add LD_DEBUG to 
unsecvars.h.  If he had bothered to listen to other people, or looked at 
the fixes from other distros, he would have seen his "fix" wasn't 
enough.

Yet now he's rejecting any bug reports on the subject, claiming he has 
fixed the problem:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146207

Yet I've just verified from two separate users of Fedora Core 3 that the 
problem is indeed *NOT* fixed, verifying my analysis of elf/rtld.c that 
it was not fixed.

Tilting the scale of security hype back to reality,
-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/0feedda8/attachment.bin