Bug in Linux x32 could allow privilege escallation

[mike acker]

Bug in Linux x32 application binary interface could allow an attacker to escalate privileges

what's up ?????

see
http://www.zdnet.com/low-level-exploit- ... 000025872/

security first, last and always -- just like in the Army!! NO concessions to convenience, --EVER!!

~~~~~

=" Users can test if they are vulnerable by checking if the CONFIG_X86_X32 variable is set in their kernel configuration. "

so how do we check and correct this setting ?

[kurotsugi]

extract the content of /proc/config.gz, open it and see the line contain 'x32'. unfortunately we need to compile a custom kernel to fix it.

[xenopeek]

The command to check it with on main editions of Linux Mint is:

Code: Select all

grep CONFIG_X86_X32 /boot/config-$(uname -r)

Linux Mint 14 is unaffected; it returns # CONFIG_X86_X32 is not set. Linux Mint 16 however returns CONFIG_X86_X32=y, so Ubuntu 13.10's kernel (as used also on Linux Mint 16) is susceptible to this privilege escalation attack.

The fix is in kernel 3.11.0-15.25, but please note there is a report that it breaks a specific program (remmina) and this kernel fix may possibly break more (the remmina breakage is unconfirmed though): https://bugs.launchpad.net/ubuntu/+sour ... comments/5.

See karlchen's excellent post here on how to get Ubuntu kernel upgrades on Linux Mint 16: http://forums.linuxmint.com/viewtopic.p ... 61#p795316. Follow that if you want to install 3.11.0-15.25.

Edit: I see there is an exploit template available for this, so heading it up to Clem to possibly consider pushing the new kernel.

[mike acker]

mine is MINT 15, with Kernel/Build 3.8.0-19

Code: Select all

 ~ $ grep CONFIG_X86_X32 /boot/config-$(uname -r)
CONFIG_X86_X32=y
 ~ $ 

this is shocking. privilege escallation exceptions to favor an app program reek of msft
and look at the trouble that has got them

hopefully we'll see a correction shortly
in the mean time I'll check into the suggested kernel update

[Zalbor]

See karlchen's excellent post here on how to get Ubuntu kernel upgrades on Linux Mint 16: http://forums.linuxmint.com/viewtopic.p ... 61#p795316. Follow that if you want to install 3.11.0-15.25.

Something seems to be wrong with the dependencies. Installing linux-generic wants to remove grub and install a lot of other things, including brasero and apache. My "treat recommended packages as dependencies" isn't checked, by the way.
EDIT: No, something's wrong with Synaptic. I uncheck that box and restart Synaptic and then the box is back on.
EDIT 2: Never mind. Apparently it was the suggested packages thing which I'd turned on with Muon and forgot to turn off again. Although Synaptic really has the problem described above.

[Zalbor]

This deserves a new post.

The fix is in kernel 3.11.0-15.25

It doesn't seem to be. According to Synaptic, that's exactly the version number of the latest kernel from Ubuntu. But still:

Code: Select all

$ grep CONFIG_X86_X32 /boot/config-3.11.0-15-generic 
CONFIG_X86_X32=y

[mike acker]

{snip}

Edit: I see there is an exploit template available for this, so heading it up to Clem to possibly consider pushing the new kernel.

alrighty, then!! please let us know if that's going to happen, or if we should consider moving to MINT 17.

[xenopeek]

mine is MINT 15, with Kernel/Build 3.8.0-19
[...]
hopefully we'll see a correction shortly

I doubt it; Linux Mint 15--and Ubuntu 13.04 that is its package base--is obsolete as of end of January and thus no longer gets security updates. Ubuntu is unlikely to patch the Ubuntu 13.04 kernel. You could install a patched kernel yourself, or upgrade to Linux Mint 16 and get the patch there. Linux Mint 17 won't be out till May/June this year.

The fix is in kernel 3.11.0-15.25

It doesn't seem to be. According to Synaptic, that's exactly the version number of the latest kernel from Ubuntu. But still:

Code: Select all

$ grep CONFIG_X86_X32 /boot/config-3.11.0-15-generic
CONFIG_X86_X32=y

Are you sure you have 3.11.0-15.25? You can check your version with:

Code: Select all

dpkg -l linux-image-$(uname -r)

[chemicalfan]

If this is really that bad, couldn't a "custom compiled" kernel without that switch be put into Mint's repo temporarily? It'd be superseeded by a future Ubuntu version when they patch it (even if APT can't work it out, at that point it could be pulled from Mint's repo)

[Zalbor]

Are you sure you have 3.11.0-15.25? You can check your version with:

Code: Select all

dpkg -l linux-image-$(uname -r)

Yes, that shows 3.11.0-15.25, just like Synaptic does.

[mike acker]

mine is MINT 15, with Kernel/Build 3.8.0-19
[...]
hopefully we'll see a correction shortly

I doubt it; Linux Mint 15--and Ubuntu 13.04 that is its package base--is obsolete as of end of January and thus no longer gets security updates. Ubuntu is unlikely to patch the Ubuntu 13.04 kernel. You could install a patched kernel yourself, or upgrade to Linux Mint 16 and get the patch there. Linux Mint 17 won't be out till May/June this year.

{snip}

from the ZD Report

The x32 ABI essentially allows 32-bit applications to take advantage of 64-bit x86 architectures.
http://www.zdnet.com/low-level-exploit- ... 000025872/

our biggest concern is a "drive by" from an infected web site . infected web sites contain un-imaginable garbage..... a bad flash object would be the most likey means of getting some sort of code to call this ABI service... i wonder how high the risk is....... right now I'm looking at options one of which is to start playing with the Debian based MINT. I'm thinking whether to order one of those Western Digital dives from NewEgg or maybe reformat the drive I have Ubuntu 12.04LTS on. I was planning to upgrade to the MINT17 LTS version when it appears. I've been on MINT 15 since Sept. of last year....

http://www.newegg.com/Product/Product.a ... 3UN18A2401 yum, Disk No.4

I've only been on Ubuntu since Oct.2012 and MINT since Sept.2013 ....still I think I'm "getting it" to the point where I might like Debian...

[chemicalfan]

Just thought - you'll still see "CONFIG_X86_X32=y", but that part of the kernel has been patched, such that it is no longer vunerable. "CONFIG_X86_X32=y" refers to the functionality, not the vunerability.

[xenopeek]

Just thought - you'll still see "CONFIG_X86_X32=y", but that part of the kernel has been patched, such that it is no longer vunerable. "CONFIG_X86_X32=y" refers to the functionality, not the vunerability.

Correct, the test on earlier kernel versions is just to see if the functionality is included or not--not to confirm whether the patch has been applied. Kernel 3.11.0-15.25 has the patch for this security issue, but otherwise keeps the functionality enabled. If the functionality isn't enabled, such as on Linux Mint 14, you're not affected by this security issue.

[xenopeek]

our biggest concern is a "drive by" from an infected web site . infected web sites contain un-imaginable garbage..... a bad flash object would be the most likey means of getting some sort of code to call this ABI service... i wonder how high the risk is.......

I've been reading some more on X32 ABI today and I think the risk on your browser is negligible. For a browser to use X32 ABI, it would have had to been compiled to use the X32 version of system libraries (else there is no X32 ABI ). Those libraries aren't installed on Linux Mint 16. You can check with following command (no result = not installed):

Code: Select all

dpkg -l | egrep 'libx32|-x32'

You can also check whether your browser (or another program) has been compiled to use X32 ABI. You can do that with the ldd command and checking the output for reference to any X32 version of system libraries. For example for Firefox with this command (no result = Firefox wasn't compiled to use X32 ABI):

Code: Select all

ldd /usr/lib/firefox/firefox | egrep 'libx32|-x32'

This command is a bit tricky and you need to be sure to run it on the binary for the program you're checking. For example the command in your menu for Firefox points to a symbolic link, which goes to a shell script, that does the actual loading of the binary that you'd need to check (as per above command, that's the right one to check). So it can be a bit of a puzzle which file to check.

To my understanding the risk is in downloading a Linux program that was specially crafted to exploit the privilege escalation weakness that is in the X32 ABI in certain kernels. Like detailed above, some kernels don't have X32 ABI enabled and those aren't susceptible. I'm not a security expert, but I doubt things like Flash and JavaScript can exploit this bug in the X32 ABI.

[daveinuk]

This stuff goes over my head, can we have a bite size chunk explanation as to what this means in reality for us lesser mortals?

If I sit here and not worry about it, as I intend to do 'cos I don't understand the problem, will a fix come down the tubes at some point or do I need to tinker as I'm currently on mint 16 on my laptop . . . . . . .

[mike acker]

I'm not a security expert, but I doubt things like Flash and JavaScript can exploit this bug in the X32 ABI.

the thing that has been a problem with flash is that it has been a vehicle by which hackers have been able to get code execution. If that happens, then if the X32 ABI service is available then the un-authorized code, running under the authority of the browser, might be able to link to the X32 ABI and obtain privilege escallation
that's my concern, anyway

I think Java runtime has been more of a problem that java script,-- AFAIK java script is rather limited in its capability,-- supposedly just feeding html into the browser. I tried to research more on the full capabilities of java script but didn't come to a satisfactory conclusion

java runtime is another matter-- AFAIK more like an actual programmers' language running. i think it runs what they call 'byte code' -- a pseudo machine language. which would be the reason it is generally recommended to have that disabled in the browser.

the existence of the x32/abi is worrysome. an o/s which allows itself to be modified by an application program is a toy. a secure o/s would never countenance such an idea.

does Torvalds know about this? we would all be learning how to cuss in Finnish

[kurotsugi]

the existence of the x32/abi is worrysome. an o/s which allows itself to be modified by an application program is a toy. a secure o/s would never countenance such an idea.

does Torvalds know about this? we would all be learning how to cuss in Finnish

the kernel config means that "it increase the risk of security breach in your system". it doesn't mean that "your system will suddenly breached if you have this kernel config".

I've been reading some more on X32 ABI today and I think the risk on your browser is negligible. For a browser to use X32 ABI, it would have had to been compiled to use the X32 version of system libraries (else there is no X32 ABI ).
...
To my understanding the risk is in downloading a Linux program that was specially crafted to exploit the privilege escalation weakness that is in the X32 ABI in certain kernels. Like detailed above, some kernels don't have X32 ABI enabled and those aren't susceptible. I'm not a security expert, but I doubt things like Flash and JavaScript can exploit this bug in the X32 ABI.

as for the kernel, they already make a patch for it on 31 jan 2014. kernel released after this date will certainly have been patched.

[killer de bug]

the existence of the x32/abi is worrysome. an o/s which allows itself to be modified by an application program is a toy. a secure o/s would never countenance such an idea.

does Torvalds know about this? we would all be learning how to cuss in Finnish

1) Every OS has security breaches. Important is only the delay between discovery and patches.
2) Linux is perfectly aware of this, since the kernel has already been patched.

[mike acker]

alas, as a Mint15 system I'm an orphan. I'll have to wait for MINT17 or jump ship and go Debian.

I think it should be noted RedHat rejected the x32/ABI as a security risk:

Red Hat has previously been paged by its users to enable x32 support in Fedora 18; however, it refused to include it, citing security concerns.

"It affects every user by potentially exposing them to as-yet-unfound security bugs for zero gain," Red Hat kernel developer Dave Jones said at the time.

reference
http://www.zdnet.com/low-level-exploit- ... 000025872/

as I had noted elsewhere: making security concessions for app developers is a bad way to go.

[chemicalfan]

alas, as a Mint15 system I'm an orphan. I'll have to wait for MINT17 or jump ship and go Debian.

....or compile your own kernel without that option, if it bothers you that much.

What do you get from:

Code: Select all

dpkg -l linux-image-$(uname -r)

If it's 3.11.0-15.25 or higher, you don't need to do anything, the patch is already in there