Bug 220892 - execshield does not respect PF_RANDOMIZE and ADDR_NO_RANDOMIZE
Summary: execshield does not respect PF_RANDOMIZE and ADDR_NO_RANDOMIZE
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 13
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Roland McGrath
QA Contact: Brian Brock
URL:
Whiteboard: bzcl34nup
Depends On:
Blocks: 605516
TreeView+ depends on / blocked
 
Reported: 2006-12-28 13:23 UTC by David Woodhouse
Modified: 2010-07-08 18:24 UTC (History)
4 users (show)

Fixed In Version: kernel-2.6.33.6-147.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 605516 (view as bug list)
Environment:
Last Closed: 2010-07-08 18:24:22 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Testcase. (3.79 KB, text/plain)
2010-03-26 21:35 UTC, Jan Kratochvil
no flags Details
test case (4.02 KB, text/plain)
2010-06-18 06:29 UTC, Roland McGrath
no flags Details
systemtap script demonstrating personality and PF_RANDOMIZE state (849 bytes, text/plain)
2010-06-18 06:55 UTC, Roland McGrath
no flags Details

Description David Woodhouse 2006-12-28 13:23:50 UTC
I found code which sets the ADDR_NO_RANDOMIZE bit in its personality and then
re-execs itself. This goes into an endless loop on x86_64 and ppc64 with 32-bit
binaries, because we lose all those extra bits when we set PER_LINUX32 for
32-bit binaries. (Bug #201739)

This is arguably a kernel bug -- we should keep those bits just like the 32-bit
kernel does.

Comment 1 Bug Zapper 2008-04-03 18:50:08 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 2 Bug Zapper 2008-05-07 01:04:04 UTC
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

Comment 3 Jan Kratochvil 2010-03-26 21:34:17 UTC
This problem still exists.
It affects both x86_64 kernels running i386 programs and i386 kernels.

As GDB has default "set disable-randomization on" for reproducible debugging sessions this feature does not work for 32bit programs/platform.

Tested:
kernel-2.6.33.1-19.fc13.i686
kernel-2.6.32.9-70.fc12.x86_64

(set -x; for i in -m64 -m32;do gcc $i -o ADDR_NO_RANDOMIZE ADDR_NO_RANDOMIZE.c -Wall -g -fPIE -pie && ./ADDR_NO_RANDOMIZE; done)
+ gcc -m64 -o ADDR_NO_RANDOMIZE ADDR_NO_RANDOMIZE.c -Wall -g -fPIE -pie
nonrandom3: OK
+ gcc -m32 -o ADDR_NO_RANDOMIZE ADDR_NO_RANDOMIZE.c -Wall -g -fPIE -pie
nonrandom2: Even with ADDR_NO_RANDOMIZE: prev 0x48d82c vs. now 0xb4882c

Comment 4 Jan Kratochvil 2010-03-26 21:35:04 UTC
Created attachment 402960 [details]
Testcase.

Comment 6 Chuck Ebbert 2010-06-18 02:26:58 UTC
This was fixed on powerpc by:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=59e4c3a2fe9cb1681bb2cff508ff79466f7585ba

but apparently x86 didn't get an equivalent fix.

Comment 7 Roland McGrath 2010-06-18 06:29:45 UTC
Created attachment 425015 [details]
test case

modified the test case so that ambient RLIMIT_STACK too large doesn't result in "no randomization found" error.

Comment 8 Roland McGrath 2010-06-18 06:55:41 UTC
Created attachment 425019 [details]
systemtap script demonstrating personality and PF_RANDOMIZE state

This is not a personality issue.  On kernel-2.6.33.5-124.fc13.x86_64 the attached stap script shows:

	magilla 30 % stap -c ~/redhat/testcases/ADDR_NO_RANDOMIZE-32 pers.stp
	"/home/roland/redhat/testcases/ADDR_NO_RANDOMIZE-32"
	"/home/roland/redhat/testcases/ADDR_NO_RANDOMIZE-32" "0x555558ac" "check"
	"/home/roland/redhat/testcases/ADDR_NO_RANDOMIZE-32" "0" "nonrandom1"
	"/home/roland/redhat/testcases/ADDR_NO_RANDOMIZE-32" "0x5d48ac" "nonrandom2"
	nonrandom2: Even with ADDR_NO_RANDOMIZE: prev 0x5d48ac vs. now 0x52e8ac
	0x402040 (R) execve("/home/roland/redhat/testcases/ADDR_NO_RANDOMIZE-32")
	0x402040 (R) kernel.function("flush_old_exec@fs/exec.c:958")
	0x40 (!R) kernel.function("flush_old_exec@fs/exec.c:958").return
	0x400000 (R) elf_map(0x0, 0x1544)  => 0x55555000
	0x400000 (R) elf_map(0x55557544, 0x158)  => 0x55557000
	0x400000 (R) elf_map(0x0, 0x1d944)  => 0x55558000
	0x400000 (R) elf_map(0x55576c60, 0xbd8)  => 0x55576000
	0x400000 (R) execve => 0
	0x400000 (R) write(1, "\"/home/roland/redhat/testcases/ADDR_NO_RANDO"..., 53)
	0x400000 (R) personality(0xffffffff)
	0x400000 (R) personality(0x0)
	0x400000 (R) execve("/proc/self/exe")
	0x400000 (R) kernel.function("flush_old_exec@fs/exec.c:958")
	0x0 (!R) kernel.function("flush_old_exec@fs/exec.c:958").return
	0x400000 (R) elf_map(0x0, 0x1544)  => 0x3e0000
	0x400000 (R) elf_map(0x3e2544, 0x158)  => 0x3e2000
	0x400000 (R) elf_map(0x0, 0x1d944)  => 0x401000
	0x400000 (R) elf_map(0x41fc60, 0xbd8)  => 0x41f000
	0x400000 (R) execve => 0
	0x402000 (R) write(1, "\"/home/roland/redhat/testcases/ADDR_NO_RANDO"..., 74)
	0x402000 (R) personality(0xffffffff)
	0x402000 (R) personality(0x40000)
	0x402000 (R) execve("/proc/self/exe")
	0x402000 (R) kernel.function("flush_old_exec@fs/exec.c:958")
	0x0 (!R) kernel.function("flush_old_exec@fs/exec.c:958").return
	0x0 (!R) elf_map(0x0, 0x1544)  => 0x5d4000
	0x0 (!R) elf_map(0x5d6544, 0x158)  => 0x5d6000
	0x0 (!R) elf_map(0x0, 0x1d944)  => 0x3aa000
	0x0 (!R) elf_map(0x3c8c60, 0xbd8)  => 0x3c8000
	0x0 (!R) execve => 0
	0x2000 (!R) write(1, "\"/home/roland/redhat/testcases/ADDR_NO_RANDO"..., 70)
	0x2000 (!R) personality(0xffffffff)
	0x2000 (!R) execve("/proc/self/exe")
	0x2000 (!R) kernel.function("flush_old_exec@fs/exec.c:958")
	0x0 (!R) kernel.function("flush_old_exec@fs/exec.c:958").return
	0x0 (!R) elf_map(0x0, 0x1544)  => 0x52e000
	0x0 (!R) elf_map(0x530544, 0x158)  => 0x530000
	0x0 (!R) elf_map(0x0, 0x1d944)  => 0x85b000
	0x0 (!R) elf_map(0x879c60, 0xbd8)  => 0x879000
	0x0 (!R) execve => 0
	0x2000 (!R) write(1, "\"/home/roland/redhat/testcases/ADDR_NO_RANDO"..., 77)
	0x2000 (!R) personality(0xffffffff)
	0x2000 (!R) write(2, "nonrandom2: Even with ADDR_NO_RANDOMIZE: prev"..., 72)
	magilla 31 %

This shows that the PF_RANDOMIZE flag is cleared, but the mmap innards are
doing randomization anyway.

This does not happen on upstream 2.6.35-rc3.  I'll investigate.

Comment 9 Roland McGrath 2010-06-18 10:08:10 UTC
Fix verified, building now.

Comment 10 Fedora Update System 2010-07-07 07:21:33 UTC
kernel-2.6.33.6-147.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/kernel-2.6.33.6-147.fc13

Comment 11 Fedora Update System 2010-07-07 17:43:52 UTC
kernel-2.6.33.6-147.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kernel-2.6.33.6-147.fc13

Comment 12 Fedora Update System 2010-07-08 18:23:20 UTC
kernel-2.6.33.6-147.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.