View previous topic :: View next topic |
Author |
Message |
I.C.Wiener Tux's lil' helper
Joined: 25 Jul 2004 Posts: 115 Location: Furtwangen (Germany)
|
Posted: Thu Feb 23, 2006 7:11 pm Post subject: How do I make use of the dx-bit (Disable Execution Bit)? |
|
|
I just figured out that my new Pentium-M comes with the dx-bit (AMD calls it nx-bit for the Athlon64) wich should prevent the execution of arbitrary code in the event of a buffer-overflow. This has recently proven to be very useful to the windows folks (at least to those who upgraded WinXP to sp2). The faulty application will crash but no malicious code beeing executed - sounds good, eh?
As far as I know Gentoo-hardened can emulate this behaviour in software even on systems that are not equipped with the dx/nx-bit. So I guess it will use the hardware-bit on systems that have it. However gentoo-hardened goes much to far for my purposes. I don't need selinux/gr-security, memory randomizations and all that stuff, I just want this execution protection which should come at no or very little performance cost.
So what do I need to make use of the dx-bit?
- Do I have to switch to the hardened-profile or set the "hardened" use-flag?
- Do I need the hardened-sources (or another kernel that comes with pax-support)?
- What gcc-profile should I use (there are quite a few, check out "gcc-config -l")?
- Are there any special CFlags I need to set in /etc/make.conf?
- Perhaps it already works, how can I test it?
I had been looking for answers to these questions quite some time and asked a lot of people but only got even more confused. I hope there's anyone out there who can clear things up. |
|
Back to top |
|
|
kottlettstanze Tux's lil' helper
Joined: 20 Apr 2004 Posts: 113
|
Posted: Sat Nov 04, 2006 12:41 pm Post subject: |
|
|
Correct me if I'm wrong - but it looks like you need to enable support for 64GB ram in the kernel config and recompile it - that's all. |
|
Back to top |
|
|
kill Apprentice
Joined: 25 Dec 2004 Posts: 179
|
Posted: Sat Nov 04, 2006 7:54 pm Post subject: |
|
|
kottlettstanze wrote: | Correct me if I'm wrong |
Your correction.
You do not need to enable anything in the kernel or use any specific profile or set any special use flag. If it's available it will automatically be used in any kernel 2.6.8 or newer.
To test emerge paxtest and run:
Look for
paxtest wrote: | Executable stack : Killed
|
If you see that, then it's enabled and working. |
|
Back to top |
|
|
kottlettstanze Tux's lil' helper
Joined: 20 Apr 2004 Posts: 113
|
Posted: Sat Nov 04, 2006 9:17 pm Post subject: |
|
|
kill wrote: |
Your correction.
|
Appreciated.
paxtest wrote: | Executable stack : Vulnerable
|
Hm... I don't like that too much I'll try it tomorrow, with 64GB enabled.
Cheers! |
|
Back to top |
|
|
zxy Veteran
Joined: 06 Jan 2006 Posts: 1160 Location: in bed in front of the computer
|
Posted: Sun Nov 05, 2006 3:22 am Post subject: |
|
|
My situation
Code: | # cat /proc/cpuinfo
...
model name : AMD Athlon(tm) 64 Processor 3700+
...
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall [b]nx[/b] mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm
|
Code: | # paxtest blackhat
...
Executable stack : Killed
...
Executable stack (mprotect) : Vulnerable
...
|
What does each of the stack tests mean? _________________ Nature does not hurry, yet everything is accomplished.
Lao Tzu |
|
Back to top |
|
|
kottlettstanze Tux's lil' helper
Joined: 20 Apr 2004 Posts: 113
|
Posted: Sun Nov 05, 2006 10:20 am Post subject: |
|
|
zxy, do you have the highmem 64G flag enabled?
However, if I enable it, the kernel doesn't boot :-/ I just get an endless message stream about unknown interrupt / EIP or something like that - followed by a reboot. |
|
Back to top |
|
|
kill Apprentice
Joined: 25 Dec 2004 Posts: 179
|
Posted: Sun Nov 05, 2006 5:47 pm Post subject: |
|
|
kottlettstanze wrote: | zxy, do you have the highmem 64G flag enabled? |
That option won't make a difference. The nx flag in his cpuinfo is why it's working for him.
zxy wrote: | What does each of the stack tests mean? |
The first one means that the nx bit is working.
The second means you are not using PAX. mprotect allows for access to memory to be changed (read, write, execute permissions). You will show as vulnerable to the mprotect portion unless you use the hardened kernel and enable NOEXEC in PAX.
What is happening with NX and mprotect is that mprotect allows for the stack to be remapped as executable. This is an issue with how Linux implements mprotect. The only way to prevent this is to use PAX. PAX can restrict mprotect and prevent memory from being marked as executable and writable at the same time. Otherwise memory marked as non executable by the NX bit can be remapped as executable by mprotect. |
|
Back to top |
|
|
Sachankara l33t
Joined: 11 Jun 2004 Posts: 696 Location: Stockholm, Sweden
|
Posted: Sun Nov 05, 2006 6:24 pm Post subject: |
|
|
Enable 64 GiB support and add this to the grub boot arguments: noexec=on noexec32=on
P.S. This will not work if you're using a hardened kernel, as grsecurity/pax already overrides the kernel's own NX functionality. _________________ Gentoo Hardened Linux 2.6.21 + svorak (Swedish dvorak) |
|
Back to top |
|
|
kill Apprentice
Joined: 25 Dec 2004 Posts: 179
|
Posted: Sun Nov 05, 2006 7:07 pm Post subject: |
|
|
Sachankara wrote: | Enable 64 GiB support and add this to the grub boot arguments: noexec=on noexec32=on |
That is not needed. It will be enabled automatically if avaliable. I can verify the grub options aren't needed on my system. As for 64 GiB support nothing on the LKML says it's needed. The announcement for the original patch says it will be used if available.
Sachankara wrote: | P.S. This will not work if you're using a hardened kernel, as grsecurity/pax already overrides the kernel's own NX functionality. | Partly true. If you're using x86_64 PAX will use the hardware NX bit the same as a non PAX kernel. Only on x86 systems does it override the internal method and also not use the hardware implementation. Instead it will use either PAGEEXEC or SEGMEXEC. |
|
Back to top |
|
|
kottlettstanze Tux's lil' helper
Joined: 20 Apr 2004 Posts: 113
|
Posted: Sun Nov 05, 2006 7:13 pm Post subject: |
|
|
Sachankara wrote: | Enable 64 GiB support and add this to the grub boot arguments: noexec=on noexec32=on |
Hm... enabling 64GiB leads to the error described above :-/ The noexecs in the kernel line didn't change anything in that.
Also, I'm getting different troubles: The kernel suddenly stopped loading the uhci_hcd module automatically. If I modprobe it, I get heaps of messages like
Code: | uhci_hcd 0000:00:1d.1: dma_pool_free uhci_qh, eec2e1c0/eec29000 (bad dma) |
... until I remove the module again. |
|
Back to top |
|
|
|