Just a little heads-up...
"If you run servers that provide shell accounts, it’s time to take
some preventive measures. At least it is if you are running kernel
versions 2.6.37 to 3.8.8, or if you are running RHEL 6 or a clone like CentOS, then the bug was backported to 2.6.32. I ran the exploit
myself in a test environment, and it works exactly as expected. Log in
as a normal user, compile 100 or so lines of C code, run the
executable and you’ve got a root shell. Scary stuff if you manage
public shell accounts."
For the exploit to work, there are a number of conditions that must be
* Linux must be compiled with PERF_EVENTS
* Shell accounts must have access to a working compiler
Obviously I checked all my servers where users have shell access, and
I was pleased to learn that none of my systems were affected :-)
The exploit can be downloaded here:
Check your systems!
Another policy in my company is to mount all user writable partitions with >noexec, nosuid, nodev options so even if the exploit binary was placed in >the system by a user or a hacker (s)he would still have find a way to >execute the exploit.
Another policy in my company is to mount all user writable partitions with >>noexec, nosuid, nodev options so even if the exploit binary was placed in >>the system by a user or a hacker (s)he would still have find a way to >>execute the exploit.
Does it work against making the exploit called from the init routine
in shared object which you could load as LD_PRELOAD in any executable
you are allowed to run?
(In Solaris, a shared object in a noexec mount cannot be loaded but
I'm not sure if Linux extend the noexec to mmap()'ed objects.)
Of course, if the user has access to perl, python, then noexec doesn't
help all that much.
|Nodes:||10 (1 / 9)|