Saturday, April 19, 2003

OpenFuck / ptrace-kmod exploits

Please bear with me, I retyped this on the fly from memory (the original hardcopy is about 35 miles away) and Google.

Please consider this presentation notes rather than a paper and that this is my first time doing this sort of thing.

I chose the following for my end-of-semester presentation:


  • OpenSSL 0.9.6d and below
  • modprobe race condition in 2.2.x and 2.4.x kernels


  • OpenFuck
  • ptrace-kmod

My project started as an experiment with openssl-uzi, which was discussed in class a few weeks ago. It was only available (at the time) on (

Uzi is not a stack overflow. It's a heap overflow. Stack overflows involve fixed length buffers. Heap overflows involve overflowing dynamically allowcated regions of memory (allocated by a specific application or kernal mod). (See the bottom of this page for the location of a tutorial.)

I downloaded the tool at home and played with it. It comes with a vulnerability scanner which I used here in class. The scanner reported that classroom IP's and 251 are vulnerable.

To determine what versions of which software were being run on the boxes, I used wget with the -S switch (which includes the server header in the return data).


[root@localhost openssl-uzi]# wget -S
=> 'index.html.5'
Connecting to
HTTP request sent, awaiting response...
1 HTTP/1.1 200 OK
2 Date: Mon, 14 Apr 2003 22:58:23 GMT
3 Server: Apache/1.3.19 (Unix) (Red-Hat/Linux) mod_ssl/2.8.1 OpenSSL/0.9.6 DAV/1.0.2 PHP/4.0.4pl1 mod_perl/1.24_01

A slew of good info. Try it yourself.

In doing research for the buffer overflow and the exploit, I discovered an even better (easier) exploit called OpenFuck. Better in that the programmer has figured out the required offsets for you. See the source code for the listing (quite a few more included in OpenFuck than in Uzi). Rob even found OpenFuck V2.

OpenFuck is available at:

According to the source code (most of the way down, look for the banner), OpenFuck is based on openssl-uzi's openssl-too-open exploit code.

OpenFuck was really nice. If you read the source code (or running it with no options), you get a list of Linux Distributions and their associated buffer offsets. Note: not restricted to Linux, FreeBSD is also listed.

So, for, the indicated offset is 0x5f. The syntax for the command is:

./openfuck 0x5f

Example output from the above command:

[root@localhost x]# ./openfuck 0x5f

* OpenFuck v ripped from openssl-too-open *
* If U know more offset please contact us *
* *
* offset by SPABAM added LSD shellcode *
* #highsecure *
* TNX special 2 #uname and #hackarena #SilverLords #isotk #BloodBR *
* #ION #delirium #nitr0x #coder #root #endiabrad0s #NHC #TechTeam *
* #pinchadoresweb HiTechHate DigitalWrapperz P()W GAT ButtP!rateZ *

Establishing SSL connection
cipher: 0x4078ba2c ciphers: 0x81f4568
Ready to send shellcode
Spawning shell...
bash: no job control in this shell
bash-2.04$ unset HISTFILE; uname -a; id; echo SPABAM R0X; pwd; w;
Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown
uid=48(apache) gid=48(apache) groups=48(apache)

7:18pm up 4 min, 0 users, load average: 0.00, 0.03, 0.00

(Side note: this may not work if the version of OpenSSL that you're using is older than the version you're trying to attack. A good point to research? We had problems running the exploit from various machines in the open lab.)

Note: Using this a lot against the same box tends to cause a DoS as the binary locks up and refuses to answer connection attempts.

Because chroots its Apache binary as the user apache, we get a shell account as that user.

Once, you're in, check who you are via "whoami". Most often, this will report "apache" or "nobody", depending on the configuration of the Apache server.

To get root, we'll need to employ a local exploit. It took a bit of searching around, but for this system, I found ptrace-kmod.c, which exploits a race condition in this version of the kernel. The source code for this portion of the kernel (kmod.c) is written so that it creates threads in an insecure manner. The exploit causes ptrace to fail while tracking cloned processes which allows the exploit to take control over the provileged modprobe binary. Supposedly it works against all unpatched 2.2.x and 2.4.x kernels.

When the binary fails, shellcode is inserted, and a shell is opened. Viola! You don't get a shell prompt, but it still works. (Show "whoami" and "ls").

Source at:


  • Update your patches!
  • OpenSSL is currently at version 0.9.6j for the production code and 0.9.7b for the cutting edge development stuff.
  • There's also an update for the kernel.


  • Update your patches.
  • Check for updates on a daily basis.
  • Chroot your binaries! It won't stop hackers, but it will slow most moderately talented ones and frustrate the script kiddies. Remember, the script kiddies are after the low-hanging fruit (and if I can do this, it's script-kiddie-level).
  • Log everything! Preferably at a remote, inaccessable log server (use a one-way cable, a sniffing log server, hardcode the actual server to be located other than what's listed in /etc/syslog.conf, all of the above?, etc.)
  • Use ipfw, iptables, or similar. This will prevent access to unauthorized ports if you're box does get hacked. Again, it will slow down moderately talented hackers and frustrate the script kiddies.

A good explanation of the OpenSSL heap vulnerability (with colored pictures) is available at:

The heap overflow tutorial available at:

No comments:

Post a Comment