| Summary: | [hardened] app-editors/emacs-23.4-r1 segfault in unexec with hardened-sources-3.3* | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Nick Wallingford <nick> |
| Component: | Current packages | Assignee: | Emacs project <emacs> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | flameeyes, hardened-kernel+disabled, pageexec, spender |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| URL: | http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11398 | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=417037 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Complete build log.
emerge --info kernel config for hardened-sources-3.3.1-r1 Diff between 3.2.12 and 3.3.1 Patch for app-editors/emacs-23.4-r1 Patch for app-editors/emacs-vcs-24.0.97 (applies to BZR trunk version too) |
||
|
Description
Nick Wallingford
2012-04-10 07:31:25 UTC
Created attachment 308365 [details]
Complete build log.
Created attachment 308367 [details]
emerge --info
Does it build with the recipe from bug 345001 comment #5? Does building of the latest pretest version (emacs-vcs-24.0.95) succeed? If not, what has changed on your system (kernel version, etc.) since the last successful build of 23.4? Succeeds with /proc/sys/kernel/randomize_va_space=0 Fails with /proc/sys/kernel/randomize_va_space=1 Fails with /proc/sys/kernel/randomize_va_space=2 (default) app-editors/emacs-vcs-24.0.95 fails with /proc/sys/kernel/randomize_va_space=2 The current kernel is hardend-sources-3.3.1. (fails) Fails with hardened-sources-3.3.0 Fails with hardened-sources-3.3.1-r1 Succeeds with hardened-sources-3.2.11 The kernel .config did not change in a relevant fashion between 3.3.0 and 3.2.11. (In reply to comment #4) > The current kernel is hardend-sources-3.3.1. (fails) > Fails with hardened-sources-3.3.0 > Fails with hardened-sources-3.3.1-r1 > Succeeds with hardened-sources-3.2.11 > > The kernel .config did not change in a relevant fashion between 3.3.0 and > 3.2.11. Thanks for testing; this may help to locate the problem. Could you attach your .config for 3.2.11 and 3.3.0? @hardened-kernel: Any idea what could cause this? Created attachment 308395 [details]
kernel config for hardened-sources-3.3.1-r1
(In reply to comment #4) > Fails with hardened-sources-3.3.1-r1 > Succeeds with hardened-sources-3.2.11 I can reproduce above two cases. The problem disappears (i.e. building of Emacs succeeds) when I unset the CONFIG_PAX_RANDMMAP kernel config option for hardened-sources-3.3.1-r1. Created attachment 308469 [details, diff]
Diff between 3.2.12 and 3.3.1
The relevant change between linux-3.2.12-hardened and linux-3.3.1-hardened-r1 that causes the bug seems to be in fs/binfmt_elf.c, see attached diff.
Reverting this change fixes the problem for me.
(In reply to comment #8) > Created attachment 308469 [details, diff] [details, diff] > Diff between 3.2.12 and 3.3.1 > > The relevant change between linux-3.2.12-hardened and > linux-3.3.1-hardened-r1 that causes the bug seems to be in fs/binfmt_elf.c, > see attached diff. > > Reverting this change fixes the problem for me. @pageexec Looks like your change to the elf_brk += code broke something. Maybe because of the page alignment? can you guys try a more recent version please? i've fixed bugs in that code (just compare what's in PaX now vs. what was posted here), so i'd rather not chase ghosts ;). (In reply to comment #10) > can you guys try a more recent version please? i've fixed bugs in that code > (just compare what's in PaX now vs. what was posted here), so i'd rather not > chase ghosts ;). Okay, I'll prepare the latest and put them on the tree for testing. I'll ping you guys back when its ready. (In reply to comment #11) > (In reply to comment #10) > > can you guys try a more recent version please? i've fixed bugs in that code > > (just compare what's in PaX now vs. what was posted here), so i'd rather not > > chase ghosts ;). > > Okay, I'll prepare the latest and put them on the tree for testing. I'll > ping you guys back when its ready. No joy. I'm hitting the same issue on both x86 and amd64 with hardened-sources-3.3.4 (which is only on my overlay for now). hs-3.3.4 = grsecurity-2.9-3.3.4-201204272006. I have not tested with the 2.6.32 or 3.2.16 patches. i've debugged the problem and it's a bug in emacs. it wants to create a memory dump of its address space without actually looking at what memory ranges are available with what access rights. due to recentish changes in PaX the gap between the end of the main executable's data section and the start of the brk heap is mapped with PROT_NONE rights, so no access is allowed and this is where emacs fails. PaX also ignores the ADDR_NO_RANDOMIZE personality bit because it's a security bug itself, so emacs can't use it as a workaround either. the fix for this (in gentoo) can go two ways: either disable RANDMMAP on emacs (requires makefile changes i guess) or as a last resort, i can add a special case hack to the brk randomization code to use PROT_READ rights for the gap when this personality bit is set (have yet to test it, but i think it'd get emacs's memory dumper code to work). your turn ;). It's certainly not a bug in Emacs. That unexec code has worked for many years without any problem. (In reply to comment #13) > PaX also ignores the ADDR_NO_RANDOMIZE personality bit [...] That's where the bug is. Emacs sets ADDR_NO_RANDOMIZE for a purpose. This is only done for dumping the final executable, not during normal operation. (In reply to comment #14) > It's certainly not a bug in Emacs. That unexec code has worked for many > years without any problem. it worked by chance, not because it was/is correct. you know, programs with exploitable bugs in them work fine 'for many years without any problem' as well... > (In reply to comment #13) > > PaX also ignores the ADDR_NO_RANDOMIZE personality bit [...] > > That's where the bug is. Emacs sets ADDR_NO_RANDOMIZE for a purpose. This is > only done for dumping the final executable, not during normal operation. FYI, ADDR_NO_RANDOMIZE was added as a workaround to fix userland bugs like what emacs has (the first bug is about assuming a particular address space layout that no standard has ever guaranteed, the second bug is that emacs doesn't use the kernel provided interface to discover its own address space layout). ignoring ADDR_NO_RANDOMIZE is the right decision because it destroys the security provided by randomization. last but not least, PaX allows the turning off of ASLR - just not at runtime. did you give it a try? (In reply to comment #15) > PaX allows the turning off of ASLR - just not at runtime. did you give it > a try? As I said before, Emacs doesn't need it at runtime, only at build time. But how should the Emacs build system turn off ASLR, if ADDR_NO_RANDOMIZE isn't available? (In reply to comment #16) > (In reply to comment #15) > > PaX allows the turning off of ASLR - just not at runtime. did you give it > > a try? > > As I said before, Emacs doesn't need it at runtime, only at build time. But > how should the Emacs build system turn off ASLR, if ADDR_NO_RANDOMIZE isn't > available? you misunderstood 'runtime'. i meant it as 'when the program is running' and emacs does enable this personality bit when it is running, i.e., at runtime. on the other hand the PaX approach is to not let programs do this exactly because an exploit could then do the same as well. instead, the binary file must be properly marked (chpax/paxctl/etc) so that the kernel can disable ASLR on process startup. but all that is still a workaround for what is fundamentally a bug in emacs's memory dumper code, the proper fix should be in there. Looks like dumping succeeds after doing "paxctl -r src/temacs". However, the final emacs executable would inherit the "r" flag, and looks like paxctl cannot output existing flags in a machine readable way that could be used for restoring them later. (It doesn't even have an option to suppress its chattiness and always outputs its copyright...) I've tried "paxctl -z", but that will clear out all flags, whereas the set was nonempty before. (In reply to comment #18) > Looks like dumping succeeds after doing "paxctl -r src/temacs". However, the > final emacs executable would inherit the "r" flag, does emacs (after dumping) work with ASLR at all? > and looks like paxctl cannot output existing flags in a machine readable way > that could be used for restoring them later. paxctl -vQ /bin/cat 2>/dev/null| cut -f 4 -d ' ' | sed s/-//g > (It doesn't even have an option to suppress its chattiness and always outputs > its copyright...) paxctl ... 2>/dev/null > I've tried "paxctl -z", but that will clear out all flags, whereas the set was nonempty before. the binutils default (it's in the manpage too) is equivalent to: paxctl -zex (In reply to comment #19) > (In reply to comment #18) > > Looks like dumping succeeds after doing "paxctl -r src/temacs". However, the > > final emacs executable would inherit the "r" flag, > > does emacs (after dumping) work with ASLR at all? I haven't noticed any problems, at least. Basically, Emacs' build system first compiles the C sources to make the temacs binary. Then it executes "./temacs --batch --load loadup dump" which will load the standard lisp files and then dump the final emacs binary. Disabling RANDMMAP for temacs ("paxctl -r temacs") before that step should be enough; restoring the flags for the final emacs binary ("paxctl -zex emacs") seems to be harmless. > the binutils default (it's in the manpage too) is equivalent to: paxctl -zex Is it guaranteed that this default will be stable across systems and releases? (In reply to comment #17) > [...] all that is still a workaround for what is fundamentally a bug in > emacs's memory dumper code, the proper fix should be in there. I had forwarded this to Emacs upstream <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11398>, but they immediately passed the buck back to this (downstream) bug. (In reply to comment #20) > > the binutils default (it's in the manpage too) is equivalent to: paxctl -zex > > Is it guaranteed that this default will be stable across systems and > releases? yes, it's been this way since 2004 or so ;). > I had forwarded this to Emacs upstream > <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11398>, but they immediately > passed the buck back to this (downstream) bug. what does 'Set bug forwarded-to-address to' mean in their lingo? i don't see any explanation/discussion at all, so i'm wondering what's going on there... (In reply to comment #21) > what does 'Set bug forwarded-to-address to' mean in their lingo? i don't see > any explanation/discussion at all, so i'm wondering what's going on there... Sorry, that was a misunderstanding on my side. See <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11398#13> for clarification from upstream. Created attachment 312873 [details, diff]
Patch for app-editors/emacs-23.4-r1
Could you please try if attached patch for Emacs 23.4 fixes the problem?
Created attachment 312875 [details, diff]
Patch for app-editors/emacs-vcs-24.0.97 (applies to BZR trunk version too)
> [...]unexec will fail because memory regions of executables are randomized.
note that the problem is not with randomization per se but the inaccessible gap between the bss and the brk regions. it could be of a constant size (and hence brk heap addresses would not be randomized) yet it'd still trigger the emacs memory dumper bug.
(In reply to comment #25) > > [...]unexec will fail because memory regions of executables are randomized. > > note that the problem is not with randomization per se but the inaccessible > gap between the bss and the brk regions. it could be of a constant size (and > hence brk heap addresses would not be randomized) yet it'd still trigger the > emacs memory dumper bug. ## On grsecurity/PaX systems, unexec will fail due to a gap between ## the bss section and the heap. This can be prevented by disabling ## memory randomization in temacs with "paxctl -r". See bug#11398. Better? (In reply to comment #26) > ## On grsecurity/PaX systems, unexec will fail due to a gap between > ## the bss section and the heap. This can be prevented by disabling > ## memory randomization in temacs with "paxctl -r". See bug#11398. > > Better? definitely, thanks ;) Should be fixed in emacs-23.4-r2 (with USE=pax_kernel). Please test. Patch with paxctl workaround committed upstream: <http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/108471> *** Bug 423693 has been marked as a duplicate of this bug. *** *** Bug 423693 has been marked as a duplicate of this bug. *** I have exactly the same problem with emacs-24.2 (latest stable on hardened profile) and sys-kernel/hardened-sources-3.7.4-r1 and sys-devel/gcc-4.6.3. ************************************************** Warning: Your system has a gap between BSS and the heap (15854248 bytes). This usually means that exec-shield or something similar is in effect. The dump may fail because of this. See the section about exec-shield in etc/PROBLEMS for more information. ************************************************** Workaround is to disable randomize_va_space for the compile step and reenable it afterwards. echo "0" > /proc/sys/kernel/randomize_va_space emerge emacs echo "1" > /proc/sys/kernel/randomize_va_space (In reply to comment #32) > I have exactly the same problem with emacs-24.2 (latest stable on hardened > profile) and sys-kernel/hardened-sources-3.7.4-r1 and sys-devel/gcc-4.6.3. Please file a new bug report, including build.log and emerge --info. (In reply to comment #33) > (In reply to comment #32) > > I have exactly the same problem with emacs-24.2 (latest stable on hardened > > profile) and sys-kernel/hardened-sources-3.7.4-r1 and sys-devel/gcc-4.6.3. > > Please file a new bug report, including build.log and emerge --info. See bug 456970. |
