| |||||||||||||
|
| |||||||||||||
Stable kernel 2.6.25.10Stable kernel 2.6.25.10Posted Jul 6, 2008 10:55 UTC (Sun) by PaXTeam (subscriber, #24616)In reply to: Stable kernel 2.6.25.10 by avik Parent article: Stable kernel 2.6.25.10
> null function pointers are only exploitable if vm.mmap_min_addr is zero, no, if a process has CAP_SYS_RAWIO it can also evade the 0 mmap restriction (and let's ignore the early implementation bugs of this feature). if a process doesn't yet have CAP_SYS_RAWIO, it can 'acquire' it by exploiting another that does have it (think of X for example or any suid root process). or alternatively, one has to use SELinux and make sure no process can be granted MEMPROTECT__MMAP_ZERO. and all of this breaks valid userland programs, so it's not a universal solution (it's default off for that reason). > which should not be the case on most installations. any statistics to back it up? remember, it needs both CONFIG_SECURITY and be set to some meaningful value. in any case, i'm not sure what you were trying to say, if a bug falls into a known exploitable bug class then it should be reported as such (or briefly explained why it's not what it looks like), regardless of what mitigation factors may apply in a given installation. such info belongs to vendor advisories at most, not a kernel commit message. > I imagine getting 4G references on a task_struct would be hard without > root privileges. the patch fixes a few ptrace commands that can be issued by any user, not only root. therefore it's triggerable and exploitable by any user who's not otherwise prevented from using ptrace. as for the technical feasibility of issuing 4G ptrace calls, on a core2 a single GETREGS takes less than 30 usec, that's less than 2 days of runtime.
(Log in to post comments)
Stable kernel 2.6.25.10 Posted Jul 6, 2008 14:02 UTC (Sun) by nix (subscriber, #2304) [Link] To me, the fact that it breaks GDB is more significant, but then I don't have dedicated maniacs attacking my systems with billions of custom-written ptrace()s (and if they did, it would take them days and there's no way I'd not notice even if I was on another continent).
Stable kernel 2.6.25.10 Posted Jul 7, 2008 2:35 UTC (Mon) by spender (subscriber, #23067) [Link] I wrote a working PoC for the vulnerability today. It only takes 20 minutes for me (inside a 3.3ghz single-processor VM). -Brad
Stable kernel 2.6.25.10 Posted Jul 7, 2008 6:48 UTC (Mon) by nix (subscriber, #2304) [Link] ... and if it took you twenty minutes, your average script kiddie would take weeks, if ever. (Of course, buying a copy from a blackhat with similar skills would probably be faster.)
Stable kernel 2.6.25.10 Posted Jul 7, 2008 7:49 UTC (Mon) by PaXTeam (subscriber, #24616) [Link] the 20 mins was the runtime of the exploit, not its development time.
Stable kernel 2.6.25.10 Posted Jul 7, 2008 19:43 UTC (Mon) by nix (subscriber, #2304) [Link] I thought 20 minutes seemed awfully fast to write an exploit from scratch, but I'm not very good at that sort of thing so I thought maybe skilled people are faster. (Still, if a random blackhat tries to eat that amount of CPU time on any of my security-important systems all sorts of alarms would go off. But maybe that's more paranoia than most people show, and I suppose if the attacker knew about those monitoring systems he could distribute the computational work among numerous processes and a long stretch of time. Still, again, if an attacker knows that much, I'm dead anyway. Maybe this is significant to unmonitored systems with untrusted local users, and I suppose it makes it easier to escalate to root once you've got in via some vulnerable network service, but if the attacker's managed that, again, you're dead anyway: and most attackers these days don't *care* about escalation to root: all they care about is being able to spam like crazy, and being able to spy on the user, and an attack via, say, a browser vulnerability will give them all of that.)
|
|
||||||||||||