Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
null function pointers are only exploitable if vm.mmap_min_addr is zero, which should not be
the case on most installations.
I imagine getting 4G references on a task_struct would be hard without root privileges.
Stable kernel 188.8.131.52
Posted Jul 6, 2008 10:49 UTC (Sun) by nix (subscriber, #2304)
If they're in an array of structures and you can integer-overflow the
array index, suddenly they're dangerous again.
Posted Jul 6, 2008 10:55 UTC (Sun) by PaXTeam (subscriber, #24616)
> 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
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.
Posted Jul 6, 2008 14:02 UTC (Sun) by nix (subscriber, #2304)
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).
Posted Jul 7, 2008 2:35 UTC (Mon) by spender (subscriber, #23067)
I wrote a working PoC for the vulnerability today. It only takes 20 minutes for me (inside a
3.3ghz single-processor VM).
Posted Jul 7, 2008 6:48 UTC (Mon) by nix (subscriber, #2304)
... 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.)
Posted Jul 7, 2008 7:49 UTC (Mon) by PaXTeam (subscriber, #24616)
the 20 mins was the runtime of the exploit, not its development time.
Posted Jul 7, 2008 19:43 UTC (Mon) by nix (subscriber, #2304)
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.)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds