It’s been a long time since we’ve heard about a problem with FreeBSD, partially because the mass of people using it isn’t that large and secondly because BSD tends to be pretty secure as operating systems go.

It’s a pretty serious flaw this time with root escalation, thankfully it’s only a local exploit though and not remotely exploitable.

Although a user could get user access on the system through an exploit in a web facing application, and use some kind of PHP/Python web shell to exploit and get root.

A security researcher has uncovered a security bug in the FreeBSD operating system that allows users with limited privileges to take full control of underlying systems.

The bug in FreeBSD’s kqueue notification interface makes it trivial for those with local access to a vulnerable system to gain full root privileges, Przemyslaw Frasunek, an independent security consultant in Poland, told The Register. It affects versions 6.0 through 6.4 of the operating system, the last two versions of which enjoy wide use and continue to be supported by the FreeBSD Foundation.

Versions 7.1 and and beyond are not vulnerable.

With a lot of people still using FreeBSD 6.3 and 6.4, amongst the FreeBSD community I’d say this could be quite a widespread problem.

A lot of BSD boxes are used for web hosting too, so I’d imagine a lot have SSH access enabled giving people local access and the capability of executing this exploit.

Those exploiting the bug must first have local access to a vulnerable system, either as a legitimate user or by exploiting some other flaw (say, a vulnerable PHP script) that gives an attacker a toe-hold in to the targeted system. Frasunek said the vulnerability is trivial to exploit, as a video he posted here suggests.

The bug is the result of a race condition in the FreeBSD kqueue that leads to a NULL pointer dereference in kernel mode. Attackers can cause vulnerable systems to run malware by putting the code in a memory page mapped to address 0×0.

Frasunek said he notified FreeBSD officials on August 29 and has yet to get a response. Robert Watson, a FreeBSD Core Team member, told El Reg that it appeared the email had gotten “lost in the slew” and he expected an advisory to be issued soon.

If you’re using the latest production release (at this time 7.2) you aren’t vulnerable to this problem, I hope to see them backport the patch to the previous versions as they still have a sizable following.

You should see an advisory hitting the mailing lists soon, and I’d expect it to be fixed pretty quickly too.

Beware if you are using FreeBSD and have users with local access you don’t trust.

Source: The Register

Or half-open scanning technique is the first of three to come series about stealth scanning… The other two are Xmas/Fin/Null and idle/zombie scan techniques…

Intro
This is a series of three to come articles about stealth scanning, everything that I am going to present is hping oriented so if you want to learn this techniques you’d better get a copy of hping.
This method is invoked when you add nmap the -sS parameter… so let’s start…

3 Way Handshake
If you didn’t know a tcp connection is based on a method called the three way handshake, that goes like this:

[host] syn flagged packet ———> [destination] receives packet
[destination] syn-ack flagged packet ———> [host] receives packet
[host] ack flagged packet ———> [destination] receives packet [connection established]

This is the methodology of a TCP connection, just upon a successful execution of this section a real connection is done… You probably can see a weak point in this method, can’t you. For every sent packet the host (and destination) waits a period of time for the next packet. If you can send really fast spoofed syn packets you can DoS a target in no time, this is the oldest DoSing method ever known to man (and women) =)

SYNner
Firstly let’s see what happens if we hit a closed port, try out the following command (and result after it):

C:\\>hping -p 81 -S lx.ro
HPING (XPSP2) lx.ro (SiS 900 PCI Fast Ethernet Adapter -
Packet Scheduler Miniport 81.181.218.80): S set, 40 headers + 0
data bytes

len=46 ip=81.181.218.80 ttl=54 DF id=0 sport=81 flags=RA seq=0
win=0 rtt=70.0 ms
len=46 ip=81.181.218.80 ttl=54 DF id=0 sport=81 flags=RA seq=1
win=0 rtt=20.0 ms
len=46 ip=81.181.218.80 ttl=54 DF id=0 sport=81 flags=RA seq=2
win=0 rtt=30.0 ms
len=46 ip=81.181.218.80 ttl=54 DF id=0 sport=81 flags=RA seq=3
win=0 rtt=40.0 ms

As you can see on an unsuccessful port scan we get a Reset-Acknowledge , which tels us, as already mentioned, that we hit a closed port…
Now for the moment we all were waiting for:

C:\\>hping -p 80 -S lx.ro
HPING (XPSP2) lx.ro (SiS 900 PCI Fast Ethernet Adapter -
Packet Scheduler Miniport 81.181.218.80): S set, 40 headers + 0
data bytes

len=46 ip=81.181.218.80 ttl=54 DF id=0 sport=80 flags=SA seq=0
win=5840 rtt=30.0 ms
len=46 ip=81.181.218.80 ttl=54 DF id=0 sport=80 flags=SA seq=0
win=5840 rtt=0.0 ms
len=46 ip=81.181.218.80 ttl=54 DF id=0 sport=80 flags=SA seq=1
win=5840 rtt=50.0 ms
len=46 ip=81.181.218.80 ttl=54 DF id=0 sport=80 flags=SA seq=0
win=5840 rtt=0.0 ms

As you can see we hit an open port… If you weren’t attentive till now a syn-ack flag means an open port, half-way connected…

Epilogue
Nowadays this method isn’t as stealthy as it was years ago, because now firewalls most often drop unwanted packets or sees them as pre-DoS syn packets…

More info about TCP :: www.rhyshaden.com
(first useful link that I have found with google)

Next >> Xmas/Fin/Null