Re: non-executable stack (via PT_GNU_STACK) not being enforced

[Michael Gilbert]

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

[Jordon Bedwell]

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

[Jordan Metzmeier]

-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

[Yves-Alexis Perez]

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

[Jordon Bedwell]

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

[Yves-Alexis Perez]

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

[Jordon Bedwell]

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

[Yves-Alexis Perez]

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

[Kees Cook]

On Wed, Oct 13, 2010 at 10:58:05AM -0400, Brchk05 wrote:
> : 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.

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

[Brchk05]

Sure, here is an easy program you can use, but first:


: 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.


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 
To: Brchk05 
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  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

[Goswin von Brederlow]

Brchk05  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

[Marsh Ray]

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:

In<4cb3406e.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

[Marcin Owsiany]

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  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

[Jordon Bedwell]

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

[Marcin Owsiany]

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  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

[Jordon Bedwell]

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

[Jordon Bedwell]

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

[Sysadmin - The Well @ Poway]

 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

[Marcin Owsiany]

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  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

[Boyd Stephen Smith Jr.]

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

[Michael Gilbert]

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

[Marsh Ray]

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

[Michael Gilbert]

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

[Boyd Stephen Smith Jr.]

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

[Marsh Ray]

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

[Török Edwin]

On Sun, 10 Oct 2010 14:05:52 -0400
Brchk05  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

Re: non-executable stack (via PT_GNU_STACK) not being enforced

[Brchk05]

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 
To: Brchk05 
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

[Kees Cook]

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

[Török Edwin]

On Sun, 10 Oct 2010 13:35:10 -0400
Brchk05  wrote:

> Thanks, Kees.
> 
> 
> 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?

Yes, you should see "NX (Execute Disable) protection: active".

Is this a 32-bit or a 64-bit kernel? (all 64-bit kernels come with NX,
while not all 32-bit ones come with NX).

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/20101010205641.78c22...@deb0

Re: non-executable stack (via PT_GNU_STACK) not being enforced

[Brchk05]

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 
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  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

[Brchk05]

Hi Wade,


Thanks for your response.  Shellcode is native machine code.  It is not shell 
script code.  See http://en.wikipedia.org/wiki/Shellcode




-Original Message-
From: Wade Richards 
To: Brchk05 
Cc: debian-security@lists.debian.org 
Sent: Sun, Oct 10, 2010 11:59 am
Subject: 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  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

[Brchk05]

Thanks, Kees.


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?


-Original Message-
From: Kees Cook 
To: Brchk05 
Cc: debian-security@lists.debian.org
Sent: Sun, Oct 10, 2010 12:07 pm
Subject: Re: non-executable stack (via PT_GNU_STACK) not being enforced


Hi,

On Sun, Oct 10, 2010 at 09:53:40AM -0400, Brchk05 wrote:
> 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?

Your CPU may not support NX enforcement. Check your dmesg output, and your
cpuflags line in /proc/cpuinfo for "nx".

See https://wiki.ubuntu.com/Security/Features#nx though ignore the nx-emu
notes, as that's not in Debian.

-Kees

-- 
Kees Cook@debian.org

 

Re: non-executable stack (via PT_GNU_STACK) not being enforced

[Nico Golde]

Hi,
* Wade Richards  [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

[Michael Loftis]

--On Sunday, October 10, 2010 9:53 AM -0400 Brchk05  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 





--
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

[Wade Richards]

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  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

[Kees Cook]

Hi,

On Sun, Oct 10, 2010 at 09:53:40AM -0400, Brchk05 wrote:
> 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?

Your CPU may not support NX enforcement. Check your dmesg output, and your
cpuflags line in /proc/cpuinfo for "nx".

See https://wiki.ubuntu.com/Security/Features#nx though ignore the nx-emu
notes, as that's not in Debian.

-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/20101010160723.gh4...@outflux.net