LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   [Slackware security] vulnerabilities outstanding 20140101 (https://www.linuxquestions.org/questions/slackware-14/%5Bslackware-security%5D-vulnerabilities-outstanding-20140101-a-4175489800/)

hpfeil 01-30-2014 03:22 PM

Perhaps I spoke too soon. Although I'm running pixman 32.2, doesn't mean that's the version in Slackware-Current.

http://lists.freedesktop.org/archive...er/003119.html

The Man! La Mancha rocks! Thanks for posting the updates. Building xorg from source is not a task for the faint of heart.

I said "faint of heart" because I fainted while reading this: http://www.x.org/wiki/Building_the_X_Window_System/

mancha 01-31-2014 05:36 AM

Update 20140131

This updates my curl advisory in post #1 of this thread.
  1. curl 7.35.0

    CVE-2014-0015 fixed
    CVE-2013-6422 fixed (since 7.34.0)
    CVE-2013-4545 fixed (since 7.33.0)
--mancha

BrZ 01-31-2014 12:43 PM

Hi mancha, a new serious kernel bug (CVE-2014-0038) affecting _all_ versions since 3.4. Second patch seems the correct and was merged here.

55020 01-31-2014 01:13 PM

AFAICT this is graded "Don't Panic". http://seclists.org/oss-sec/2014/q1/187 says it affects only x32 -- which is that weird hybrid 32-bit address space with AMD64 instructions that nobody uses. Especially not Slackware. The vuln goes back to 3.4, because 3.4 is when x32 was merged...

Edit: Wrong wrong wrong! :( see metaschima's post below.

metaschima 01-31-2014 01:20 PM

Quote:

Originally Posted by BrZ (Post 5108830)
Hi mancha, a new serious kernel bug (CVE-2014-0038) affecting _all_ versions since 3.4. Second patch seems the correct and was merged here.

I was just about to post this. It really does look serious and x32 is enabled in slackware64 kernels.

Luckily I have a custom kernel that is pure 64-bit.

EDIT:
It looks like slackware64 glibc is NOT built with x32 support. So I guess maybe it isn't so bad after all. The user would have to build glibc with x32 support and then run a compromised x32 program.

55020 01-31-2014 01:38 PM

Quote:

Originally Posted by metaschima (Post 5108852)
I was just about to post this. It really does look serious and x32 is enabled in slackware64 kernels.

Eek! Thanks! You're right: CONFIG_X86_X32=y
I hereby withdraw that "Don't Panic" grading. Sorry!

mancha 01-31-2014 02:08 PM

Quote:

Originally Posted by BrZ (Post 5108830)
Hi mancha, a new serious kernel bug (CVE-2014-0038) affecting _all_ versions since 3.4. Second patch seems the correct and was merged here.

Hi BrZ.

Thanks for raising visibility of this issue.

I confirm I am able to oops Slackware64 14.1's kernel (system is stock Slackware64-14.1):

Code:

[ 3625.853465] BUG: unable to handle kernel NULL pointer dereference at 0000000000000009
[ 3625.853465] IP: [<ffffffff81a73c1d>] __sys_recvmmsg+0x2d/0x260
[ 3625.853465] PGD b6d1067 PUD 4514067 PMD 0
[ 3625.853465] Oops: 0000 [#1] SMP

The fix applies successfully to Slackware 14.1's 3.10.17 kernel (with slight offset but that's OK).

This issue only affects 64-bit Slackware (14.1 and -current). 32-bit Slackware is unaffected.

ɐɥɔuɐɯ--

volkerdi 01-31-2014 03:35 PM

Quote:

Originally Posted by 55020 (Post 5108864)
Eek! Thanks! You're right: CONFIG_X86_X32=y
I hereby withdraw that "Don't Panic" grading. Sorry!

Ah, but CONFIG_X86_X32_ABI is not set. Apparently ld isn't handling x86_32 properly, so the kernel didn't enable that option. Accidentally not vulnerable. :)

Since I'm here, in cases like the pixman/X server trapazoid bug which can lead to a crash but not privilege escalation, I'm inclined to look at it as a bug rather than a security issue even though it was assigned a CVE. It's not in the same realm as something like the libXfont overflow.

mancha 01-31-2014 04:06 PM

Quote:

Originally Posted by volkerdi (Post 5108933)
Ah, but CONFIG_X86_X32_ABI is not set. Apparently ld isn't handling x86_32 properly, so the kernel didn't enable that option. Accidentally not vulnerable. :)

Hi Pat. I believe Slackware64 14.1 & current are vulnerable (see my oops in the post just above yours).

CONFIG_X86_X32_ABI is a compile-time option which is set after confirming ld can emulate elf32_x86_64.
You can check Slack's ld supported emulations with:

Code:

$ ld -V
The actual kernel test is something like this:

Code:

echo '1: .quad 1b' | gcc -c -xassembler -o blah - && objcopy -O elf32-x86-64 blah blah.o && ld -m elf32_x86_64 blah.o -o blah; echo $?
ɐɥɔuɐɯ--

mancha 01-31-2014 04:57 PM

Pat:

I won't be able to check this for the next few hours, but a quick double-check you can do is:

Code:

# cd /usr/src/linux-3.10.17
# make V=1

Let that run a bit and see if the option is being set (-DCONFIG_X86_X32_ABI).

--mancha

volkerdi 01-31-2014 06:08 PM

Quote:

Originally Posted by mancha (Post 5108965)

Let that run a bit and see if the option is being set (-DCONFIG_X86_X32_ABI).

--mancha

Ah, I see. It is there at compile time, but not in the .config.

Is there actually any interest in x86_x32? If the toolchain doesn't fully support it and nobody's using it for anything, perhaps the path of least resistance would be to turn off CONFIG_X86_X32 in the kernel entirely.

metaschima 01-31-2014 06:20 PM

Full use of x32 requires x32 glibc, gcc, gdb, and ld (binutils). If these are not provided (and they are not), then there is no reason to enable x32 in the kernel.
https://sites.google.com/site/x32abi/

The proof of concept by mancha doesn't use glibc, but rather assembly ... which is clever.

mancha 02-01-2014 04:43 AM

Quote:

Originally Posted by volkerdi (Post 5108997)
Is there actually any interest in x86_x32? If the toolchain doesn't fully support it and nobody's using it for anything, perhaps the path of least resistance would be to turn off CONFIG_X86_X32 in the kernel entirely.

The API never really took off so my hunch is very few, if any, will notice if you remove it. Then again, no one misses the water till the well runs dry.

Quote:

Originally Posted by volkerdi (Post 5108933)
Since I'm here, in cases like the pixman/X server trapazoid bug which can lead to a crash but not privilege escalation, I'm inclined to look at it as a bug rather than a security issue even though it was assigned a CVE.

The pixman vulnerability seems limited to denial of service. I'm not familiar with the EXA acceleration code in xorg-server so without code review I have no idea if there's potential to leverage the wraparound for things like code execution. To be honest I didn't dwell on it. X runs as root; the fix is trivial; why risk it?

ɐɥɔuɐɯ--

mancha 02-02-2014 09:57 PM

Update 20140202

ALERT: CVE-2014-0038 is no longer merely theoretical. A working Ubuntu exploit was made public by Rebel. I can confirm
the exploit methodology does work on Slackware64 14.1+.

Given the exposure, I authored a kernel module which protects against this attack and which I now share with the Slackware
community.

To get it working, as root do:

Code:

# tar xf nox32recvmmsg.tar.bz2
# cd nox32recvmmsg
# make
# insmod nox32recvmmsg.ko

--mancha

EDIT: The kernel module has undergone two revisions since the original post. See follow-up posts for more info.
Make sure the tarball you downloaded is the most recent. Compare to hash:

SHA256(nox32recvmmsg.tar.bz2)= 8c822d55a0a45f0fa994c73921701e2bb035bdaeb169c2355ed8d767414c4f73

mancha 02-03-2014 02:59 AM

I made a change to the kernel module. If you downloaded before this post, please download again and rebuild.

nox32recvmmsg.tar.bz2

S̶H̶A̶2̶5̶6̶(̶n̶o̶x̶3̶2̶r̶e̶c̶v̶m̶m̶s̶g̶.̶t̶a̶r̶.̶b̶z̶2̶)̶=̶ ̶a̶9̶7̶2̶e̶c̶3̶d̶c̶e̶a̶c̶b̶b̶5̶3̶b̶f̶d̶6̶4̶a̶f̶e̶f̶e̶0̶6̶d̶0̶e̶7̶a̶4̶8̶9̶e̶e̶5̶2̶6̶4̶b̶5̶9̶8̶a̶c̶1̶9 ̶2̶6̶6̶4̶d̶9̶f̶5̶c̶6̶e̶b̶c̶0̶

--mancha

EDIT: The module underwent one more modification after this post. Discard above hash. Latest version
should be compared to:

SHA256(nox32recvmmsg.tar.bz2)= 8c822d55a0a45f0fa994c73921701e2bb035bdaeb169c2355ed8d767414c4f73


All times are GMT -5. The time now is 12:21 PM.