Weekly Edition
Return to the Distributions page
| |||||||||||
Red Hat upgrades security (News.com)
News.com
reports that Red Hat has released an update to its enterprise product
with security upgrades, support for IBM Power5 servers, new driver support
and bug fixes. "The security upgrades in Enterprise Linux 3 Update 3
include Exec-shield and Position Independent Executable (PIE) features to
protect against stack, buffer or function pointer overflows and other
exploits that involve overwriting data structures in memory. No-execute
(NX) support will now be available for Intel x86, Intel EM64T and Advanced
Micro Devices AMD64 processors."
(Log in to post comments)
Red Hat upgrades security (News.com) Posted Sep 8, 2004 13:25 UTC (Wed) by spender (guest, #23067) [Link] Maybe Red Hat should spend less time writing press releases and more time updating their glibc so that their "security" isn't trivial to bypass locally (by leaking randomization for the entire address space for a setuid binary and then performing a ret2libc that causes the entire address space to become executable)
WHOOPS!
Red Hat upgrades security (News.com) Posted Sep 8, 2004 16:29 UTC (Wed) by solar (guest, #17536) [Link] - Claim #1: You can't get exact addresses from LD_DEBUG, just whatlibrary the symbols are contained in, and that information is already readily available and doesn't improve exploits. - Claim #2: You can always affect timing and the only additional issue is that you can get some information about the timing by watching the LD_DEBUG output. You can always stop a setuid program with job control anyway.
The above is the response from the glibc maintainers.
Red Hat upgrades security (News.com) Posted Sep 9, 2004 1:08 UTC (Thu) by walters (subscriber, #7396) [Link] Are you saying you disagree? The upstream response makes sense to me.
Red Hat upgrades security (News.com) Posted Sep 9, 2004 21:14 UTC (Thu) by PaXTeam (subscriber, #24616) [Link] the answers don't make sense for the following reasons:
1. LD_DEBUG=all provides precise *runtime* addresses, which becomes evident as soon as you diff two outputs under a kernel patched by Exec-Shield or PaX (or anything that adds randomization to mmap). it's needless to say that having precise *runtime* addresses makes it trivial to adjust shellcode and whatnot for an exploit *live* (meaning, it becomes a one shot success story, probably not what you'd expect from a security conscious glibc).
2. the point in timing attacks is not that you can prevent them by ignoring certain LD_ variables but that glibc should not help them become very reliable by leaking information about the progress of the attacked application and hence allow precise timing.
NX support for x86? Posted Sep 9, 2004 10:11 UTC (Thu) by nhoxanh (guest, #17931) [Link] anybody knows how can they support NX for x86? since only modern architecture like Opteron and Itanium (all are 64bits, not x86) support that kind of technique.
NX support for x86? Posted Sep 9, 2004 11:21 UTC (Thu) by eru (subscriber, #2753) [Link] The answer can be found right here in LWN.net. See article x86 NX support and especially its attached comments.
NX support for x86? Posted Sep 9, 2004 16:50 UTC (Thu) by nhoxanh (guest, #17931) [Link] eh... so the answer is that they force x86 to run in PAE mode (supported from PentiumPro upward) in order to have NX feature on "legacy" system.
anybody can compare this approach to PAX ? and anyway why PAX is not in mainline kernel? after all, this kind of technique was invented by PAX team long time before.
many thanks
NX support for x86? Posted Sep 9, 2004 12:49 UTC (Thu) by danpb (guest, #4831) [Link] This whitepaper goes into more detail about ExecShield/NX/PIE implementation
http://www.redhat.com/f/pdf/rhel/WHP0006US_Execshield.pdf
|
|||||||||||