14 DAY TRIAL // A Polish security researcher has announced that both the FreeBSD 7.2 and 6.4 releases suffer from local privilege escalation vulnerabilities that could be exploited to obtain root access. The FreeBSD team is working on patches and will release official security advisories soon.
The vulnerability affecting FreeBSD 6.4-RELEASE, as well as previous versions down to 6.0, is described as a race condition in Kqueue, the operating system's event notification interface. According to Przemyslaw Frasunek, the independent security consultant who discovered it, the flaw results in a NULL pointer dereference in kernel mode and can be used to execute arbitrary code.
Back in August, Mr. Frasunek reported a very similar issue in the kevent() system call that was patched in the 6.1-STABLE FreeBSD release. Regarding the new 6.4 vulnerability, the researcher announced that the "FreeBSD security team was notified on 29th Aug, but there is no response until now, so I won't publish any details."
He did, however, post an online video showing his proof-of-concept exploit code in action. The demo advises that unsuccessful exploitation might result in a denial of service condition. "Successful exploitation may cause kernel memory corruption leading to system crash," it warns.
According to The Register, Robert Watson, a member of the FreeBSD Core Team, confirmed that Frasunek's email was not read, probably because it got lost amongst other messages. Nevertheless, he noted that a security advisory was expected soon.
Meanwhile, the Polish researcher has posted another video demonstrating the exploitation of yet another race condition vulnerability, but this time in FreeBSD 7.2-RELEASE, the most current version of FreeBSD for production environments. Details about this new flaw are scarce at the moment, but Mr. Frasunek announced that an "official security advisory [is] pending."
Both these flaws can be used to elevate the privileges of a restricted local account to root and escape the FreeBSD jail system. An authorized account on the server is obviously not necessarily required, as a shell obtained by exploiting some other vulnerability will do just fine.