7 ms·

Linux 3.4+: arbitrary write with CONFIG_X86_X32 (CVE-2014-0038)

94 points by akerl_ 13y ago

saintdev 13y ago
On the plus side, hardly anybody uses x32 ABI.
- akerl_ 13y ago
  Unfortunately, it looks like Ubuntu just recently enabled it in their kernels: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1274754 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1274754
  - vinkelhake 13y ago
    How do you get an x32 Ubuntu? I couldn't find it on the regular download page. I'm not surprised since it is a rather obscure configuration.
    - akerl_ 13y ago
      I don't run Ubuntu myself, but CONFIG_X86_X32 isn't a new architecture, it's an option for 64 bit kernels. Based on the state of that bug report, it looks like it's an option they've enabled in their recent 64 bit kernels (Quantal+)
      - ahomescu1 13y ago
        You need a completely different userland, compiled for x32 instead of amd64. Just running the default amd64 installation with a x32 kernel doesn't make it x32. EDIT: It would also work for just running x32 apps on an amd64 system, but then you only get the x32 benefits for those applications.
        mnw21cam 13y ago
        You don't need a whole x32 userland in order to be exploited. Just a single x32 binary executable that happens to not depend on on any external libraries.
        spendergrsec 13y ago
        You don't even need that. This can be done within a 64bit process using the x32 syscall number for recvmmsg. -Brad
        mnw21cam 13y ago
        Ouch.
        ahomescu1 13y ago
        I did't mean for an exploit, I just meant that you don't have any use for a x32 kernel on your system if you don't have x32 apps and libraries (unless you build a statically-linked x32 app).
        justincormack 13y ago
        People are finally getting around to experimenting now there is gcc support. You need an x32 libc too, but you can use a chroot environment.
        ahomescu1 13y ago
        I realized after writing my post that you don't really need an entire system, just the x32 libraries (and not even those if you statically link your x32 application).
  - eddiedunn 13y ago
    There is already a patch out for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1274349 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1274349
ye 13y ago
Am I the only one shocked by the lack of comments in the code? It's literally a wall of code.
- barrkel 13y ago
  How familiar are you with largish C codebases? At this level, you're dealing with an API at the calling end (you should be fairly intimately familiar with the semantics without much reference to the docs if you're working on the implementation) and the functions being calling are almost readable as English. Code should strive to be written such that it doesn't need comments unless it's being clever - and it should avoid being clever if possible. Also, I'm not sure where you saw a "wall of code". I don't see any walls of code, not in the commit diff, nor in the smaller diff in the email. A wall of code, for me, would have to be long (say, 70+ lines - but it depends on the language) and dense (e.g. boolean expressions complex enough to need parentheses to clarify precedence).
  - Raphael_Amiard 13y ago
    > How familiar are you with largish C codebases? Well I don't know, let's see some code for postgresql, a quite large C codebase. I took this file at random: https://github.com/postgres/postgres/blob/master/src/pl/plpgsql/src/pl_comp.c https://github.com/postgres/postgres/blob/master/src/pl/plpg... So assuming "what you know" means the same as "what is the best" is probably not a good idea.
  - crististm 13y ago
    That's an attitude of "stay the fuck out of my code - you're too stupid to understand it without comments". I've seen it too often in "large code bases" "you should be fairly intimately familiar with the semantics" - do you see a problem bootstrapping that on an obscure code base?
    - __david__ 13y ago
      > …do you see a problem bootstrapping that on an obscure code base? No, I don't. It just requires that you can read C and understand it. Any large codebase (in whatever language) is going to require you to understand certain semantics and idioms, and it doesn't make any sense to document those idioms every single place you use them. Big codebases require context and a comment in some random function isn't going to give you enough context unless it was a tome. Also, did you see the 2 patches linked in the bug report? They significantly changed the code. C is just like that. It's an environment ripe for comment bitrot. And the only thing worse than no comments is incorrect comments. In the end, the code is what matters. If you can read it, you can understand it.
barrkel 13y ago
This might be useful context: http://en.wikipedia.org/wiki/X32_ABI http://en.wikipedia.org/wiki/X32_ABI an application binary interface project for Linux that allows programs to take advantage of the benefits of x86-64 (larger number of CPU registers, better floating-point performance, ... ) while using 32-bit pointers and thus avoiding the overhead of 64-bit pointers
- userbinator 13y ago
  So in other words, it's a 32-bit address space in 64-bit mode? I thought that wasn't possible with x86-64... in fact the biggest mistake I think with x86-64, after some(admittedly not much) reading of the manuals is that it wasn't like the 16/32-bit where you could independently choose the default operand and address sizes, and use 32-bit addresses or registers in 16-bit mode and vice-versa.
  - nknighthb 13y ago
    Not sure what you were reading, but to the best of my knowledge, long mode retains almost all of the 32-bit instructions, only a relative handful were ripped out. Code running in 32-bit protected mode can't access 64-bit instructions or registers, of course, but that's a different issue. x32 is basically just long mode code that limits itself to instructions that use 32-bit addresses.
    - pbsd 13y ago
      You can jump between 32-bit and 64-bit modes in a 64-bit Windows and Linux by switching between the 0x23 and 0x33 code segments. Like so: BITS 32 start: call far 0x33:code64 code32: nop ; resume code64: BITS 64 xor rax, rax BITS 32 retf ; return to 0x23:code32
      - 0x0 13y ago
        That's interesting that the CS values are the same in windows and linux, more than a coincidence... Is this part of some x86_64 ABI spec?
jjjeffrey 13y ago
At the bottom there are two lines that taken together really confuse me: <grsecurity> If you're running Linux 3.4 or newer and enabled CONFIG_X86_X32 , you need to disable it or update immediately; upstream vuln CVE-2014-0038 and <grsecurity> In case there's confusion, this vuln is not about 32bit userland on 64bit (CONFIG_X86_32), but the new X32 ABI. Ubuntu enables it recently Does the second line affect the first? EDIT: I ask because it looks like I need to fix my kernel, but I'd rather be lazy if possible.
- harshreality 13y ago
  x32 is a separate abi, distinct from the normal 64-bit and 32-bit abis. Most distros don't use it, most don't even offer an x32 install image, but if they enable the kernel option for the x32 abi even without intending to use it, they're vulnerable. If you're using the x32 abi, either you're using it on purpose, or your distro happens to offer an x32 install image and you downloaded it by accident instead of the normal 32-bit image you probably wanted. In all other cases it should be safe enough to disable the kernel option.
- elwin 13y ago
  CONFIG_X86_X32 and CONFIG_X86_32 are different. The first one, with the second X, enables the new X32 ABI. The second one, without the second X, is the "32bit userland on 64bit".
- lambda 13y ago
  Does "grep CONFIG_X86_X32 /boot/config-`uname -r`" give you any results which aren't commented out? If it does, you're at risk; if not, nothing to worry about (at least, with regards to this vulnerability).
akerl_ 13y ago
Has anyone seen talk of this leading to an expedited 3.13.2/3.12.10 release? If I need to manually patch my kernels to fix this, I'll do it, but if upstream is going to release fixed versions shortly, that seems like the preferable solution. So far though, I haven't seen anything about merging in the patch provided by PaX.
- nknighthb 13y ago
  Are you actually using x32? I doubt most people are. It didn't even exist in a stable kernel until April 2012.
  - akerl_ 13y ago
    I am not actively using it, but I am running kernels that have CONFIG_X86_X32 enabled.
    - nknighthb 13y ago
      Yeah, I just saw that Ubuntu at least already enabled it quite a while ago. Ouch.
      - akerl_ 13y ago
        I don't suppose there's some way to disable x32 from within a running system that's not using it? edit: It doesn't appear there is. Not shocking, but I was hoping for a bit of luck.
        nknighthb 13y ago
        As far as I know, no. I'm about 90% sure you have to rebuild the kernel to disable it. That said, I've only read about it, not played with it, and I don't have a box with it enabled at my fingertips. That said, this is a local exploit, so unless you have untrusted users or otherwise run untrusted native code, your risk is pretty low. Someone would have to exploit something else first to get access to run custom code on the box.
jlgaddis 13y ago
While we sometimes get laughed at for not running the latest and greatest, I am (once again) quite glad that I'm running RHEL 5 and 6 and their 2.6.18 and 2.6.32 kernels.
- sspiff 13y ago
  I'm not sure you noticed, but this doesn't affect any popular distro. It only affects the kernels build with the X32 ABI, which is not used in production by anyone as far as I can tell. So the fact that you're running old kernels didn't prevent anything this time.
- sspiff 13y ago
  I'm not sure you noticed, but this doesn't affect any popular distro. It only affects the kernels build with the X32 ABI, which is not used in production by anyone as far as I can tell. So the fact that you're running old kernels didn't prevent anything this time.
- jasonzemos 13y ago
  Those are patched against the myriad of bugs and vulnerabilities from the last 8 years... haha?
  - zorked 13y ago
    As long as he's upgrading, yes they are, Red Hat fully supports those kernels.
lelf 13y ago
- if (get_compat_timespec(&ktspec, timeout)) + if (compat_get_timespec(&ktspec, timeout)) return -EFAULT; Sigh

94 points by akerl_ 13y ago

saintdev 13y ago

On the plus side, hardly anybody uses x32 ABI.

akerl_ 13y ago
Unfortunately, it looks like Ubuntu just recently enabled it in their kernels: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1274754 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1274754
- vinkelhake 13y ago
  How do you get an x32 Ubuntu? I couldn't find it on the regular download page. I'm not surprised since it is a rather obscure configuration.
  - akerl_ 13y ago
    I don't run Ubuntu myself, but CONFIG_X86_X32 isn't a new architecture, it's an option for 64 bit kernels. Based on the state of that bug report, it looks like it's an option they've enabled in their recent 64 bit kernels (Quantal+)
    - ahomescu1 13y ago
      You need a completely different userland, compiled for x32 instead of amd64. Just running the default amd64 installation with a x32 kernel doesn't make it x32. EDIT: It would also work for just running x32 apps on an amd64 system, but then you only get the x32 benefits for those applications.
      - mnw21cam 13y ago
        You don't need a whole x32 userland in order to be exploited. Just a single x32 binary executable that happens to not depend on on any external libraries.
        spendergrsec 13y ago
        You don't even need that. This can be done within a 64bit process using the x32 syscall number for recvmmsg. -Brad
        mnw21cam 13y ago
        Ouch.
        ahomescu1 13y ago
        I did't mean for an exploit, I just meant that you don't have any use for a x32 kernel on your system if you don't have x32 apps and libraries (unless you build a statically-linked x32 app).
      - justincormack 13y ago
        People are finally getting around to experimenting now there is gcc support. You need an x32 libc too, but you can use a chroot environment.
        ahomescu1 13y ago
        I realized after writing my post that you don't really need an entire system, just the x32 libraries (and not even those if you statically link your x32 application).
- eddiedunn 13y ago
  There is already a patch out for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1274349 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1274349

ye 13y ago

Am I the only one shocked by the lack of comments in the code? It's literally a wall of code.

barrkel 13y ago
How familiar are you with largish C codebases? At this level, you're dealing with an API at the calling end (you should be fairly intimately familiar with the semantics without much reference to the docs if you're working on the implementation) and the functions being calling are almost readable as English. Code should strive to be written such that it doesn't need comments unless it's being clever - and it should avoid being clever if possible. Also, I'm not sure where you saw a "wall of code". I don't see any walls of code, not in the commit diff, nor in the smaller diff in the email. A wall of code, for me, would have to be long (say, 70+ lines - but it depends on the language) and dense (e.g. boolean expressions complex enough to need parentheses to clarify precedence).
- Raphael_Amiard 13y ago
  > How familiar are you with largish C codebases? Well I don't know, let's see some code for postgresql, a quite large C codebase. I took this file at random: https://github.com/postgres/postgres/blob/master/src/pl/plpgsql/src/pl_comp.c https://github.com/postgres/postgres/blob/master/src/pl/plpg... So assuming "what you know" means the same as "what is the best" is probably not a good idea.
- crististm 13y ago
  That's an attitude of "stay the fuck out of my code - you're too stupid to understand it without comments". I've seen it too often in "large code bases" "you should be fairly intimately familiar with the semantics" - do you see a problem bootstrapping that on an obscure code base?
  - __david__ 13y ago
    > …do you see a problem bootstrapping that on an obscure code base? No, I don't. It just requires that you can read C and understand it. Any large codebase (in whatever language) is going to require you to understand certain semantics and idioms, and it doesn't make any sense to document those idioms every single place you use them. Big codebases require context and a comment in some random function isn't going to give you enough context unless it was a tome. Also, did you see the 2 patches linked in the bug report? They significantly changed the code. C is just like that. It's an environment ripe for comment bitrot. And the only thing worse than no comments is incorrect comments. In the end, the code is what matters. If you can read it, you can understand it.

barrkel 13y ago

This might be useful context: http://en.wikipedia.org/wiki/X32_ABI http://en.wikipedia.org/wiki/X32_ABI an application binary interface project for Linux that allows programs to take advantage of the benefits of x86-64 (larger number of CPU registers, better floating-point performance, ... ) while using 32-bit pointers and thus avoiding the overhead of 64-bit pointers

userbinator 13y ago
So in other words, it's a 32-bit address space in 64-bit mode? I thought that wasn't possible with x86-64... in fact the biggest mistake I think with x86-64, after some(admittedly not much) reading of the manuals is that it wasn't like the 16/32-bit where you could independently choose the default operand and address sizes, and use 32-bit addresses or registers in 16-bit mode and vice-versa.
- nknighthb 13y ago
  Not sure what you were reading, but to the best of my knowledge, long mode retains almost all of the 32-bit instructions, only a relative handful were ripped out. Code running in 32-bit protected mode can't access 64-bit instructions or registers, of course, but that's a different issue. x32 is basically just long mode code that limits itself to instructions that use 32-bit addresses.
  - pbsd 13y ago
    You can jump between 32-bit and 64-bit modes in a 64-bit Windows and Linux by switching between the 0x23 and 0x33 code segments. Like so: BITS 32 start: call far 0x33:code64 code32: nop ; resume code64: BITS 64 xor rax, rax BITS 32 retf ; return to 0x23:code32
    - 0x0 13y ago
      That's interesting that the CS values are the same in windows and linux, more than a coincidence... Is this part of some x86_64 ABI spec?

jjjeffrey 13y ago

At the bottom there are two lines that taken together really confuse me: <grsecurity> If you're running Linux 3.4 or newer and enabled CONFIG_X86_X32 , you need to disable it or update immediately; upstream vuln CVE-2014-0038 and <grsecurity> In case there's confusion, this vuln is not about 32bit userland on 64bit (CONFIG_X86_32), but the new X32 ABI. Ubuntu enables it recently Does the second line affect the first? EDIT: I ask because it looks like I need to fix my kernel, but I'd rather be lazy if possible.

harshreality 13y ago
x32 is a separate abi, distinct from the normal 64-bit and 32-bit abis. Most distros don't use it, most don't even offer an x32 install image, but if they enable the kernel option for the x32 abi even without intending to use it, they're vulnerable. If you're using the x32 abi, either you're using it on purpose, or your distro happens to offer an x32 install image and you downloaded it by accident instead of the normal 32-bit image you probably wanted. In all other cases it should be safe enough to disable the kernel option.
elwin 13y ago
CONFIG_X86_X32 and CONFIG_X86_32 are different. The first one, with the second X, enables the new X32 ABI. The second one, without the second X, is the "32bit userland on 64bit".
lambda 13y ago
Does "grep CONFIG_X86_X32 /boot/config-`uname -r`" give you any results which aren't commented out? If it does, you're at risk; if not, nothing to worry about (at least, with regards to this vulnerability).

akerl_ 13y ago

Has anyone seen talk of this leading to an expedited 3.13.2/3.12.10 release? If I need to manually patch my kernels to fix this, I'll do it, but if upstream is going to release fixed versions shortly, that seems like the preferable solution. So far though, I haven't seen anything about merging in the patch provided by PaX.

nknighthb 13y ago
Are you actually using x32? I doubt most people are. It didn't even exist in a stable kernel until April 2012.
- akerl_ 13y ago
  I am not actively using it, but I am running kernels that have CONFIG_X86_X32 enabled.
  - nknighthb 13y ago
    Yeah, I just saw that Ubuntu at least already enabled it quite a while ago. Ouch.
    - akerl_ 13y ago
      I don't suppose there's some way to disable x32 from within a running system that's not using it? edit: It doesn't appear there is. Not shocking, but I was hoping for a bit of luck.
      - nknighthb 13y ago
        As far as I know, no. I'm about 90% sure you have to rebuild the kernel to disable it. That said, I've only read about it, not played with it, and I don't have a box with it enabled at my fingertips. That said, this is a local exploit, so unless you have untrusted users or otherwise run untrusted native code, your risk is pretty low. Someone would have to exploit something else first to get access to run custom code on the box.

jlgaddis 13y ago

While we sometimes get laughed at for not running the latest and greatest, I am (once again) quite glad that I'm running RHEL 5 and 6 and their 2.6.18 and 2.6.32 kernels.

sspiff 13y ago
I'm not sure you noticed, but this doesn't affect any popular distro. It only affects the kernels build with the X32 ABI, which is not used in production by anyone as far as I can tell. So the fact that you're running old kernels didn't prevent anything this time.
sspiff 13y ago
I'm not sure you noticed, but this doesn't affect any popular distro. It only affects the kernels build with the X32 ABI, which is not used in production by anyone as far as I can tell. So the fact that you're running old kernels didn't prevent anything this time.
jasonzemos 13y ago
Those are patched against the myriad of bugs and vulnerabilities from the last 8 years... haha?
- zorked 13y ago
  As long as he's upgrading, yes they are, Red Hat fully supports those kernels.

lelf 13y ago

- if (get_compat_timespec(&ktspec, timeout)) + if (compat_get_timespec(&ktspec, timeout)) return -EFAULT; Sigh