Atomicorp

I get this in my asl

High Risk: Kernel Main executable randomisation (ET_EXEC) test failed.

Even when I command asl fix this remains. Why ?

So the short answer: this is a weakness in your hardware. Some CPUs can not do this - its not an ASL thing - ASL is telling you your hardware does not support this capability.

Long answer: all Linux, Windows, BSD, MacOS, etc. boxes are vulnerable to these types of stack attacks. ASL includes stack protection countermeasures not available in regular Linux kernels (like with Fedora, Ubuntu, and others). And unlike those other folks, we test your hardware to see if its up to the task too. The good news is that this particular vector is not a direct vector - the ASL countermeasure is proactively proactive if you will. ASL is trying to make a certain class of attacks even less likely to work on an ASL system. So, if you get this one red you need not sweat over it - we added in the stack checks because not all CPUs can present the capabilities needed for us to defend against all stack based attacks and for some customers perfection is a requirement - and they need to know if their hardware is up to the task.

Stack protection is a PROACTIVE counter measure to protect your box from a class of attacks that take advantage of the behavior of CISC CPUs like Intels, AMDs, etc. So if your CPU is not able to support all the protection capabilities in ASL you have some exposure, but you have immensely greater exposure if you don't run ASL (plus you wouldnt know you had this weakness in your CPU). A standard Linux kernels stack protection is nearly non-existent for example.

We are always working on ways to squeeze more blood out of the rock, if you will, and are looking at ways to emulate these protections for CPUs that can not support it - but we have to do it in a way that doesnt kill your box. So unfortunately for some CPUs you will not be able to get all green with stack protection - and with ASL you will always get the most stack protection possible on Linux. On a normal Linux kernel you get almost none of the stack protection features of ASL. A normal Linux kernels stack protection is tiny subnet of what ASL can do.

I hope this answers your questions.

Wow thx Mike, I have this "error" 2 one some servers, now I know why

We're *paranoid* with the scanner, so when we find anything - we want you to know.

mikeshinn wrote:We're *paranoid* with the scanner, so when we find anything - we want you to know.

Thats why we choose ASL and thats why we love you ! hehe

Ok. So now I have some stack protection or not at all ? I presume some ...

And a question not relevant to this topic ... But relevant with the ASL kernel.
If there is from your side a new kernel. It will be downloaded and compiled when asl -u runs ? And when this happens... Will there be some kind of notification in order to reboot the system and boot with the new ASL kernel ?

Thats something that just came around in yum as of Fedora 10, it supports a messaging layer that lets you tell a user "this update requires the application to restart" (firefox for example). There are already messages in there to notify the user than a new kernel will require a reboot. I dont know if or when that will end up on centos 4 or 5, but it is available in fedora 10 now. I would expect to see that in CentOS/RHEL 6 when it comes out.

A nice function to come for sure.

But if there is an automated as I assume kernel update before this becomes available... How will I know in order to reboot the server ?

I'll see what we can come up with for an automated solution, its definitely a good idea to come up with a notification system. Especially since in the past we've managed to build compensating security controls into the kernel for vulnerabilities in other applications in the past. We've got a mailing list, if you havent signed up for that already. We will absolutely post to that in the future whenever we have an update available.

Ok. So now I have some stack protection or not at all ? I presume some ...

You have a LOT of stack protection, more than anything you get a regular Linux kernel (like in Fedora, Centos, Redhat, Ubuntu, etc.).

Run the ASL scanner on a non-ASL box and you'll see what I mean. Heres an ASL box:

Linux server 2.6.27.7-9.art.i686 #1 SMP Fri Dec 19 11:05:35 EST 2008 i686 i686 i386 GNU/Linux

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Executable stack (mprotect) : Killed
Anonymous mapping randomisation test : 17 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 23 bits (guessed)
Main executable randomisation (ET_EXEC) : 23 bits (guessed)
Main executable randomisation (ET_DYN) : 15 bits (guessed)
Shared library randomisation test : 17 bits (guessed)
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)
Stack randomisation test (PAGEEXEC) : 23 bits (guessed)
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Killed

Zero vulnerabilities on the ASL box.

Now heres a non ASL box with both exec-shield running and SELinux in enforce mode (Fedora in this case):

Mode: blackhat
Linux box1 2.6.27.21-78.2.41.fc9.i686 #1 SMP Mon Mar 23 23:45:58 EDT 2009 i686 i686 i386 GNU/Linux

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Executable stack (mprotect) : Vulnerable
Anonymous mapping randomisation test : 16 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 14 bits (guessed)
Main executable randomisation (ET_EXEC) : 5 bits (guessed)
Main executable randomisation (ET_DYN) : 12 bits (guessed)
Shared library randomisation test : No randomisation
Stack randomisation test (SEGMEXEC) : 19 bits (guessed)
Stack randomisation test (PAGEEXEC) : 19 bits (guessed)
Executable shared library bss : Vulnerable
Executable shared library data : Killed
Writable text segments : Vulnerable

Several vulnerabilities in the stack on a non-ASL box.

nobody wrote:If there is from your side a new kernel. It will be downloaded and compiled when asl -u runs ?

No, asl -u doesn't install new kernels. You need to run 'yum update' for that. Yum will download and install a precompiled kernel.

breun wrote:

nobody wrote:If there is from your side a new kernel. It will be downloaded and compiled when asl -u runs ?

No, asl -u doesn't install new kernels. You need to run 'yum update' for that. Yum will download and install a precompiled kernel.

Then I'll see the update. I am running both asl and yum update commands on crontab.