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
Proof of Concept link: http://blog.zx2c4.com/749
*** Bug 399865 has been marked as a duplicate of this bug. ***
- 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
(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.
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
(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.
Is there a patch for the 2.3.39 kernel?
(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.
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
*** Bug 400579 has been marked as a duplicate of this bug. ***
*** Bug 400571 has been marked as a duplicate of this bug. ***
*** Bug 400581 has been marked as a duplicate of this bug. ***
(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)
*** Bug 400651 has been marked as a duplicate of this bug. ***
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
BTW, this exploit only affects > 2.6.39. So no patch for that version or lower is needed, apparently.
Looks like I am incorrect about 2.6.39 being unaffected. I will be dropping this kernel from the tree for gentoo-sources.
And what about hardened-sources?
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 ?
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.
(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.
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.
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.
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.
