grsecurity forums

Hi,

When can we get stable patch for stable kernel 2.4.34?

Regards,
y.

There has been a patch in http://grsecurity.net/~spender. It will be released officially this weekend, most likely.

-Brad

Spender,

I think it would be a good idea to wait for the fix for expand_stack() critical bug:
http://www.digitalarmaments.com/pre2007-00018659.html
Don't you think so?

I mean, grsec for 2.4.34 should have the fix for pax code (IMHO). It would be a real waste of time to release two patches (one with the fix and the other one being vulnerable for the developper as well as the users (since we'd have to duplicate the setup and install work.

-rs

I don't think we'll be waiting 6 months, as the "pre-advisory" states for the final advisory to be released publicly. They can't make up their mind whether it "will" or "may" be released either.

-Brad

rs wrote:I think it would be a good idea to wait for the fix for expand_stack() critical bug:
http://www.digitalarmaments.com/pre2007-00018659.html
Don't you think so?

i don't. for now there's no bug, there's only a claim of it (actually two if you count the supposed remote one as well, one wonders why it hasn't been announced with the same fanfare, it's surely a bigger thing than a local one). this company hasn't put anything tangible on the table therefore there's nothing we can do. furthermore, it's a bit suspicious that they intend to make a living out of this bug for another few months yet they disclosed the supposedly buggy function (which isn't complex and therefore easy to see if something's wrong in it), looks like the left hand doesn't know what the right one's doing. it's also funny that they think that grsec "should prevent any form of code execution and privilege escalation" whereas none of us has ever made that claim (quite the contrary in fact, we give certain guarantees only for certain classes of remote bugs, on localhost all bets are off, there's no system on the market today that could claim guarantees there). and if we accept their claim about grsec's goals, then wouldn't the very fact that one can run an exploit (against whatever bug) at all be *the* vulnerability itself?

I mean, grsec for 2.4.34 should have the fix for pax code (IMHO).

where did you see that 2.4.34 (or any particular grsec/pax version for that matter) was affected?

Given your comments (spender&paxteam), I fully agree with you. Sorry for the fud.

I read the announcement in several security mailing-lists. Or at least one: Bugtraq (where a RedHat security team guy answered also against the original post). Perhaps an official statement, in mailing-lists, as well as grsec/pax webpages, would help.

Cheers.
-rs

rs wrote:Perhaps an official statement, in mailing-lists, as well as grsec/pax webpages, would help.

sorry, but it just doesn't scale. you wouldn't expect us to do the same every time someone makes a similar announcement (and given the lack of quality of bugtraq, i can imagine that a cron job would suffice). so the best response is to simply not start this claim-counterclaim cycle at all. people who are genuinely concerned about bugs in grsec/pax can look for them themselves, everyone else will have (and already must have had) to trust the code anyway.

At least they managed to make enough of an impact to make in on the grsecurity front page ...

They claim to have posted some exploit (20-01-07).

Basically they generate a segmantation fault and hope to escalate the privileges.
It stops with a segmentation fault on my system.
Perhaps someone else has more success with this 'exploit'.

They stil haven't posted any details on the version of grsecurity, kernel and pax.
They haven't posted details on the configuration used.
Also they haven't posted kernelconfiguration details and effective grsecurity options.
The sourcecode reveals they want "chpax -m" executed for the exploitcode.
It's seems like asking "disable your security so we can prove it does not work".

Any other opinion?

PS sorry for keeping this thread alive.

Definetly another opinion here, yes. It does SIGSEGV but leaves the system in an unstable state, at least for me (see here). Also, Brad just confirmed that it can probably be used for more than just a local DoS (check here, there's also a follow-up; a preliminary "workaround" is also available).

It appears to be a not-so-uncommon misconception, that the chpax binary's default permissions will offer "protection". That's not true, however.