LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 01-30-2014, 03:22 PM   #31
hpfeil
Member
 
Registered: Nov 2010
Location: Tucson, Arizona US
Distribution: Slackware Current
Posts: 352
Blog Entries: 1

Rep: Reputation: Disabled

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/

Last edited by hpfeil; 01-30-2014 at 03:48 PM. Reason: elucidation
 
Old 01-31-2014, 05:36 AM   #32
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
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
 
3 members found this post helpful.
Old 01-31-2014, 12:43 PM   #33
BrZ
Member
 
Registered: Apr 2009
Distribution: Slackware
Posts: 543

Rep: Reputation: 121Reputation: 121
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.
 
2 members found this post helpful.
Old 01-31-2014, 01:13 PM   #34
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,307
Blog Entries: 4

Rep: Reputation: Disabled
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.

Last edited by 55020; 01-31-2014 at 01:51 PM. Reason: Fessed up to wrongness, and added strikethrough ;-)
 
1 members found this post helpful.
Old 01-31-2014, 01:20 PM   #35
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,982

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
Quote:
Originally Posted by BrZ View Post
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.

Last edited by metaschima; 01-31-2014 at 01:27 PM.
 
1 members found this post helpful.
Old 01-31-2014, 01:38 PM   #36
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,307
Blog Entries: 4

Rep: Reputation: Disabled
Quote:
Originally Posted by metaschima View Post
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!
 
Old 01-31-2014, 02:08 PM   #37
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by BrZ View Post
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ɐɯ--

Last edited by mancha; 01-31-2014 at 03:07 PM.
 
1 members found this post helpful.
Old 01-31-2014, 03:35 PM   #38
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 2,454

Rep: Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347
Quote:
Originally Posted by 55020 View Post
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.
 
5 members found this post helpful.
Old 01-31-2014, 04:06 PM   #39
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by volkerdi View Post
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ɐɯ--

Last edited by mancha; 02-01-2014 at 08:40 AM. Reason: tidy up sample command list
 
2 members found this post helpful.
Old 01-31-2014, 04:57 PM   #40
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
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

Last edited by mancha; 01-31-2014 at 05:10 PM.
 
Old 01-31-2014, 06:08 PM   #41
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 2,454

Rep: Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347
Quote:
Originally Posted by mancha View Post

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.
 
Old 01-31-2014, 06:20 PM   #42
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,982

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
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.
 
Old 02-01-2014, 04:43 AM   #43
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by volkerdi View Post
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 View Post
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ɐɯ--

Last edited by mancha; 02-01-2014 at 05:44 AM.
 
Old 02-02-2014, 09:57 PM   #44
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
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

Last edited by mancha; 02-04-2014 at 02:47 PM. Reason: Mention module update and remove poc link
 
3 members found this post helpful.
Old 02-03-2014, 02:59 AM   #45
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
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

Last edited by mancha; 02-04-2014 at 02:15 PM. Reason: Mention module update.
 
1 members found this post helpful.
  


Reply

Tags
exploit, security, slackware


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[Slackware Security]: Some pending vulnerabilities... mancha Slackware 7 08-22-2013 09:08 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 09:10 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration