GrSecurity: The Truth About Linux 4.6 [Security]

[pal666]

The kid found one of many false positives with this tool and trolling over the internet that there is a high vulnerability in Grsecurity and blamed the team that they do not doing proper security audits on their patch.

well, he found comparison unsigned < 0, obviously it had no audit whatsoever, security or otherwise

[pal666]

original article boils down to "you should upgrade kernels often, because we will be merging parts of grsecurity among other things"
reply boils down to "they are lying, grsecurity is more secure"
such unrelated butthurt

[Hunger.hu]

well, he found comparison unsigned < 0

Nope. The PaX Size Overflow plugin found it.

HTH

[pal666]

Nope. The PaX Size Overflow plugin found it.
HTH

plugin crashed, he found. and plugin crashed not on comparison, so that was ridiculous attemp at lying to me. do all grsecurity people behave like this? btw, comparison doesn not need runtime to be detected.
still no audit

[Hunger.hu]

plugin crashed

Nope. Plugin does not crash.

Plugin instruments extra checks to the kernel code in compilation time. At run-time these extra checks detected the integer underflow and triggered a deterministic panic().

If he use the "pax_size_overflow_report_only" kernel parameter then it does not call the panic() function just logs the detected underflow to kernel buffer (dmesg) and the system is running on and on. Nothing crash here.

[pal666]

Nope. Plugin does not crash.

Plugin instruments extra checks to the kernel code in compilation time. At run-time these extra checks detected the integer underflow and triggered a deterministic panic().

If he use the "pax_size_overflow_report_only" kernel parameter then it does not call the panic() function just logs the detected underflow to kernel buffer (dmesg) and the system is running on and on. Nothing crash here.

why are you telling me all of this? i know this and this is irrelevant, because: 1) all what plugin did for him is crash. 2) plugin did not find comparison. 3) comparison was found by bug reporter. 4) comparison was broken by grsecurity patch which obviously had zero audit.5) do not try to post random bullshit again

[stevenc]

But was that unsigned < 0 comparison in the grsecurity patch, or in the vanilla kernel?

[starshipeleven]

But was that unsigned < 0 comparison in the grsecurity patch, or in the vanilla kernel?

the patch changes the signed to unsigned, a few lines later there is the comparison, and who made the patch didn't adjust that too.

[Hunger.hu]

why are you telling me all of this? i know this and this is irrelevant, because: 1) all what plugin did for him is crash. 2) plugin did not find comparison. 3) comparison was found by bug reporter. 4) comparison was broken by grsecurity patch which obviously had zero audit.5) do not try to post random bullshit again

You said "plugin crashed" multiple times but there was no crash so you are who post random bullshit instead of reading.

1) It was a managed exception. The system integrator has the choice to log only this type of integer under- and overflows with "pax_size_overflow_report_only" kernel parameter or get a safer panic() call to circumvent a potential privilege escalation attack. This choice is depends on the result of a risk analysis (Integrity vs. Availability). Without risk management the PaX Size Overflow GCC plugin does not recommended for production use.

2) The comparison and the underflow does not calls panic() and does not crash. He find nothing without this feature. This plugin was detected the underflow and he thought it is a vulnerability. Not every integer under- and overflow has security implications. This was a false positive which triggered the plugin to report but was no real security issue. He cannot use this integer underflow for privilege escalation attacks.

3) The kid is used this plugin without the knowledge of it. He enabled every option in kernel config of Grsecurity. One of Grsec features is this plugin which - again - not for production use. If he use vanilla kernel only but with CONFIG_KMEMCHECK he got similar results, kernel panics and much slowdowns. Is it the problem of vanilla kernels? Nope. KmemCheck feature is for developers and kernel hackers. Not for average users. The PaX Size Overflow GCC plugin is for experts too and not for average users.

Experts can use "pax_size_overflow_report_only" kernel parameter if they do not want the plugin to call panic() on a detected integer overflow event.

[pal666]

You said "plugin crashed" multiple times but there was no crash

imbecile, kernel panic is a crash. it does not matter whether it could be prevented with kernel parameters, as a matter of fact plugin did nothing but crash. and i will repeat, imbecile, i am not interested in plugin at all, you brought this fucking plugin crash as an excuse, while it is completely irrelevant because it had nothing to do with comparison. plugin crashed on decrement, i was not talking about decrement, imbecile. and i was not talking about crash, until some imbecile brought crash into discussion. i was talking about comparison unsigned < 0 which has to be caught by patch audit, imbecile. it does not matter what kernel config was enabled by bug reporter, this patch has to be caught before runtime by any adequate review but it is obvious that adequate grsecurity people do not exist.
no wonder grsecurity has no traction, if it is made by bunch of hallucinating fucks like you