[Full-Disclosure] "Advances in Security" in the Linux Kernel and RedHat idiocy

• Previous message: muts_at_zahav.net.il: "[Full-Disclosure] Remotely exploitable file traversal vulnerability in SnugServer 3.0.0.40 FTP Service"
• Next in thread: Arjan van de Ven: "Re: [Full-Disclosure] "Advances in Security" in the Linux Kernel and RedHat idiocy"
• Reply: Arjan van de Ven: "Re: [Full-Disclosure] "Advances in Security" in the Linux Kernel and RedHat idiocy"
• Reply: Michal Zalewski: "Re: [Full-Disclosure] "Advances in Security" in the Linux Kernel and RedHat idiocy"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Thu, 27 Jan 2005 11:10:43 -0500
To: dailydave@lists.immunitysec.com

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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

• application/pgp-signature attachment: Digital signature

• Previous message: muts_at_zahav.net.il: "[Full-Disclosure] Remotely exploitable file traversal vulnerability in SnugServer 3.0.0.40 FTP Service"
• Next in thread: Arjan van de Ven: "Re: [Full-Disclosure] "Advances in Security" in the Linux Kernel and RedHat idiocy"
• Reply: Arjan van de Ven: "Re: [Full-Disclosure] "Advances in Security" in the Linux Kernel and RedHat idiocy"
• Reply: Michal Zalewski: "Re: [Full-Disclosure] "Advances in Security" in the Linux Kernel and RedHat idiocy"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]