Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 399243 (CVE-2012-0056) - Kernel: proc: clean up and fix /proc/<pid>/mem handling (CVE-2012-0056)
Summary: Kernel: proc: clean up and fix /proc/<pid>/mem handling (CVE-2012-0056)
Status: RESOLVED OBSOLETE
Alias: CVE-2012-0056
Product: Gentoo Security
Classification: Unclassified
Component: Kernel (show other bugs)
Hardware: All Linux
: Normal critical
Assignee: Gentoo Kernel Security
URL: http://git.kernel.org/linus/e268337df...
Whiteboard:
Keywords:
: 399865 400571 400579 400581 400651 (view as bug list)
Depends on: 400671
Blocks:
  Show dependency tree
 
Reported: 2012-01-18 03:42 UTC by Viorel Tabara
Modified: 2018-04-04 18:05 UTC (History)
20 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
proc-mem-handling patch for 2.6.39-gentoo-r3 kernel (backport-proc-mem-handling-fix-2.6.39.patch,4.76 KB, patch)
2012-01-25 09:49 UTC, werner maier
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Viorel Tabara 2012-01-18 03:42:12 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=782642

From Linus' patch:
"Jüri Aedla reported that the /proc/<pid>/mem handling really isn't very
robust, and it also doesn't match the permission checking of any of the other
related files.

This changes it to do the permission checks at open time, and instead of
tracking the process, it tracks the VM at the time of the open.  That
simplifies the code a lot, but does mean that if you hold the file descriptor
open over an execve(), you'll continue to read from the old VM.

That is different from our previous behavior, but much simpler.  If somebody
actually finds a load where this matters, we'll need to revert this commit.

I suspect that nobody will ever notice - because the process mapping addresses
will also have changed as part of the execve.  So you cannot actually usefully
access the fd across a VM change simply because all the offsets for IO would
have changed too."

Upstream commit:
http://git.kernel.org/linus/e268337dfe26dfc7efd422a804dbb27977a3cccc


Reproducible: Always
Comment 1 Michael Harrison 2012-01-23 10:06:39 UTC
Proof of Concept link:
http://blog.zx2c4.com/749
Comment 2 Alex Legler (RETIRED) archtester gentoo-dev Security 2012-01-23 17:59:08 UTC
*** Bug 399865 has been marked as a duplicate of this bug. ***
Comment 3 Delete ME 2012-01-23 18:10:23 UTC
- use the following to check if your Hardened Gentoo is affected or not
- http://grsecurity.net/~spender/correct_proc_mem_reproducer.c
- i don't know which specific GRSEC Kernel option can stop this on a hardened system but mine is not vulnerable according to the above check
Comment 4 cyberbat 2012-01-23 19:01:07 UTC
(In reply to comment #0)
> 
> Upstream commit:
> http://git.kernel.org/linus/e268337dfe26dfc7efd422a804dbb27977a3cccc
> 
> Reproducible: Always

Have applied this patch to gentoo-sources-3.1.6. System is running ok and bug seems to go away.
Comment 5 Mike Pagano gentoo-dev 2012-01-23 21:51:10 UTC
This patch is now included in the following gentoo kernels:

gentoo-sources-3.2.1-r1
gentoo-sources-3.1.10
gentoo-sources-3.0.17-r1
Comment 6 cyberbat 2012-01-24 06:56:49 UTC
(In reply to comment #5)
> This patch is now included in the following gentoo kernels:
> 
> gentoo-sources-3.2.1-r1
> gentoo-sources-3.1.10
> gentoo-sources-3.0.17-r1

Mike, as for gentoo user it's interesting for me whether these unaffected kernel versions will be security stabilized soon. And also about hardened-sources. Or it better to apply patch manually?

I'm asking because fix for this patch is in ubuntu stable updates for example.
Comment 7 Thomas Rausch 2012-01-24 09:43:11 UTC
Is there a patch for the 2.3.39 kernel?
Comment 8 Oliver Oberst 2012-01-24 10:33:55 UTC
(In reply to comment #5)
> This patch is now included in the following gentoo kernels:
> 
> gentoo-sources-3.2.1-r1
> gentoo-sources-3.1.10
> gentoo-sources-3.0.17-r1

Hi,

I emerged gentoo-sources-3.2.1-r1:
>>> Unpacking genpatches-3.2-4.extras.tar.bz2 to /var/tmp/portage/sys-kernel/gentoo-sources-3.2.1-r1/work/patches
 * Applying 1000_linux-3.2.1.patch (-p0+) ...                                                                                                         [ ok ]
 * Applying 2100_proc-mem-handling-fix.patch (-p0+) ...                                                                                               [ ok ]

However, it seems like the patch is not applied somehow:
#>diff linux-3.2.0-gentoo/fs/proc/base.c linux-3.2.1-gentoo-r1/fs/proc/base.c 
#>

I had to apply it manually.
Comment 9 Manuel 2012-01-24 10:50:46 UTC
Hi Mike, Hi all,

(In reply to comment 8)
>  * Applying 2100_proc-mem-handling-fix.patch (-p0+) ...                        
>                                                                       [ ok ]
> 
> However, it seems like the patch is not applied somehow:
> #>diff linux-3.2.0-gentoo/fs/proc/base.c linux-3.2.1-gentoo-r1/fs/proc/base.c 
> #>
> 
> I had to apply it manually.
It seems that 2100_proc-mem-handling-fix.patch is only a patch of a patch and thus it fails. It just creates b/queue-3.2/proc-clean-up-and-fix-proc-pid-mem-handling.patch within the kernel source directory. Mike, could you please fix that?

Cheers,
  Manuel
Comment 10 Alex Legler (RETIRED) archtester gentoo-dev Security 2012-01-24 11:18:29 UTC
*** Bug 400579 has been marked as a duplicate of this bug. ***
Comment 11 Alex Legler (RETIRED) archtester gentoo-dev Security 2012-01-24 11:18:32 UTC
*** Bug 400571 has been marked as a duplicate of this bug. ***
Comment 12 Alex Legler (RETIRED) archtester gentoo-dev Security 2012-01-24 11:23:04 UTC
*** Bug 400581 has been marked as a duplicate of this bug. ***
Comment 13 Rafał Mużyło 2012-01-24 13:51:26 UTC
(In reply to comment #9)
> Hi Mike, Hi all,
> 
> > I had to apply it manually.
> It seems that 2100_proc-mem-handling-fix.patch is only a patch of a patch and
> thus it fails. It just creates
> b/queue-3.2/proc-clean-up-and-fix-proc-pid-mem-handling.patch within the kernel
> source directory. Mike, could you please fix that?
> 
Seems the patch included in the genpatches-3.2-4.base tarball is broken in more than one way.

- it was pulled from git, but it seems it was saved with wrong encoding (latin1 as opposed to utf8); while just cosmetic (as affects only comments), still...
- the patch itself doesn't properly manually apply (by 'patch -p1' from KDIR), as (AFAICT) somebody decided to change indentation (likely while saving)
Comment 14 Alex Legler (RETIRED) archtester gentoo-dev Security 2012-01-24 23:08:01 UTC
*** Bug 400651 has been marked as a duplicate of this bug. ***
Comment 15 Mike Pagano gentoo-dev 2012-01-25 01:52:54 UTC
Ok, the versions have been in the tree since this morning (1/23). The fixed versions are:

gentoo-sources-3.2.1-r2
gentoo-sources-3.1.10-r1
gentoo-sources-3.0.17-r2

I fast tracked 3.1.10-r1 and 3.0.17-r2 as per our policy since we had earlier kernels stabilized for those versions.

For 3.2.1-r2 I opened a critical stabilization bug for the arch teams to work. [1]


[1] https://bugs.gentoo.org/show_bug.cgi?id=400671
Comment 16 Mike Pagano gentoo-dev 2012-01-25 01:54:03 UTC
BTW, this exploit only affects > 2.6.39. So no patch for that version or lower is needed, apparently.
Comment 17 Mike Pagano gentoo-dev 2012-01-25 01:59:09 UTC
Looks like I am incorrect about 2.6.39 being unaffected.  I will be dropping this kernel from the tree for gentoo-sources.
Comment 18 cyberbat 2012-01-25 05:56:58 UTC
And what about hardened-sources?
Comment 19 cyberbat 2012-01-25 06:19:34 UTC
Is issue that is opened by fixing current CVE and described here: http://www.openwall.com/lists/oss-security/2012/01/22/5 fixed in

gentoo-sources-3.2.1-r2
gentoo-sources-3.1.10-r1
gentoo-sources-3.0.17-r2

?
Comment 20 werner maier 2012-01-25 09:49:59 UTC
Created attachment 299811 [details, diff]
proc-mem-handling patch for 2.6.39-gentoo-r3 kernel

As we are stuck to gentoo-2.6.39-gentoo-r3 for some reasons, 
I backported the patch based on 2.6.39-gentoo-r3. 
the exploit that worked with 2.6.39-gentoo-r3 does not give a root shell any more.

(don't know, if 2.6.39 is still supported as it is a bit outdated right now)

maybe it is useful for some people out there.
Comment 21 Andrey 2012-01-25 10:07:26 UTC
(In reply to comment #15)
> Ok, the versions have been in the tree since this morning (1/23). The fixed
> versions are:
> 
> gentoo-sources-3.2.1-r2
> gentoo-sources-3.1.10-r1
> gentoo-sources-3.0.17-r2

I've tested gentoo-sources-3.2.1-r2 and it is not affected by the exploit anymore.
Comment 22 kfm 2012-01-26 19:21:40 UTC
In case anyone is interested, the offending code was unleashed by commit 198214a7ee50375fa71a65e518341980cfd4b2f0, which made it into 2.6.39. The flawed functionality was wrapped in an #ifdef which was removed in this commit. The patch attached to this bug is what actually fixes said functionality.

https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=198214a7ee50375fa71a65e518341980cfd4b2f0

In other words, vanilla kernels from 2.6.39 onwards are affected.
Comment 23 GLSAMaker/CVETool Bot gentoo-dev 2012-02-25 04:08:02 UTC
CVE-2012-0056 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-0056):
  The mem_write function in Linux kernel 2.6.39 and other versions, when ASLR
  is disabled, does not properly check permissions when writing to
  /proc/<pid>/mem, which allows local users to gain privileges by modifying
  process memory, as demonstrated by Mempodipper.
Comment 24 Aaron Bauman (RETIRED) gentoo-dev 2018-04-04 18:05:00 UTC
There are no longer any 2.x kernels available in the repository with the exception of sys-kernel/xbox-sources which is unsupported by security.