[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: