Category Archives: Defense

openSUSE kernel sources : patching against sock_sendpage() NULL Pointer Dereference vulnerability

I am using the 2.6.30 kernel sources from Kernel:linux-next and noticed that it has not yet been patched against the ’sock_sendpage()’ NULL Pointer Dereference vulnerability.

The threat is serious as it could allow a local user to gain root privileges.

Those who compile their own 2.6.x kernel should apply this patch (from Linus, check there for more info) .

Within your kernel source folder :

$ patch -u -p0 < sock_sendpage.patch

I hope an official patch will be released soon for all kernels. I did not check if the 11.1 kernel has already been patched or not.

Promiscuous mode detection

Detectpromisc is a python script based on Scapy, that allows to detect if a computer is sniffing the network.

By nature, it is quite difficult to detect if a machine is sniffing, because it operates passively, receiving all packets from the wire but, normaly, answering only to packets destinated to itself.

There are however several methods that make the detection possible.

Some are based on the latency, because in promiscuous mode a machine will take more time to answer (packets have to be processed by the kernel, not the network card only).

Another imply to generate some tricky packets, with a correct IP but a wrong MAC address. The machine should answer only if it is in spoofing mode.

It is also possible to use source-routing with a host on the path that doesn’t route. If an answer comes back anyway, the target is sniffing.

Other methods are implemented by IDS and based on the volume of DNS requests.

Most of these methods are not necessarily reliable, easy to implement. All the ones based on IP routing are quite easy to workaround by the attacker.

Detectpromisc works exclusively at the ARP level.

According to the OS, it sends out some specific ARP packets (multicast, fake broadcast…).

In normal mode, the network card will discard theses illegitimate packets : they call it the hardware filter.
In promiscuous mode, there is no hardware filter : packets reaches directly the kernel (software filter).

Of course, according to the OS, the kernel will behave differently, but some tricked ARP packets generated by Detectpromisc will cause the sniffing machine to send an answer.

It is therefore possible to differenciate a sniffing machine from a normal machine. Plus, as it is quite reliable and OS specific, it is possible to fingerprint the target.

In practice, it has worked very well so far :

% sudo ./detect.py -i eth0 -O 192.168.222.25
Scan right index finger on UPEK TouchStrip
WARNING: No route found for IPv6 destination :: (no default route?)
192.168.222.25 : promiscuous mode card detected
probably: Linux 2.2/2.4/2.6
% sudo ./detect.py -i eth0 -O 192.168.222.26
WARNING: No route found for IPv6 destination :: (no default route?)
192.168.222.26 : promiscuous mode card detected
probably: Windows 2k/NT4

A full paper on how it works is there. Great tool, isn’t it ?

Windows Vista memory protection : defeated ?

It seems, at least according to some researchers showed it at the Black Hat conference.

Mark Dowd (IBM) and Alexander Sotirov (VMWare) found a way to bypass  the memory protection implemented in Vista to inject malicious instructions within Internet Explorer. They were able to copy any content wherever they wished on the disk.

Especially, this paper will be an interesting reading, even if it is not as simple as they say – at least for me.

Postfix : TLS not working outside my network

As I just finished setting TLS and SASL to secure the access to my Postfix server, I realized that it was working only from inside my network.

What I got from my lan :

$ telnet mars 25
Trying 192.168.222.10...
Connected to phocean.net.
Connected to phocean.net.
Escape character is '^]'.
220 phocean.net ESMTP Postfix (Debian/GNU)
220 phocean.net ESMTP Postfix (Debian/GNU)
ehlo phocean.net
ehlo phocean.net
250-phocean.net
250-phocean.net
250-PIPELINING
250-SIZE 200000000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH NTLM DIGEST-MD5 CRAM-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

I shows well that the TLS handshake is initiated.

But from this outside, I just got this weired thing :

$ telnet phocean.net 25

$ telnet phocean.net 25
Trying 81.64.194.119...
Connected to phocean.net.
Connected to phocean.net.
Escape character is '^]'.
220 **********************************************
ehlo phocean.net
ehlo phocean.net
502 5.5.2 Error: command not recognized


Of course, the firewall, a Cisco Pix one, was properly set to redirect port 25 UDP/TCP to my server.


However, I soon focused my effort on this equipment. I considered a while that the cause could be some filtering from my provider, but most probably, the problem came from the Pix.


That was not difficult to figure out : it had some protocol inspector activated for SMTP :


$ sh ru
[...]
fixup protocol smtp 25
[...]


Just after :


> no fixup protocol smtp 25


… it started to work perfectly well !!!


The engine for the SMTP protocol could not recognize the TLS handshake, considered that the SMTP session as not valid and therefore blocked it !


I can deactivate it without any fear as my Postfix server is already pretty well secured, or at least configured to reject any weired SMTP dialog.