10 ms·

Linux kernel: multiple x86_64 vulnerabilities

256 points by jgeralnik 12y ago

0x0 12y ago
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)
dmix 12y ago
> 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 12y ago
  > 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 12y ago
    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/15054 http://article.gmane.org/gmane.comp.security.oss.general/150... And you can see Greg K H (a linux core dev) snarky reply here: http://article.gmane.org/gmane.comp.security.oss.general/15056 http://article.gmane.org/gmane.comp.security.oss.general/150... 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
    - mburns 12y ago
      "I'm glad to help out with this if you can point me at specific examples of things that should be changed." Doesn't sound the least bit snarky. Submitting small patches isn't unreasonable, and GRSecurity-inclined people would do well to play nice with the kernel dev process.
      - deleted 12y ago
        [deleted]
      - someengineer 12y ago
        Totally agree. His reply is an overly polite response to a rather snarky rant on why the Linux devs should just shut up and accept the author's massive merge. Giant projects like the Linux kernel just don't work that way.
        dmix 12y ago
        No one in that thread is recommending the Linux devs take the monolithic GRSecurity patches flat out. If you read the originally linked thread Daniel explains why it can't be accepted this way nor does he propose it should. Rather attempts to submit it in smaller patches have been met with disinterest. As well as the fact security in general has the appearance of being sidelined by the core developers - which has created a large disincentive for developers interested in getting GRSecurity upstreamed from even trying (again).
        nodata 12y ago
        Maybe the grsec people should better communicate the advantage. I suggest taking each CVE and listing whether it would have been mitigated by running a grsec kernel, and compare it to something else (selinux or whatever)
        dmix 12y ago
        If there is a kernel privilege escalation then SELinux can be disabled as Spender loves to demonstrate https://www.youtube.com/watch?v=WI0FXZUsLuI https://www.youtube.com/watch?v=WI0FXZUsLuI GRSec does includes it's own MAC system as an alternative to SELinux but that is only a small part. PaX/grsec is in a different class of mitigation. I don't really know any competitors besides other implementations of small subsets by different operating systems or hardware manufacturers. To your other point, I don't think anyone who has been following Linux security for any amount of time thinks that Spender or PaX are in need of proving themselves.
  - alecco 12y ago
    Linus hates security and security related projects. He is against prioritizing security bugs over normal bugs. Also he is against embargo (coordinated release). One example of many, many instances: http://yarchive.net/comp/linux/security_bugs.html http://yarchive.net/comp/linux/security_bugs.html
    - api 12y ago
      I simultaneously agree and disagree with him. I think he's wrong because security is increasingly critical, but I agree with him because I can't stand (most of) the infosec profession. The vast majority of infosec gives zero thought to any concern other than security, resulting in systems that are insanely complex with incredibly poor user experience. Not only does this break everything else, but it's bad for security in the long run. The typical security solution is something that makes it so hard for people to do ordinary work that they either disable it entirely (e.g. SELinux) or work around it (tunneling through aggressive firewalls, etc.) and defeat the whole purpose. I worked in a research institution once where some departments had people whose informal job description (I was told) was to "help work around security so we can get our work done." If you worked with security, they'd put up so many road blocks and say "no" to so many things that months and months could go by without a single thing being accomplished. There was a whole culture of literally conspiring to ignore and sidestep the security department. People kept doing this even after we got hacked, arguing (again explicitly) that the cost of complying with infosec was greater than the cost of the hack. Infosec is largely a ghetto populated by people who only think about one thing, and who think that one thing is the sexist, coolest, most important thing in the entire world. There are other such ghettoes and they all suffer from similar sorts of problems. I firmly believe that almost nothing can be done well without whole system thinking. You have to look at the entire context of a system, not just the one thing you're building or optimizing. Think about the system from technical details all the way up to how users will interact with it on a day to day basis. A good starting point is to look at whatever you're building and ask "how annoyed would I be if management foisted this on me?" If the answer is "very annoyed," your system has horrible UX. This isn't the only case where I simultaneously agree and disagree with Linus. Another notable one is C vs C++. Short version: I think C++ is fine and makes it a lot easier to do many things, but anyone writing C++ should have YAGNI and KISS tattooed on their forehead. As with many other "powerful" multi-paradigm languages it takes discipline to avoid over-using the language's features, and most programmers unfortunately have the opposite tendency. They over-abstract and over-engineer as if they're trying to show how clever they are.
- nchelluri 12y ago
  I haven't really explored this but I remember a few years ago I liked the idea of using grsecurity on my VPSs. Unfortunately I couldn't come up with a good way to do it. I believe the idea I stumbled onto was to use kexec to load a hardened kernel after boot, which seems doable but I am not sure it would be a good route to go. Have you/anyone ever tried anything like this?
  - elwin 12y ago
    Linode VPSs can boot custom kernels: https://www.linode.com/docs/tools-reference/custom-kernels-distros/run-a-custom-compiled-kernel-with-pvgrub https://www.linode.com/docs/tools-reference/custom-kernels-d... I don't know if this is possible with other providers.
    - voltagex_ 12y ago
      EC2: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UserProvidedKernels.html http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UserProvi... DO: http://0wned.it/2014/08/27/custom-kernel-on-a-digitalocean-droplet-the-right-way/ http://0wned.it/2014/08/27/custom-kernel-on-a-digitalocean-d... Rackspace: http://www.rackspace.com/knowledge_center/article/linux-kernel-management http://www.rackspace.com/knowledge_center/article/linux-kern...
- mintplant 12y ago
  Would anyone happen to know of grsecurity is compatible with the linux-ck patchset?
- amluto 12y ago
  I think that UDEREF works here, on brief inspection of the code. However I haven't looked too hard, but grsec seems to have its own bugs in this area. I'll email them. As usual, my nasty IRET test case is available [1], and, as of the embargo expiration (Monday), it contains tests for the whole pile of issues here, among others. Save your work before running it. [1] https://gitorious.org/linux-test-utils/linux-clock-tests/source/ https://gitorious.org/linux-test-utils/linux-clock-tests/sou...
  - easytiger 12y ago
    FYI that link is 404
    - wglb 12y ago
      Perhaps this is the one? https://gitorious.org/linux-test-utils/linux-clock-tests/source/10b9a7d317f6d8ae5f32bcb4bbbb186acdd6b89a https://gitorious.org/linux-test-utils/linux-clock-tests/sou...:
      - easytiger 12y ago
        Thanks very useful, I was just writing something similar. INterested in: syscall32_from_64.c What's does that do? I know in IA32 emu mode on a 64bit kernel from running binaries using strace that they make gettimeofday etc syscalls rather than use vdso.
        amluto 12y ago
        I think I wrote syscall32_from_64 to try to test something related to the 32-bit syscall (as opposed to sysenter or int80) handler in ia32entry.S. TBH, I don't remember exactly what it was for. On my Intel-based box, it gets SIGILL, but if I run it under QEMU without KVM, it says "syscall return = 137". The more interesting things in there include segregs (testing for an info leak that has no CVE yet), syscall_exit_regs_64 (run it under strace and watch it fail), and dump_all_pmcs. I'm hoping that dump_all_pmcs will stop working in Linux 3.20. Also, on new enough kernels with new enough glibc (I think), even 32-bit programs use vdso timing.
- ema_ 12y ago
  GRSecurity users have to actually upgrade their kernel anyways: > On those systems, assuming that the mitigation works correctly, the impact of this bug may be limited to massive memory corruption and an eventual crash or reboot
- richwhiteguy 12y ago
  GRSecurity is a bunch of weak, messy patches for an even weaker, messier kernel. Why not just install the most superior kernel of them all -- OpenBSD -- and not have to worry about these weekly Linux security advisories? When are people going to realize that, despite its contributions to open source, Linux is a complete and utter mess? Choose OpenBSD for your Unix needs. OpenBSD -- the world's simplest and most secure Unix-like OS. Creator of the world's most used SSH implementation OpenSSH, the world's most elegant firewall PF, the world's most elegant mail server OpenSMTPD, and the OpenSSL rewrite LibreSSL. OpenBSD -- the cleanest kernel, the cleanest userland and the cleanest configuration syntax.
vojfox 12y ago
How can this/these be exploited?
- whitten 12y ago
  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 12y ago
Is there any information whether the fix is in 3.18.1, which was released yesterday?
- amluto 12y ago
  CVE-2014-9090 and CVE-2014-9322 were fixed in 3.18, just before it was released.

256 points by jgeralnik 12y ago

0x0 12y ago

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)

dmix 12y ago

> 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 12y ago
> 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 12y ago
  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/15054 http://article.gmane.org/gmane.comp.security.oss.general/150... And you can see Greg K H (a linux core dev) snarky reply here: http://article.gmane.org/gmane.comp.security.oss.general/15056 http://article.gmane.org/gmane.comp.security.oss.general/150... 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
  - mburns 12y ago
    "I'm glad to help out with this if you can point me at specific examples of things that should be changed." Doesn't sound the least bit snarky. Submitting small patches isn't unreasonable, and GRSecurity-inclined people would do well to play nice with the kernel dev process.
    - deleted 12y ago
      [deleted]
    - someengineer 12y ago
      Totally agree. His reply is an overly polite response to a rather snarky rant on why the Linux devs should just shut up and accept the author's massive merge. Giant projects like the Linux kernel just don't work that way.
      - dmix 12y ago
        No one in that thread is recommending the Linux devs take the monolithic GRSecurity patches flat out. If you read the originally linked thread Daniel explains why it can't be accepted this way nor does he propose it should. Rather attempts to submit it in smaller patches have been met with disinterest. As well as the fact security in general has the appearance of being sidelined by the core developers - which has created a large disincentive for developers interested in getting GRSecurity upstreamed from even trying (again).
        nodata 12y ago
        Maybe the grsec people should better communicate the advantage. I suggest taking each CVE and listing whether it would have been mitigated by running a grsec kernel, and compare it to something else (selinux or whatever)
        dmix 12y ago
        If there is a kernel privilege escalation then SELinux can be disabled as Spender loves to demonstrate https://www.youtube.com/watch?v=WI0FXZUsLuI https://www.youtube.com/watch?v=WI0FXZUsLuI GRSec does includes it's own MAC system as an alternative to SELinux but that is only a small part. PaX/grsec is in a different class of mitigation. I don't really know any competitors besides other implementations of small subsets by different operating systems or hardware manufacturers. To your other point, I don't think anyone who has been following Linux security for any amount of time thinks that Spender or PaX are in need of proving themselves.
- alecco 12y ago
  Linus hates security and security related projects. He is against prioritizing security bugs over normal bugs. Also he is against embargo (coordinated release). One example of many, many instances: http://yarchive.net/comp/linux/security_bugs.html http://yarchive.net/comp/linux/security_bugs.html
  - api 12y ago
    I simultaneously agree and disagree with him. I think he's wrong because security is increasingly critical, but I agree with him because I can't stand (most of) the infosec profession. The vast majority of infosec gives zero thought to any concern other than security, resulting in systems that are insanely complex with incredibly poor user experience. Not only does this break everything else, but it's bad for security in the long run. The typical security solution is something that makes it so hard for people to do ordinary work that they either disable it entirely (e.g. SELinux) or work around it (tunneling through aggressive firewalls, etc.) and defeat the whole purpose. I worked in a research institution once where some departments had people whose informal job description (I was told) was to "help work around security so we can get our work done." If you worked with security, they'd put up so many road blocks and say "no" to so many things that months and months could go by without a single thing being accomplished. There was a whole culture of literally conspiring to ignore and sidestep the security department. People kept doing this even after we got hacked, arguing (again explicitly) that the cost of complying with infosec was greater than the cost of the hack. Infosec is largely a ghetto populated by people who only think about one thing, and who think that one thing is the sexist, coolest, most important thing in the entire world. There are other such ghettoes and they all suffer from similar sorts of problems. I firmly believe that almost nothing can be done well without whole system thinking. You have to look at the entire context of a system, not just the one thing you're building or optimizing. Think about the system from technical details all the way up to how users will interact with it on a day to day basis. A good starting point is to look at whatever you're building and ask "how annoyed would I be if management foisted this on me?" If the answer is "very annoyed," your system has horrible UX. This isn't the only case where I simultaneously agree and disagree with Linus. Another notable one is C vs C++. Short version: I think C++ is fine and makes it a lot easier to do many things, but anyone writing C++ should have YAGNI and KISS tattooed on their forehead. As with many other "powerful" multi-paradigm languages it takes discipline to avoid over-using the language's features, and most programmers unfortunately have the opposite tendency. They over-abstract and over-engineer as if they're trying to show how clever they are.
nchelluri 12y ago
I haven't really explored this but I remember a few years ago I liked the idea of using grsecurity on my VPSs. Unfortunately I couldn't come up with a good way to do it. I believe the idea I stumbled onto was to use kexec to load a hardened kernel after boot, which seems doable but I am not sure it would be a good route to go. Have you/anyone ever tried anything like this?
- elwin 12y ago
  Linode VPSs can boot custom kernels: https://www.linode.com/docs/tools-reference/custom-kernels-distros/run-a-custom-compiled-kernel-with-pvgrub https://www.linode.com/docs/tools-reference/custom-kernels-d... I don't know if this is possible with other providers.
  - voltagex_ 12y ago
    EC2: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UserProvidedKernels.html http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UserProvi... DO: http://0wned.it/2014/08/27/custom-kernel-on-a-digitalocean-droplet-the-right-way/ http://0wned.it/2014/08/27/custom-kernel-on-a-digitalocean-d... Rackspace: http://www.rackspace.com/knowledge_center/article/linux-kernel-management http://www.rackspace.com/knowledge_center/article/linux-kern...
mintplant 12y ago
Would anyone happen to know of grsecurity is compatible with the linux-ck patchset?
amluto 12y ago
I think that UDEREF works here, on brief inspection of the code. However I haven't looked too hard, but grsec seems to have its own bugs in this area. I'll email them. As usual, my nasty IRET test case is available [1], and, as of the embargo expiration (Monday), it contains tests for the whole pile of issues here, among others. Save your work before running it. [1] https://gitorious.org/linux-test-utils/linux-clock-tests/source/ https://gitorious.org/linux-test-utils/linux-clock-tests/sou...
- easytiger 12y ago
  FYI that link is 404
  - wglb 12y ago
    Perhaps this is the one? https://gitorious.org/linux-test-utils/linux-clock-tests/source/10b9a7d317f6d8ae5f32bcb4bbbb186acdd6b89a https://gitorious.org/linux-test-utils/linux-clock-tests/sou...:
    - easytiger 12y ago
      Thanks very useful, I was just writing something similar. INterested in: syscall32_from_64.c What's does that do? I know in IA32 emu mode on a 64bit kernel from running binaries using strace that they make gettimeofday etc syscalls rather than use vdso.
      - amluto 12y ago
        I think I wrote syscall32_from_64 to try to test something related to the 32-bit syscall (as opposed to sysenter or int80) handler in ia32entry.S. TBH, I don't remember exactly what it was for. On my Intel-based box, it gets SIGILL, but if I run it under QEMU without KVM, it says "syscall return = 137". The more interesting things in there include segregs (testing for an info leak that has no CVE yet), syscall_exit_regs_64 (run it under strace and watch it fail), and dump_all_pmcs. I'm hoping that dump_all_pmcs will stop working in Linux 3.20. Also, on new enough kernels with new enough glibc (I think), even 32-bit programs use vdso timing.
ema_ 12y ago
GRSecurity users have to actually upgrade their kernel anyways: > On those systems, assuming that the mitigation works correctly, the impact of this bug may be limited to massive memory corruption and an eventual crash or reboot
richwhiteguy 12y ago
GRSecurity is a bunch of weak, messy patches for an even weaker, messier kernel. Why not just install the most superior kernel of them all -- OpenBSD -- and not have to worry about these weekly Linux security advisories? When are people going to realize that, despite its contributions to open source, Linux is a complete and utter mess? Choose OpenBSD for your Unix needs. OpenBSD -- the world's simplest and most secure Unix-like OS. Creator of the world's most used SSH implementation OpenSSH, the world's most elegant firewall PF, the world's most elegant mail server OpenSMTPD, and the OpenSSL rewrite LibreSSL. OpenBSD -- the cleanest kernel, the cleanest userland and the cleanest configuration syntax.

vojfox 12y ago

How can this/these be exploited?

whitten 12y ago
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 12y ago

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

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