Summary: | app-arch/p7zip-9.20.1: RWX mmaping causes failure on PaX kernels | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Cănărău Constantin <canarauc> |
Component: | Current packages | Assignee: | The Gentoo Linux Hardened Team <hardened> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | blueness, hardened, jlec, pageexec, radek, taaroa |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Kernel config
strace -o 7za.hardened.trace /usr/bin/7za a -- test.c.7z test.c strace -o 7za.vanilla.trace /usr/bin/7za a -- test.c.7z test.c Patch to fix RWX issues |
Description
Cănărău Constantin
2011-04-06 20:13:24 UTC
Created attachment 268755 [details]
Kernel config
Which version of app-arch/p7zip is that? It's p7zip-9.20.1 as in "Steps to reproduce". But I didn't specified the use flags: These are the packages that would be merged, in order: [ebuild R ] app-arch/p7zip-9.20.1 USE="-doc -kde (-pch) -rar (-static) -wxwidgets" 0 kB I didn't hit this with 9.13 but I did with 9.20.1. The significant difference between our systems is that I have gcc-4.4.5 glibc-2.11.3 hardned-sources=2.6.32-r43. I haven't looked in the code yet to see where the RWX mmaping might be happening, but I'm pretty sure its not the 2.6.37 -> 2.6.38 move. Both would equally complain about RWX anon mmaps. I'll look later at where this is happening but as a work around for now, downgrade to 9.13 which is the current stable. 9.20.1 is unstable. Actually I switched to pbzip2. It's important to me to compress a large amount of data in a time window period. bzip gzip, 7zip<9.20 use 1 or 2 core max. 7zip have a better ratio compression than (p)bzip2, that's why I chose it. I used hardened profile and 7zip for a very long period and, for me, it's the first time when I hit this bug. Thanks for the info! Hopefully it will help to solve this bug as quick as possible. * Messages for package app-arch/p7zip-9.13: * Package: app-arch/p7zip-9.13 * Repository: gentoo * Maintainer: jlec@gentoo.org radek@gentoo.org * USE: amd64 elibc_glibc kernel_linux userland_GNU * FEATURES: fakeroot preserve-libs sandbox suidctl usersandbox * Package: app-arch/p7zip-9.13 * Repository: gentoo * Maintainer: jlec@gentoo.org radek@gentoo.org * USE: amd64 elibc_glibc kernel_linux userland_GNU * FEATURES: fakeroot preserve-libs sandbox suidctl usersandbox * Applying 9.04-makefile.patch ... * Applying 9.04-kde4.patch ... * QA Notice: Package has poor programming practices which may compile * fine but exhibit random runtime failures. * ../../Archive/NtfsHandler.cpp:1253:78: warning: passing NULL to non-pointer argument 4 of 'bool NArchive::Ntfs::CMftRec::Parse(Byte*, int, UInt32, UInt32, CObjectVector<NArchive::Ntfs::CAttr>*)' * Please do not file a Gentoo bug and instead report the above QA * issues directly to the upstream developers of this software. * Homepage: http://p7zip.sourceforge.net/ ----------------- * Messages for package app-arch/p7zip-9.20.1: * Package: app-arch/p7zip-9.20.1 * Repository: gentoo * Maintainer: jlec@gentoo.org radek@gentoo.org * USE: amd64 elibc_glibc kernel_linux userland_GNU * FEATURES: fakeroot preserve-libs sandbox suidctl usersandbox * Package: app-arch/p7zip-9.20.1 * Repository: gentoo * Maintainer: jlec@gentoo.org radek@gentoo.org * USE: amd64 elibc_glibc kernel_linux userland_GNU * FEATURES: fakeroot preserve-libs sandbox suidctl usersandbox * Applying 9.04-makefile.patch ... * QA Notice: The following files contain writable and executable sections * Files with such sections will not work properly (or at all!) on some * architectures/operating systems. A bug should be filed at * http://bugs.gentoo.org/ to make sure the issue is fixed. * For more information, see http://hardened.gentoo.org/gnu-stack.xml * Please include the following list of files in your report: * Note: Bugs should be filed for the respective maintainers * of the package in question and not hardened@g.o. * RWX --- --- usr/lib64/p7zip/7z.so * RWX --- --- usr/lib64/p7zip/7z * RWX --- --- usr/lib64/p7zip/7zr * RWX --- --- usr/lib64/p7zip/7za * RWX --- --- usr/lib64/p7zip/7zCon.sfx * QA Notice: Package has poor programming practices which may compile * fine but exhibit random runtime failures. * ../../Archive/NtfsHandler.cpp:1283:78: warning: passing NULL to non-pointer argument 4 of 'bool NArchive::Ntfs::CMftRec::Parse(Byte*, int, UInt32, UInt32, CObjectVector<NArchive::Ntfs::CAttr>*)' * Please do not file a Gentoo bug and instead report the above QA * issues directly to the upstream developers of this software. * Homepage: http://p7zip.sourceforge.net/ p.s. Portage 2.2.0_alpha29 (hardened/linux/amd64/no-multilib, gcc-4.5.2, glibc-2.13-r2, 2.6.38-hardened x86_64) Okay this packages has a lot of issues. I spent too much time trying to trace down where the RWX mmap occurs, but haven't nailed it. A simple grep -r mmap * gives C/Alloc.c.back2: address = mmap(ADDR, size, PROTECTION, FLAGS, 0, 0); C/Alloc.c.back: address = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); C/Alloc.c: address = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0 which doesn't show any PROT_READ|PROT_WRITE|PROT_EXEC. Yet when I run it and strace, I get the RWX mapping. Strangely this does not happen on a vanilla system. So somehow the RWX mapping is introduced on hardened systems. Climbing back through the code, I know it happens when the following call is made: _mixerCoder->Code(&inStreamPointers.Front(), NULL, 1, &outStreamPointers.Front(), NULL, outStreamPointers.Size(), compressProgress) at line 248 of CPP/7zip/Archive/7z/7zEncode.cpp. It goes further back, but I stopped there. I don't think I want to spend any more time with this, so I'm going to p.mask it on hardened/linux/amd64 unless there are any objections, solutions, workarounds. Subsequent posts will have my straces on hardened and vanilla. All USE flags are off. I tried different combinations, but no change. Created attachment 269147 [details]
strace -o 7za.hardened.trace /usr/bin/7za a -- test.c.7z test.c
Created attachment 269149 [details]
strace -o 7za.vanilla.trace /usr/bin/7za a -- test.c.7z test.c
It sounds good to me, as there are alternatives to p7zip and by masking this version will prevent other users to hit this bug. I also tried p7zip with other hardened-sources version and the problem occurred only with 2.6.38. Maybe next versions of hardened-sources will "automatically" fix the problem. this is just the usual RWE GNU_STACK crap as reported by emerge itself. execstack -c /usr/lib64/p7zip/* is your friend or you can hunt down the unmarked .S file(s). Created attachment 269281 [details, diff]
Patch to fix RWX issues
Classical case of assembler missing the stack markings. The culprits:
./Asm/x64/7zCrcT8U.asm
./Asm/x86/7zCrcT8U.asm
Attaches is a patch to fix this. Please send also upstream so they can fix that now and on their future assembler code.
Fixing the asm did it. However, there was no change in the asm between 9.13 and 9.20.1. So something else changed that caused it to be triggered in the latter but not the former. (In reply to comment #13) > Fixing the asm did it. However, there was no change in the asm between 9.13 > and 9.20.1. So something else changed that caused it to be triggered in the > latter but not the former. I am not sure about this, but I think it is because the ebuild for 9.13 uses makefile.linux_amd64 while 9.20 uses makefile.linux_amd64_asm (i.e. 9.13 does not use asm, 9.20 uses it). Reported upstream: https://sourceforge.net/tracker/?func=detail&aid=3283518&group_id=111810&atid=660493 (In reply to comment #14) > (In reply to comment #13) > > Fixing the asm did it. However, there was no change in the asm between 9.13 > > and 9.20.1. So something else changed that caused it to be triggered in the > > latter but not the former. > > I am not sure about this, but I think it is because the ebuild for 9.13 uses > makefile.linux_amd64 while 9.20 uses makefile.linux_amd64_asm (i.e. 9.13 does > not use asm, 9.20 uses it). Yep. If you just get rid of makefile.linux_amd64_asm on hardened and recompile, it doesn't use the asm and it works like 9.13. (In reply to Anthony Basile from comment #16) > Yep. If you just get rid of makefile.linux_amd64_asm on hardened and > recompile, it doesn't use the asm and it works like 9.13. How do I detect hardened profiles without an explicit USE? (In reply to Justin Lecher from comment #17) > (In reply to Anthony Basile from comment #16) > > Yep. If you just get rid of makefile.linux_amd64_asm on hardened and > > recompile, it doesn't use the asm and it works like 9.13. > > How do I detect hardened profiles without an explicit USE? Even if you check for hardened you still have a QA on the packages for The following files contain writable and executable sections. And the fix is simpel. (In reply to Magnus Granberg from comment #18) > (In reply to Justin Lecher from comment #17) > > (In reply to Anthony Basile from comment #16) > > > Yep. If you just get rid of makefile.linux_amd64_asm on hardened and > > > recompile, it doesn't use the asm and it works like 9.13. > > > > How do I detect hardened profiles without an explicit USE? > Even if you check for hardened you still have a QA on the packages for > The following files contain writable and executable sections. > And the fix is simpel. Ah so the bug is fixed for long and also by upstream now |