Freebsd exploit (FreeBSD-SA-08:13.protosw)

N

Near

New exploit, i'm placing the comments below:

/*
* This is a quick and very dirty exploit for the FreeBSD protosw vulnerability
* defined here:
* http://security.freebsd.org/advisories/FreeBSD-SA-08:13.protosw.asc
*
* This will overwrite your credential structure in the kernel. This will
* affect more than just the exploit's process, which is why this doesn't
* spawn a shell. When the exploit has finished, your login shell should
* have euid=0.
*
* Enjoy, and happy holidays!
* - Don "north" Bailey (don.bailey@gmail.com) 12/25/2008
*/
 
Near is pointing to a working exploit.. Not the original advisory..
 
I removed the link to the actual sploit because I don't believe we need that posted here.
 
I'm sorry, that's just silly... People need to know..
Or are you the kind of person that shoves security issues under the carpet and pretends they don't exist?

http://www.milw0rm.com/exploits/7581

A smart sysadmin will use it to test his/her system...
 
SirDice said:
A smart sysadmin will use it to test his/her system...
Click to expand...
A smarter sysadmin would instead simply read the advisory and check if the exploit's two preconditions exist on his system --

1. That the vulnerable kernel modules are actually loaded via kldstat -v | grep ng

2. If they are loaded, but users are all properly jailed, that sysctl security.jail.socket_unixiproute_only == 0 (rather than the default, 1).

I don't think there is any reason to go running malicious code (especially code with a disclaimer stating that it shatters the entire credential structure) on a machine where security is valued.

That said, it's fun having a proof-of-concept available to throw on the sandbox machines (and to demonstrate that the advisory is a serious issue). Removing the link is silly, IMHO.
 
SirDice said:
I'm sorry, that's just silly... People need to know..
Or are you the kind of person that shoves security issues under the carpet and pretends they don't exist?

http://www.milw0rm.com/exploits/7581

A smart sysadmin will use it to test his/her system...
Click to expand...

SirDice,

As they have mentioned, I didn't cover up the security advisory at all. Just removed the direct link to the sploit. If someone wants that, they can find it easily, but I believe we shouldn't link to it directly.
 
Err... You seem to have misunderstood me completely..
The advisory is linked in the first few source code lines of the exploit.

It was the removal of the link to the exploit that I objected to. It wasn't even clickable..
 
I think that does who use this os have a right to know how the exploits are coded, thats why I posted it in the main forum of the os and not in a lame hacking (scriptkidding) forum.
 
Escaping from jail is a new experience

Thanks @ Near!

Without pushing us here I might have missed the point, admitting not having read the advisory before:

[font="Fixedsys"]
III. Impact

A local user can cause the FreeBSD kernel to execute arbitrary code.
This could be used by an attacker directly; or it could be used to gain
root privilege or to escape from a jail.​
[/font]
Escaping from jail is a new experience, at least for me. Now I'm thinking about redesign of layout as consequence. This example shows, how dangerous it is to feel safe with jails. Well meant censorship doesn't make the world safer. Reading the code of an exploit does, cause it makes us think.
 
w00 it's a very old stuff ! at least 2 years no ? You're talking about the vulnerabily using links ? It is working on FreeBSD 5.5 - 6.1 which are not patched so this advisory is deprected i think.
 
Erratus said:
Thanks @ Near!

[font="Fixedsys"]
III. Impact

A local user can cause the FreeBSD kernel to execute arbitrary code.
This could be used by an attacker directly; or it could be used to gain
root privilege or to escape from a jail.​
[/font]
Escaping from jail is a new experience, at least for me. Now I'm thinking about redesign of layout as consequence. This example shows, how dangerous it is to feel safe with jails. Well meant censorship doesn't make the world safer. Reading the code of an exploit does, cause it makes us think.
Click to expand...

In the default FreeBSD jail configuration, it is not possible to break out of jails with this vulnerability, but if the setting to allow additional protocol access from jails is enabled, then it is possible. Changing that setting is generally not considered advisable because it allows use of protocols not specifically adapted for use in Jail.

Jails are a lightweight form of virtualization/containment premised on a shared kernel across protection domains--this means that a kernel vulnerability may allow access between protection domains. If your environment requires you to tolerate a kernel vulnerability, then you will need a non-kernel based virtualization system. Note that a very similar kind of reasoning applies to using hypervisors (such as Xen, VirtualBox, VMWare, etc) and vulnerabilities they might have: if you need to be able to tolerate a hypervisor vulnerability and maintain protection between two machines, then you can't use a hypervisor to keep them separate.

Hypervisors have the advantage of having a much smaller code base than an OS kernel, so there's less scope for vulnerabilities. However, they also share resources between virtual machines less effectively--it's easy to imagine hundreds or thousands of FreeBSD jails on a single system, and you definitely won't be doing a thousand Xen VMs on the same hardware, so there's definitely a trade-off to consider.
 
You must log in or register to reply here.
Back
Top