
Linux kernel: multiple x86_64 vulnerabilities - jgeralnik
http://seclists.org/oss-sec/2014/q4/1052
======
dmix
> This is likely to be easy to exploit for privilege escalation, except on
> systems with SMAP or UDEREF

Another reminder why everyone should be using
[https://grsecurity.net](https://grsecurity.net) which provides these
mitigations to the Linux kernel via patches. GRSecurity has had SMAP aka
KERNEXEC for a long time as well as UDEREF
[https://grsecurity.net/~spender/uderef.txt](https://grsecurity.net/~spender/uderef.txt)

If you keep any sensitive data on a Linux server you should seriously consider
grsec.

Even last week there was an ASLR bypass posted on OSS-security which of-course
grsec already protected you against [http://seclists.org/oss-
sec/2014/q4/908](http://seclists.org/oss-sec/2014/q4/908)

There is a lot of drama around the fact Linux core devs don't adopt these
patches by default. But regardless Linux is pretty insecure by default and
grsec makes privesc via various classes of exploits significantly harder.

~~~
sarciszewski
> There is a lot of drama around the fact Linux core devs don't adopt these
> patches by default.

What is the main cause of resistance for implementing these fixes? It worries
me that they haven't put forth the effort to do so yet.

~~~
dmix
Daniel Micay who works on security with Arch Linux explains why GRSecurity
hasn't been upstreamed here:
[http://article.gmane.org/gmane.comp.security.oss.general/150...](http://article.gmane.org/gmane.comp.security.oss.general/15054)

And you can see Greg K H (a linux core dev) snarky reply here:
[http://article.gmane.org/gmane.comp.security.oss.general/150...](http://article.gmane.org/gmane.comp.security.oss.general/15056)

Basically a few people have tried in the past but Linux core devs are against
large patches. And if you look at old threads [1] where people have attempted
to break it up into small patches the core devs have been disinterested.

Just to be clear we're talking about many 2003-era exploit mitigation
techniques not being adopted into the kernel. And as a side effect every year
there are countless vulnerabilities that come out - for which proactive
mitigations with up-to-date PoC's have existed for years.

Greg KH basically said in that thread that it would need to be broken up into
tons of small patches. Then each patch will have to be submitted and go
through the massive politics of getting it upstreamed. This would require a
full-time paid team of people doing it, since Linux foundation or similar
organizations don't seem to think it's worth paying for a team of security
experts themselves to do similar work hardening the kernel.

Additionally, a long time ago (before grsec I believe) the person (or team)
behind PaX, whose code is now a significant percentage of GRSecurity, is
anonymous and the Linux core refused to accept patches from anonymous
developers.

Also for a more meta-discussion on how security is handled by the core devs
see Spenders summary here in "KASLR: An Exercise in Cargo Cult Security"
[https://forums.grsecurity.net/viewtopic.php?f=7&t=3367](https://forums.grsecurity.net/viewtopic.php?f=7&t=3367)

[1] Spender links to old threads here where people tried breaking it up and
submitting small patches:

[https://twitter.com/grsecurity/status/541797486479028225](https://twitter.com/grsecurity/status/541797486479028225)

[https://twitter.com/grsecurity/status/541797673419145217](https://twitter.com/grsecurity/status/541797673419145217)

[https://twitter.com/grsecurity/status/541797780482977792](https://twitter.com/grsecurity/status/541797780482977792)

~~~
pakled_engineer
Does systemd even work w/patched grsec kernel? Last I heard Spender was
considering writing a security module to get deep hooks into the kernel to
handle systemd, so I assumed systemd killed off any hope of more grsec/pax
patches making it upstream.

~~~
zanny
I've tried running the grsec kernel on Arch a few times, and I've never gotten
it to boot once, it usually just panics immediately. In the same way openSSL
was a base of nobody wanting to invest in covering your own ass, there is no
interest in having a legitimately secure kernel the way grsec proposes, and
even in Arch there are only a few people working on it and while it is in the
official repos it really should be in the stock kernel if they wanted to send
a message.

------
0x0
Status for at least one of the CVEs in Debian is here: [https://security-
tracker.debian.org/tracker/CVE-2014-8133](https://security-
tracker.debian.org/tracker/CVE-2014-8133) (currently unfixed)

------
vojfox
How can this/these be exploited?

~~~
whitten
I'm sure this question is important to ask to learn how to protect yourself,
but it struck me as a question that is difficult to ask. By asking it, you
sound like someone who wants to exploit others vulnerabilities rather than
someone who is trying to protect themselves.

------
xorcist
Is there any information whether the fix is in 3.18.1, which was released
yesterday?

~~~
amluto
CVE-2014-9090 and CVE-2014-9322 were fixed in 3.18, just before it was
released.

