grsecurity forums

Hello,

This may be a little off-topic but I have a minor problem with a python script and can seem to figure out why because of grsec/pax.
Everytime I get: stack smashing attack in function PyEval_EvalFrame(),
signal 6 sent and denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0.
Since it's a python script paxctl doesn't help me, can you tell me what logging options to enable to show me more info on this?
--
Greetings Japie

If it was PaX you could use paxctl on python binary (usually /usr/bin/python) but from log you pasted here (stack smashing attack in function..) it looks like problem is elsewhere. Grsecurity, here, only reports that your application was sent signal 6.

Your python interpreter is compiled with SSP enabled gcc and this kind of problem should be reported to your distribution bugzilla.

tosh wrote:it looks like problem is elsewhere. Grsecurity, here, only reports that your application was sent signal 6.

I know, and denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 means it can't leave a coredump behind because of the core size resource limit, right?
Is there a way to make the resource limit bigger via proc?

tosh wrote:Your python interpreter is compiled with SSP enabled gcc and this kind of problem should be reported to your distribution bugzilla.

It's one of the first Hardened Linux From Scratch systems, fairly older than any distro using ssp/pax/grsec and since then HLFS is changed quite a lot (for a reason) but it (almost) works for every app. I run.

I tryed paxctl on the python bin. itself wich didn't help so grsec/pax isn't the problem itself but they do make it hard to find the problem because the lack of a coredump.

For the first question: `man bash` and search for ulimit.

I also have system build around HLFS book and now I remember heaving similar problem with python, with one script but I don't have/use that script anymore.

Some python scripts do something that for binary build with SSP looks like stack smashing attack and I can't recommend anything other that recompiling python with -fno-stack-protector or/and -fno-stack-protector-all.

I also had a problem with perl binary when linked as PIE, it was just crashing on many scripts.

tosh wrote:For the first question: `man bash` and search for ulimit.

That was so easy, I'am ashamed of myself...

tosh wrote:I also have system build around HLFS book and now I remember heaving similar problem with python, with one script but I don't have/use that script anymore.

In my case it's "mminfo" a tool used to extract information from various multimedia sources used inside freevo.
All media works except for audio-cd's, those gives the trouble.
Recompiling Python with CC="gcc -fno-stack-protector-all" does defenatly work.
Until I find out what is causing it I will use it this way.

Thanks for helping out and I wish you (all) a happy new-year!

japie wrote:Recompiling Python with CC="gcc -fno-stack-protector-all" does defenatly work.
Until I find out what is causing it I will use it this way.

you might want to take a look at http://bugs.gentoo.org/show_bug.cgi?id=135265.

PaX Team wrote:you might want to take a look at http://bugs.gentoo.org/show_bug.cgi?id=135265.

That explains a lot, I tryed to upgrade bind and ran into trouble too wich are also explained here.
Thanks for pointing me there!