Re: non-executable stack (via PT_GNU_STACK) not being enforced
On mar., 2010-10-12 at 05:34 -0500, Jordon Bedwell wrote: Also to add, the benefits of NX on PAE far outweigh those of not having PAE, Like, not booting at all? -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Thu, 2010-10-14 at 20:09 +0200, Yves-Alexis Perez wrote: On mar., 2010-10-12 at 05:34 -0500, Jordon Bedwell wrote: Also to add, the benefits of NX on PAE far outweigh those of not having PAE, Like, not booting at all? Like, going and buying a better computer? I have no problem booting my mums computer with PAE and NX (and it's almost 5 years old now ~ built with heavily proprietary hardware from Dell) Don't blame the kernel for your hardware. You must also be a politician or news anchor on the side too. Taking things out of context and replying out of context. Always pro to do so, that way you can subjectively reply. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1287080107.14513.3.ca...@envygeeks
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On jeu., 2010-10-14 at 13:15 -0500, Jordon Bedwell wrote: Like, not booting at all? Like, going and buying a better computer? I'm not sure it's a solution Debian can advertise. I have no problem booting my mums computer with PAE and NX (and it's almost 5 years old now ~ built with heavily proprietary hardware from Dell) Don't blame the kernel for your hardware. That's not the point (and tbh, I don't run any i386 kernel anyway). But we do have users which will have issues, and we do have a -bigmem kernel which can be used for needing users. So yes I agree a way to propose the -bigmem to users needing it would be nice, but I don't think setting it the default kernel would work. But I basically see i386 as “the kernel of the last chance”. You must also be a politician or news anchor on the side too. Taking things out of context and replying out of context. Always pro to do so, that way you can subjectively reply. Was that really necessary? Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Thu, 2010-10-14 at 20:21 +0200, Yves-Alexis Perez wrote: I'm not sure it's a solution Debian can advertise. I know it's not, that is why later down the discussion we brought up the installer giving people the option to either choose the kernel or building a script that will check for PAE and go from there. That's not the point (and tbh, I don't run any i386 kernel anyway). But we do have users which will have issues, and we do have a -bigmem kernel which can be used for needing users. So yes I agree a way to propose the -bigmem to users needing it would be nice, but I don't think setting it the default kernel would work. But I basically see i386 as “the kernel of the last chance”. Read above. It was not meant to be a point, but a mere example. You can't stay legacy forever (well you /can/ but why would you want to?) and I think giving users the choice is the best step with a pro being NX that PAE can bring if the CPU supports it. Was that really necessary? Yes, because out of context replies are out of context. While it should have not so blunt (which I am really working on ~ you should have seen the way I would have replied a year ago) it had to be brought up :P -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1287081333.14513.16.ca...@envygeeks
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On jeu., 2010-10-14 at 13:35 -0500, Jordon Bedwell wrote: On Thu, 2010-10-14 at 20:21 +0200, Yves-Alexis Perez wrote: I'm not sure it's a solution Debian can advertise. I know it's not, that is why later down the discussion we brought up the installer giving people the option to either choose the kernel or building a script that will check for PAE and go from there. That's not the point (and tbh, I don't run any i386 kernel anyway). But we do have users which will have issues, and we do have a -bigmem kernel which can be used for needing users. So yes I agree a way to propose the -bigmem to users needing it would be nice, but I don't think setting it the default kernel would work. But I basically see i386 as “the kernel of the last chance”. Read above. It was not meant to be a point, but a mere example. You can't stay legacy forever (well you /can/ but why would you want to?) Well, in this case, to support our users, which still use non pae cpu. And for non legacy users, I'd advertise using amd64 anyway. Not exactly sure how much cpus don't support x86_64 while still supporting PAE/NX, and if it's really worth it. But yeah, if you want to provide a patch to the installer for Wheezy go ahead. Was that really necessary? Yes, because out of context replies are out of context. While it should have not so blunt (which I am really working on ~ you should have seen the way I would have replied a year ago) it had to be brought up :P It was a rhetorical question. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: non-executable stack (via PT_GNU_STACK) not being enforced
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/14/2010 02:15 PM, Jordon Bedwell wrote: Like, going and buying a better computer? I have no problem booting my mums computer with PAE and NX (and it's almost 5 years old now ~ built with heavily proprietary hardware from Dell) Don't blame the kernel for your hardware. There is not only issues of legacy hardware but virtual machines. I signed up for the RHEL 6 beta. Downloaded my copy and fired it up in virtualbox, only to find that it failed to boot, because virtualbox did not support PAE. I am not sure if other virtualization solutions would also have issues with this. However, virtualbox is likely more popular in a desktop environment where you are more likely to have an i386 host. You must also be a politician or news anchor on the side too. Taking things out of context and replying out of context. Always pro to do so, that way you can subjectively reply. That may have been somewhat out of context, but from my experience on #debian IRC, many uses do still run on hardware. I saw two different people this week wanting to install debian via floppy for example. Regards, - -- Jordan Metzmeier -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJMt3h9AAoJEKj/C3qNthmTdG4P/2OyBapahTYEKKYU4DoJAxlN AhlBRL/J+YImKk7xyRw97YA9SJ4/yMo3JX5yIBpumaPa8hNBBwFVLz6B8LZTCs0E K7rZTEPphsJY2CTzOKkH9W/qIfBQZAohGL/biE+AQucoKTw5/lLbBpB+A0Bi5hse Ppc0/hVlIepwc1q+tpKrmZy9rjXSlJr1PHAXzg6QyHb/7NbrUL+KCAPYC+4vgHE8 IoGfiz48QjWnMwEzgPb2AFlaUl5ghovNTuQZijA1CuqNco7EwbRJyLimYXjGx+xA ujTmrdLLc3cpxCdnr7OVj9jOUQ+qF3vRKyNgIBoxX4qh8xgHqMmwSbQiTkHBpB+L IXYvg4/nxINHnoYAsewGR3pBrHVH8Ftn2VNE+pdXOVYnNiJVBcaXKmwa24Jb7NSV ACe5MQ5HEdVJo3qIv4ogiVrooVPYrt6lJVTa4A2ehDsKvd8nL+Lge5J9pRCjyitC cN8OnWV8xm2kQ2bntXh7dzZDCysTZW3PyRQTw0g6Ro1J2am5fuluNSWw6TLTLVJD gu7AyzfDPFmvu4az1q7QDEcudM4rskPESHKg5bOtEFmWeyOres0DD4E5YQFYTgyx qbTa9sZResA8QqEHsPy9zTTyu/GzNBzd+TzaaVh7pDg0D01yjBOrtw8BVu+rSG7e Wes88lx4BLDFdoe3VFoi =fC4+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cb77886.4010...@gmail.com
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Thu, 2010-10-14 at 17:39 -0400, Jordan Metzmeier wrote: There is not only issues of legacy hardware but virtual machines. I signed up for the RHEL 6 beta. Downloaded my copy and fired it up in virtualbox, only to find that it failed to boot, because virtualbox did not support PAE. According to Virtualbox Devteam: Virtualbox does support PAE/NX. I don't know where it is, but I found an old ticket from 2007 that is marked as 'fixed' and somebody in said ticket mentioned advanced tab. I personally use VMWare and Xen but hope that helps :P -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1287092397.2322.2.ca...@envygeeks
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Thu, 14 Oct 2010 16:39:57 -0500, Jordon Bedwell wrote: On Thu, 2010-10-14 at 17:39 -0400, Jordan Metzmeier wrote: There is not only issues of legacy hardware but virtual machines. I signed up for the RHEL 6 beta. Downloaded my copy and fired it up in virtualbox, only to find that it failed to boot, because virtualbox did not support PAE. According to Virtualbox Devteam: Virtualbox does support PAE/NX. I don't know where it is, but I found an old ticket from 2007 that is marked as 'fixed' and somebody in said ticket mentioned advanced tab. Yes, there is a non-default enable PAE/NX option under settings for the VM in the virtualbox GUI. This is rather off-topic at this point. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101014180524.565a58a3.michael.s.gilb...@gmail.com
Re: non-executable stack (via PT_GNU_STACK) not being enforced
Brchk05 brch...@aim.com writes: I am running Debian 2.6.26-21lenny4 and I am puzzled by an issue with the enforcement of page permissions. I have written a simple program with a basic buffer overflow and compiled two versions using gcc: one with -z execstack and another with -z noexecstack. So, to verify that the option takes: For the -z execstack version: $ readelf -l a.out | grep -i -A1 stack GNU_STACK 0x00 0x 0x 0x0 0x0 RWE 0x4 For the -z noexecstack version: $ readelf -l a.out | grep -i -A1 stack GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0x4 However, I am able to inject and execute shellcode from a stack local character buffer in both versions. Is there another system option I am unaware of that affects enforcement? Is enforcement not supported for my system version? Thanks for your help. Could you provide source? I'm interested in checking this for my system too. MfG Goswin -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y6a24gzp@frosties.localdomain
Re: non-executable stack (via PT_GNU_STACK) not being enforced
Sure, here is an easy program you can use, but first:
PATERNAL WARNING: the shellcode below launches /bin/sh. It is from Aleph
One's Smashing the Stack for Fun and Profit. It is generally a bad idea to
blindly run someone else's shellcode on your machine since you don't know what
it will do (unless you've analyzed it). You can and should verify that the
following shellcode is the same as listed in Aleph One's article (found easily
via Google) before running this example./WARNING
static char shellcode[] =
\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b
\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd
\x80\xe8\xdc\xff\xff\xff/bin/sh;
int main() {
void (*function_pointer)(void) = (void *) shellcode;
function_pointer();
return(0);
}
---
Call it tmp.c. Now you can test for page permission enforcement:
u...@host:~$ gcc -z execstack tmp.c
u...@host:~$ ./a.out
sh-3.2$ exit ## -- this means the stack is executable
u...@host:~$ gcc -z noexecstack tmp.c
u...@host:~$ ./a.out
Segmentation fault ## -- this means the stack is non executable
u...@host:~$
If ./a.out does not segfault once you have compiled it with -z noexecstack,
then page permissions are not being enforced.
-Original Message-
From: Goswin von Brederlow goswin-...@web.de
To: Brchk05 brch...@aim.com
Cc: debian-security@lists.debian.org
Sent: Wed, Oct 13, 2010 4:46 am
Subject: Re: non-executable stack (via PT_GNU_STACK) not being enforced
Brchk05 brch...@aim.com writes:
I am running Debian 2.6.26-21lenny4 and I am puzzled by an issue with the
enforcement of page permissions. I have written a simple program with a basic
buffer overflow and compiled two versions using gcc: one with -z execstack and
another with -z noexecstack.
So, to verify that the option takes:
For the -z execstack version:
$ readelf -l a.out | grep -i -A1 stack
GNU_STACK 0x00 0x 0x 0x0 0x0 RWE 0x4
For the -z noexecstack version:
$ readelf -l a.out | grep -i -A1 stack
GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0x4
However, I am able to inject and execute shellcode from a stack local
character
buffer in both versions. Is there another system option I am unaware of that
affects enforcement? Is enforcement not supported for my system version?
Thanks for your help.
Could you provide source? I'm interested in checking this for my system
too.
MfG
Goswin
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Wed, Oct 13, 2010 at 10:58:05AM -0400, Brchk05 wrote: PATERNAL WARNING: the shellcode below launches /bin/sh. It is from Aleph One's Smashing the Stack for Fun and Profit. It is generally a bad idea to blindly run someone else's shellcode on your machine since you don't know what it will do (unless you've analyzed it). You can and should verify that the following shellcode is the same as listed in Aleph One's article (found easily via Google) before running this example./WARNING Linked from the wiki URL I gave earlier is a set of NX tests that only depend on the return machine code instruction to do the NX tests (so it is easier to show that it is not evil machine code): http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/files/head%3A/scripts/kernel-security/nx/ $ make ... $ ./nx-test Usage: ./nx-test [data|bss|stack|brk|mmap|mmap-exec] To check your stack, here it is, being protected: $ ./nx-test stack ... Attempting to execute function at 0x7fff00a5f86c If this program seg-faults, the region was enforced as non-executable... Segmentation fault or here it is without enforcement: $ ./nx-test stack ... Attempting to execute function at 0x7fff00a5f86c If this program seg-faults, the region was enforced as non-executable... Unexpected: returned from function that was marked non-executable. NX segment markings are not being enforced. You can check all kinds of memory regions in the ELF, though this is really only useful when examining NX emulation. -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101013194238.gc4...@outflux.net
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Mon, Oct 11, 2010 at 11:08:04PM -0500, Boyd Stephen Smith Jr. wrote: On Monday, October 11, 2010 17:18:34 you wrote: On 10/11/2010 12:21 PM, Boyd Stephen Smith Jr. wrote: What can be done to not disable page protections in the default kernel? Enable PAE. From what I understand, the features are not separable in the i386 kernel. You either suffer under PAE and get NX, or you suffer without NX and drop PAE. That's my understanding too. I was really asking about the default. Most of us would prefer the 1% performance hit over having an executable stack (and heap). Then install -bigmem, reboot and be done. Remember that Debian i386 targets more than beefy servers. In fact, it probably has a larger install base on Atom-based router boards, All-in-one PCs, and netbooks. And it might be non-obvious, but some CPUs (e.g. the one in my not-so-old laptop) don't support PAE, so making the default kernel use PAE would make debian unbootable on them. -- Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101012101045.ga3...@beczulka
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On 10/12/2010 03:10 AM, Marcin Owsiany wrote: On Mon, Oct 11, 2010 at 11:08:04PM -0500, Boyd Stephen Smith Jr. wrote: On Monday, October 11, 2010 17:18:34 you wrote: On 10/11/2010 12:21 PM, Boyd Stephen Smith Jr. wrote: What can be done to not disable page protections in the default kernel? Enable PAE. From what I understand, the features are not separable in the i386 kernel. You either suffer under PAE and get NX, or you suffer without NX and drop PAE. That's my understanding too. I was really asking about the default. Most of us would prefer the 1% performance hit over having an executable stack (and heap). Then install -bigmem, reboot and be done. Remember that Debian i386 targets more than beefy servers. In fact, it probably has a larger install base on Atom-based router boards, All-in-one PCs, and netbooks. And it might be non-obvious, but some CPUs (e.g. the one in my not-so-old laptop) don't support PAE, so making the default kernel use PAE would make debian unbootable on them. This is true. However, I've always wondered why we don't detect whether the CPU appears to support PAE and suggest a bigmem kernel at installation.
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Tue, 2010-10-12 at 11:10 +0100, Marcin Owsiany wrote: And it might be non-obvious, but some CPUs (e.g. the one in my not-so-old laptop) don't support PAE, so making the default kernel use PAE would make debian unbootable on them. Because it's too hard to have ubiquity run a script that checks if the processor supports PAE and then enable it by default if it does, right? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1286879343.2459.10.ca...@envygeeks
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Tue, 2010-10-12 at 05:29 -0500, Jordon Bedwell wrote: On Tue, 2010-10-12 at 11:10 +0100, Marcin Owsiany wrote: And it might be non-obvious, but some CPUs (e.g. the one in my not-so-old laptop) don't support PAE, so making the default kernel use PAE would make debian unbootable on them. Because it's too hard to have ubiquity run a script that checks if the processor supports PAE and then enable it by default if it does, right? Sorry, I didn't check the list, not Ubiquity. Not enough coffee in the world this morning, I thought this was Ubuntu lists . Also to add, the benefits of NX on PAE far outweigh those of not having PAE, unless it's found that there are a significant amount of users on Debian who do in-fact use old /old/ hardware. With it recently being found that Linux is in-fact more popular than Mac OS X it might be best to start forcing some sort of basic security on users so they don't get had easily? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1286879680.2459.15.ca...@envygeeks
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Tue, Oct 12, 2010 at 05:29:03AM -0500, Jordon Bedwell wrote: On Tue, 2010-10-12 at 11:10 +0100, Marcin Owsiany wrote: And it might be non-obvious, but some CPUs (e.g. the one in my not-so-old laptop) don't support PAE, so making the default kernel use PAE would make debian unbootable on them. Because it's too hard to have ubiquity What's ubiquity? run a script that checks if the processor supports PAE and then enable it by default if it does, right? Enable what? Last time I checked, a given kernel image either user PAE or not, there was no flag to control it. -- Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101012103542.gc3...@beczulka
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Tue, 2010-10-12 at 11:35 +0100, Marcin Owsiany wrote: What's ubiquity? Read the follow up email where I corrected mistake please... Enable what? Last time I checked, a given kernel image either user PAE or not, there was no flag to control it. You read to much into the subjective usage of enable, enable could mean many things, including enabling an entirely different kernel... Last I checked there were ways of carrying multiple Kernels and enabling them on need-be basis (I guess I need to clarify here that enabling them implies a /single/ kernel at a time,) unless the entire world has gone topsy turvy. if PAE exists - PAE Kernel if ! PAE - Non-PAE Kernel There are other ideas, but those other ideas would add significantly to management time and they're just not too viable for Debian to implement on a default level. I guess there is one where you could have the installer /ask/ the user if they want to enable PAE and list the pros /and or/ cons. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1286880503.2459.27.ca...@envygeeks
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Tue, Oct 12, 2010 at 05:48:23AM -0500, Jordon Bedwell wrote: Last I checked there were ways of carrying multiple Kernels and enabling them on need-be basis Oh, sure. I'm just pointing out that the performance hit one experiences with PAE is not the only factor to take into consideration when making the decision whether to enable PAE in the default kernel. Indeed some installer support for kernel selection would be more than desirable in such case. -- Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101012114254.gd3...@beczulka
Re: non-executable stack (via PT_GNU_STACK) not being enforced
Thank you all for your kind responses. I think I have a much better understanding of the Debian security process now. Some out-of-context excerpts below. - Marsh On 10/12/2010 05:10 AM, Marcin Owsiany wrote: And it might be non-obvious, but some CPUs (e.g. the one in my not-so-old laptop) don't support PAE, so making the default kernel use PAE would make debian unbootable on them. Somehow Windows manages to boot. On 10/11/2010 12:21 PM, Boyd Stephen Smith Jr. wrote: In4cb3406e.5020...@extendedsubset.com, Marsh Ray wrote: Anyone else perceive this situation as being a bit sub-optimal from the security perspective? No. [...] 1. Configure the BIOS properly. 2. If that's not possible, hack the BIOS. 3. If that's too hard, use LinuxBIOS / OpenBoot. Finally, don't whine when your software doesn't correct for intentional hardware crippling. [...] That said, I don't really care what the default is for i386. On 10/11/2010 12:45 PM, Michael Gilbert wrote: On Mon, 11 Oct 2010 11:50:54 -0500, Marsh Ray wrote: Anyone else perceive this situation as being a bit sub-optimal from the security perspective? I agree that this is not ideal. What can be done to not disable page protections in the default kernel? You would need to convince the kernel team that the bigmem kernel should be the default on i386 systems. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cb49057.7010...@extendedsubset.com
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On 10/10/2010 12:40 PM, Kees Cook wrote: On Sun, Oct 10, 2010 at 01:35:10PM -0400, Brchk05 wrote: this means that my CPU supports nx but I do not have the right type of kernel, i.e., one that uses PAE addressing, to support enforcement (or is that part Ubuntu specific). Does this sound plausible? That is quite likely, yes. If you're running 64bit, you already have PAE mode. If you're running 32bit, you'll need to check your kernel's CONFIG options for PAE. The default for 32bit is _not_ PAE mode, so this is probably what is happening. Anyone else perceive this situation as being a bit sub-optimal from the security perspective? I'm quite certain there are lots of Debian server admins out there who had assumed that in the year 2010 their operating system is not going to disable the nonexecutable page protection which is built into every modern processor. Yes, I have always thought that PAE in general was a kludge, but the NX bit is now a fundamental part of the process integrity provided by the CPU. It's been available in the 2.6 kernel, and shipped in MS Windows, since 2004. What can be done to not disable page protections in the default kernel? What can be done to at least warn users that the OS is silently not enforcing the page protections advertised by the CPU? - Marsh -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cb3406e.5020...@extendedsubset.com
Re: non-executable stack (via PT_GNU_STACK) not being enforced
In 4cb3406e.5020...@extendedsubset.com, Marsh Ray wrote: On 10/10/2010 12:40 PM, Kees Cook wrote: On Sun, Oct 10, 2010 at 01:35:10PM -0400, Brchk05 wrote: this means that my CPU supports nx but I do not have the right type of kernel, i.e., one that uses PAE addressing, to support enforcement (or is that part Ubuntu specific). Does this sound plausible? That is quite likely, yes. If you're running 64bit, you already have PAE mode. If you're running 32bit, you'll need to check your kernel's CONFIG options for PAE. The default for 32bit is _not_ PAE mode, so this is probably what is happening. Anyone else perceive this situation as being a bit sub-optimal from the security perspective? No. I'm quite certain there are lots of Debian server admins out there who had assumed that in the year 2010 their operating system is not going to disable the nonexecutable page protection which is built into every modern processor. Debian server admins are running amd64, not i386, and NX is supported by default on 64-bit kernels. Even if they are running the i386 arch because of some random closed app they have to have on top of Debian, they can run the amd64 kernel. Yes, I have always thought that PAE in general was a kludge, but the NX bit is now a fundamental part of the process integrity provided by the CPU. It's been available in the 2.6 kernel, and shipped in MS Windows, since 2004. MS Windows also defaults to PAE. What can be done to not disable page protections in the default kernel? Enable PAE. From what I understand, the features are not separable in the i386 kernel. You either suffer under PAE and get NX, or you suffer without NX and drop PAE. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Mon, 11 Oct 2010 11:50:54 -0500, Marsh Ray wrote: On 10/10/2010 12:40 PM, Kees Cook wrote: On Sun, Oct 10, 2010 at 01:35:10PM -0400, Brchk05 wrote: this means that my CPU supports nx but I do not have the right type of kernel, i.e., one that uses PAE addressing, to support enforcement (or is that part Ubuntu specific). Does this sound plausible? That is quite likely, yes. If you're running 64bit, you already have PAE mode. If you're running 32bit, you'll need to check your kernel's CONFIG options for PAE. The default for 32bit is _not_ PAE mode, so this is probably what is happening. Anyone else perceive this situation as being a bit sub-optimal from the security perspective? I agree that this is not ideal. I'm quite certain there are lots of Debian server admins out there who had assumed that in the year 2010 their operating system is not going to disable the nonexecutable page protection which is built into every modern processor. Yes, I have always thought that PAE in general was a kludge, but the NX bit is now a fundamental part of the process integrity provided by the CPU. It's been available in the 2.6 kernel, and shipped in MS Windows, since 2004. What can be done to not disable page protections in the default kernel? You would need to convince the kernel team that the bigmem kernel should be the default on i386 systems. What can be done to at least warn users that the OS is silently not enforcing the page protections advertised by the CPU? There is the checksec script, which I have packaged, but have yet to get sponsored. It checks whether various kernel security features are enabled. Other than that, perhaps a debconf warning on kernels without NX enabled would be useful. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101011134514.0826e6bb.michael.s.gilb...@gmail.com
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On 10/11/2010 12:21 PM, Boyd Stephen Smith Jr. wrote: Anyone else perceive this situation as being a bit sub-optimal from the security perspective? No. Interesting. Do you happen to run any such systems in a production environment? Debian server admins are running amd64, not i386, and NX is supported by default on 64-bit kernels. Even if they are running the i386 arch because of some random closed app they have to have on top of Debian, they can run the amd64 kernel. Oh good. Then I'm glad I didn't notify those admins I know who bought expensive IBM servers just a couple of years ago that turned out to have virtualization support for 64-bit guests disabled in the BIOS even though the Intel Xeon CPUs had support for it. They were already disappointed that they couldn't use weren't getting all the features of the processors and they would be just heartbroken to find out that they'd been pwned through executable stacks too. MS Windows also defaults to PAE. So from this we can conclude it doesn't adversely affect consuming content (i.e. watching television) and playing 3D games, which is probably actually telling us something about PAE's effect on kernel task-switch latencies. FWIW, Microsoft also used to have separate single and multi-CPU kernels, but these days prefers to support a single kernel image. Didn't Debian begin installing SMP by default a while back too? What can be done to not disable page protections in the default kernel? Enable PAE. From what I understand, the features are not separable in the i386 kernel. You either suffer under PAE and get NX, or you suffer without NX and drop PAE. That's my understanding too. I was really asking about the default. How bad is PAE really? These guys: http://people.redhat.com/nmurray/RHEL-2.1-VM-whitepaper.pdf seem to say when they tested it worked out to about 1% overhead. My guess is the kind of sites that would find that significant are probably tuning their own kernels. Most of us would prefer the 1% performance hit over having an executable stack (and heap). On 10/11/2010 12:45 PM, Michael Gilbert wrote: On Mon, 11 Oct 2010 11:50:54 -0500, Marsh Ray wrote: Anyone else perceive this situation as being a bit sub-optimal from the security perspective? I agree that this is not ideal. Thank you, I'm not totally off the wall then (at least not in this specific way). What can be done to not disable page protections in the default kernel? You would need to convince the kernel team that the bigmem kernel should be the default on i386 systems. Please? What can be done to at least warn users that the OS is silently not enforcing the page protections advertised by the CPU? There is the checksec script, which I have packaged, but have yet to get sponsored. It checks whether various kernel security features are enabled. That sounds useful. Do you have a link? Other than that, perhaps a debconf warning on kernels without NX enabled would be useful. I've sure seen less valuable warnings. - Marsh -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cb38d3a.1040...@extendedsubset.com
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Mon, 11 Oct 2010 17:18:34 -0500 Marsh Ray wrote: You would need to convince the kernel team that the bigmem kernel should be the default on i386 systems. Please? Don't ask this list, ask the kernel team (via bug report and/or mailing list message). Note that ubuntu uses some kind of NX emulation on i386 when its disabled in the bios or unsupported on the cpu, which may be an option as well here. A patch for that submitted as a kernel bug would be most effective. What can be done to at least warn users that the OS is silently not enforcing the page protections advertised by the CPU? There is the checksec script, which I have packaged, but have yet to get sponsored. It checks whether various kernel security features are enabled. That sounds useful. Do you have a link? http://trapkit.de/tools/checksec.html Best wishes, Mike -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101011192429.ad97c225.michael.s.gilb...@gmail.com
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Monday, October 11, 2010 17:18:34 you wrote: On 10/11/2010 12:21 PM, Boyd Stephen Smith Jr. wrote: Anyone else perceive this situation as being a bit sub-optimal from the security perspective? No. Interesting. Do you happen to run any such systems in a production environment? Depends on what you mean by production. I do manage http://www.freegeekarkansas.org, http://www.iguanasuicide.net, and the MX for iguanasuicide.net. It's only 3 systems.[1] All are VPSes, 2 running Debian Lenny; 1 running Ubuntu 10.04 LTS. Debian server admins are running amd64, not i386, and NX is supported by default on 64-bit kernels. Even if they are running the i386 arch because of some random closed app they have to have on top of Debian, they can run the amd64 kernel. Oh good. Then I'm glad I didn't notify those admins I know who bought expensive IBM servers just a couple of years ago that turned out to have virtualization support for 64-bit guests disabled in the BIOS even though the Intel Xeon CPUs had support for it. They were already disappointed that they couldn't use weren't getting all the features of the processors and they would be just heartbroken to find out that they'd been pwned through executable stacks too. 1. Configure the BIOS properly. 2. If that's not possible, hack the BIOS. 3. If that's too hard, use LinuxBIOS / OpenBoot. Finally, don't whine when your software doesn't correct for intentional hardware crippling. Also: -bigmem is available. What can be done to not disable page protections in the default kernel? Enable PAE. From what I understand, the features are not separable in the i386 kernel. You either suffer under PAE and get NX, or you suffer without NX and drop PAE. That's my understanding too. I was really asking about the default. Most of us would prefer the 1% performance hit over having an executable stack (and heap). Then install -bigmem, reboot and be done. Remember that Debian i386 targets more than beefy servers. In fact, it probably has a larger install base on Atom-based router boards, All-in-one PCs, and netbooks. That said, I don't really care what the default is for i386. When multiple kernels are available for my architecture, I do the research and install the correct one. [1] One of the systems in that configuration is not directly public facing; it handles the ClamAV scanning via a private network for the MX. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: non-executable stack (via PT_GNU_STACK) not being enforced
The noexecstack option has no affect on shell code or any other interpreted language. It only prevents native code (aka machine code) from executing. --- Wade On 2010-10-10, at 6:53, Brchk05 brch...@aim.com wrote: I am running Debian 2.6.26-21lenny4 and I am puzzled by an issue with the enforcement of page permissions. I have written a simple program with a basic buffer overflow and compiled two versions using gcc: one with -z execstack and another with -z noexecstack. So, to verify that the option takes: For the -z execstack version: $ readelf -l a.out | grep -i -A1 stack GNU_STACK 0x00 0x 0x 0x0 0x0 RWE 0x4 For the -z noexecstack version: $ readelf -l a.out | grep -i -A1 stack GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0x4 However, I am able to inject and execute shellcode from a stack local character buffer in both versions. Is there another system option I am unaware of that affects enforcement? Is enforcement not supported for my system version? Thanks for your help.
Re: non-executable stack (via PT_GNU_STACK) not being enforced
--On Sunday, October 10, 2010 9:53 AM -0400 Brchk05 brch...@aim.com wrote: I am running Debian 2.6.26-21lenny4 and I am puzzled by an issue with the enforcement of page permissions. I have written a simple program with a basic buffer overflow and compiled two versions using gcc: one with -z execstack and another with -z noexecstack. I could be wrong as I haven't looked at the whole NX/XD thing in detail, been a while since I've actively done anything of the sort, but, it would seem to me smashing is not the same as executing on the stack necessarily. Overwriting/changing returns on the stack via a smash, or clobbering code via a smash won't be affected by non executable stack, since that's just changing stack variables, now if your code section is also non-writable, and your heap is non-executable, you're further protected but you can still do a return to libc attack. Wikipedia talks about this http://en.wikipedia.org/wiki/Stack_buffer_overflow#Nonexecutable_stack -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2ccc3b7fe7647c824eb6f...@[192.168.1.68]
Re: non-executable stack (via PT_GNU_STACK) not being enforced
Hi, * Wade Richards w...@wabyn.net [2010-10-10 19:08]: The noexecstack option has no affect on shell code or any other interpreted language. It only prevents native code (aka machine code) from executing. errm http://en.wikipedia.org/wiki/Shellcode -- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0xA0A0 For security reasons, all text in this mail is double-rot13 encrypted. pgpFxgHWUzsMK.pgp Description: PGP signature
Re: non-executable stack (via PT_GNU_STACK) not being enforced
In this case, the target of my clobbered return address is on the stack (in the stack local character buffer), so this is exactly what NX/XD is intended to prevent. -Original Message- From: Michael Loftis mlof...@wgops.com To: debian-security@lists.debian.org Sent: Sun, Oct 10, 2010 1:08 pm Subject: Re: non-executable stack (via PT_GNU_STACK) not being enforced --On Sunday, October 10, 2010 9:53 AM -0400 Brchk05 brch...@aim.com wrote: I am running Debian 2.6.26-21lenny4 and I am puzzled by an issue with the enforcement of page permissions. I have written a simple program with a basic buffer overflow and compiled two versions using gcc: one with -z execstack and another with -z noexecstack. I could be wrong as I haven't looked at the whole NX/XD thing in detail, been a while since I've actively done anything of the sort, but, it would seem to me smashing is not the same as executing on the stack necessarily. Overwriting/changing returns on the stack via a smash, or clobbering code via a smash won't be affected by non executable stack, since that's just changing stack variables, now if your code section is also non-writable, and your heap is non-executable, you're further protected but you can still do a return to libc attack. Wikipedia talks about this http://en.wikipedia.org/wiki/Stack_buffer_overflow#Nonexecutable_stack -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2ccc3b7fe7647c824eb6f...@[192.168.1.68]
Re: non-executable stack (via PT_GNU_STACK) not being enforced
Hi, On Sun, Oct 10, 2010 at 01:35:10PM -0400, Brchk05 wrote: nx is in /proc/cpuinfo as a flag, though it does not appear at all in my dmesg output. From what I can tell from the Ubuntu link you supplied, I am assuming this means that my CPU supports nx but I do not have the right type of kernel, i.e., one that uses PAE addressing, to support enforcement (or is that part Ubuntu specific). Does this sound plausible? That is quite likely, yes. If you're running 64bit, you already have PAE mode. If you're running 32bit, you'll need to check your kernel's CONFIG options for PAE. The default for 32bit is _not_ PAE mode, so this is probably what is happening. -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101010174049.gj4...@outflux.net
Re: non-executable stack (via PT_GNU_STACK) not being enforced
It's a 32-bit kernel and probably does not have PAE support enabled so I think the mystery has been solved. Thanks to everyone for your help. -Original Message- From: Kees Cook k...@debian.org To: Brchk05 brch...@aim.com Cc: debian-security@lists.debian.org Sent: Sun, Oct 10, 2010 1:40 pm Subject: Re: non-executable stack (via PT_GNU_STACK) not being enforced Hi, On Sun, Oct 10, 2010 at 01:35:10PM -0400, Brchk05 wrote: nx is in /proc/cpuinfo as a flag, though it does not appear at all in my dmesg output. From what I can tell from the Ubuntu link you supplied, I am assuming this means that my CPU supports nx but I do not have the right type of kernel, i.e., one that uses PAE addressing, to support enforcement (or is that part Ubuntu specific). Does this sound plausible? That is quite likely, yes. If you're running 64bit, you already have PAE mode. If you're running 32bit, you'll need to check your kernel's CONFIG options for PAE. The default for 32bit is _not_ PAE mode, so this is probably what is happening. -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101010174049.gj4...@outflux.net
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Sun, 10 Oct 2010 14:05:52 -0400 Brchk05 brch...@aim.com wrote: It's a 32-bit kernel and probably does not have PAE support enabled so I think the mystery has been solved. Thanks to everyone for your help. Try linux-image-2.6-686-bigmem, it probably has PAE enabled. Best regards, -_Edwin -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101010212530.20533...@deb0
