kernel 2.6.17-2.6.24.1 vmsplice localroot exploit

[spender]

They'd have to modify the exploit to disable certain grsecurity protections or change you to the real filesystem root.

-Brad

[I_Vladimirov]

That is my point is it currently possible with id 0 group 0 to escape from chroot jail on grsecurity kernel with chroot protections on or yet is not known about this possibility.

[cormander]

is it currently possible with id 0 group 0 to escape from chroot jail on grsecurity kernel with chroot protections

As spender is saying, you can't break out unless you somehow disable the protection features. The root user can do this, unless you remove it's capability to. If sysctl is enabled, make sure you use the grsec_lock feature so root can't remove the restrictions (or at the very least, use RBAC to deny those changes unless you're authenticated as grsecurity admin). Deny the use of mknod, mount. Hell, enable all the chroot restrictions, unless you have a reason not to enable one.

I've done pretty extensive tests with C code as root in a jail on a grsecurity kernel to try to break out (with protections enabled), and I haven't been able to. So with these things enabled you're pretty safe, but don't count on just those hardening features to stay secure. Putting all your faith and trust in a single piece of software is *never* a good idea.

A grsecurity kernel, PAX, and RBAC are different pieces of software in this regard. Hide processes, make them unkillable / un-ptrace-able (even by root), deny socket/tcp connections your users shouldn't be making in the first place, etc. It's what a default deny policy is all about.

Remember that security is all about how many layers of protection you have, and how hard you want it to be to hack your system. A kernel built with the grsecurity patch, by itself, isn't the stop-all hacker solution. Use grsecurity. Enable PAX. Use the RBAC system. Encrypt your sensitive data. Keep your system up to date. Log what your users are doing.

Systems get hacked, identities get stolen, people get murdered. That's life. If it's your job on the line, show your employer that you're doing everything humanly possible to prevent it; being cautious and overly protective may prevent you from getting fired even if you do get hacked through all of your security hardening's. Look up what the SOX and PCI requirements are for security and act as if you had those organizations auditing you.

[spender]

I was referring more specifically to the attacker's capability in this case -- they're targeting a system vulnerable to the vmsplice exploit. It wouldn't be too difficult for an average attacker to add some code to the exploit to heuristically identify the location of the global grsec feature variables and turn them all off -- similar to what I did in my SELinux-disabling exploit.

-Brad

[cormander]

I was under the impression that grsecurity/PAX prevented the modification of the running kernel (if you have all the right options enabled)? When I tried vmsplice on my grsecurity 2.6.23 kernel the worst I got was a system crash; the attacker didn't actually gain root access to the machine.

Or are you talking about a case where the user uses vmsplice and they *aren't* stopped by pageexec? Or is vmsplice not stopped by pageexec..as I said, seemed to be when I attempted it.

It's been looming and glooming in my head for a while.... I think it's about time I brush up on my C code and actually get into kernel development. Have wanted to for some time now. I learned C back in college and haven't used it since, beyond patch merging and writing small fixes for some applications. Been spending so much time in the userspace portion of the system that I probably sound like a complete idiot to any kernel developer when I talk about these kinds of exploits.

[I_Vladimirov]

is it currently possible with id 0 group 0 to escape from chroot jail on grsecurity kernel with chroot protections

Remember that security is all about how many layers of protection you have, and how hard you want it to be to hack your system. A kernel built with the grsecurity patch, by itself, isn't the stop-all hacker solution. Use grsecurity. Enable PAX. Use the RBAC system. Encrypt your sensitive data. Keep your system up to date. Log what your users are doing.

Well I do not count on one software for anything, as I have mentioned before I'm building a secure environment for my web servers and so far I have reached fowling conclusions.
First line of defense is PHP or PERL code on sites served if they have include bug problems began.
Second line is Apache PHP configuration and possible vulnerabilities in them.
Turd is the linux kernel which is like cheese and need to be updated every time bug come out.
Next we come to grsecurity and chroot environment as the final defense line.

As far as my experience goes for about 10 years as administrator first line is always a opened door and administrator can't relay on web developers security so that left me with apache and PHP which I can configure fine also security patches for them do not require restart .
The next step I have performed was to set wwwroot in chroot jail on readonly partition with grsecurity enabled for the chroot.
The only scenario when I have to relay on grsecurity as final defense is when I have writable space in chroot for upload of some web stuff.
Then using the include bug attacker can upload exploit for kernel and run it to gain root privileges in chroot. which leads to my post hear.
Attacker can't damage web site until he escapes chroot so it is the final protection and the verry last one.

[spender]

grsecurity/PaX would prevent the vector used by all the published exploits for the vulnerability if either KERNEXEC or UDEREF were enabled. With that said, as the data corruption on the stack still occurs, and this data is then used by subsequent code, it's not entirely clear if without the userland dereference vector the vulnerability is still exploitable in some way, which is why the PaX team and myself have stuck to (1) It certainly stops the public exploits and any other exploits that use the same vector, and (2) though unlikely, it could be still exploitable via some other unknown vector, and (3) attempting to exploit the bug will still likely cause system instability.

-Brad