nepbabu's munge, some drivels..

If you've ever been interested in interfacing with shared libraries and DLL using Python, then there are basically three ways you can achieve it. One is to use Python/C API, second is to use SWIG and the third which I will demonstrate is to use ctypes. ctypes is a great companion to keep around as it allows one to call functions and extract data as C types from a shared library without leaving the pleasant world of Python. Without further ado, let me roll some code.


//ctypedemo.c
#include < stdio.h >
#include < stdlib.h >
#include < string.h >

char* getenv2(char * environment)
{
fprintf(stdout,"getenv2(%s)\n",environment);
fflush(0);

return getenv(environment);
}

int _init()
{
printf("%s\n","Loaded ctype shared library");
return 0;
}

#ctypedemo.py
from ctypes import *
from ctypes.util import find_library
import sys

ctype_sl = cdll.LoadLibrary('./libctypedemo.so.1') # load library

getenv_ = ctype_sl.getenv2(sys.argv[1]) # get 1st arg
ret = c_char_p(getenv_) # cast to char*
if ret:
print "\{0}={1}".format(sys.argv[1],ret.value)

#sharedlibcompile.sh
gcc -Wall -fPIC -c ctypedemo.c
gcc -shared -nostartfiles -Wl,-soname,libctypedemo.so.1 -o libctypedemo.so.1 -lc ctypedemo.o
export LD_PRELOAD=./libctypedemo.so.1

$ls
ctypedemo.c
ctypedemo.py
sharedlibcompile.sh

$./sharedlibcompile.sh
$ python ctypedemo.py PATH
Loaded ctype shared library
getenv2(PATH)

value for PATH=/usr/local/bin:/usr/local/sbin/:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/sbin:/bin:/usr/games

Hope you enjoyed the tiny intro. Feedbacks are welcome (constructive or destructive otherwise).

I was going through the details about socktress[0][1] on Slashdot[1] today. I could not believe that TCP/IP specification itself could be distorted yet again. By starting a 3-way handshake in userspace, an attacker would exhaust remote systems' connection table (similar to SYN Floods of the old days[2]) filling up with arbritrary SYN packets on the remote end. On receiving the first ACK from the remote end, the attacker would presumablyn gets hold of the packet in userspace using libpcap[3] and manipulates it however the attacker wishes because theoretically as the paper points out the kernel is suppose to panic and send RST to the remote end (the one the attacker is attacking) because fore sure kernel  didn't ask for an ACK packet now did it[4]? :-) 

The patch to fix SYN DoS in kernel[3] was invented by Daniel Bernstein. It basically did not establish (read: connection state in ESTABLISHED state/3-way handshake complete) the connection until a 3-way handshake was completed in totality - SYN, SYN/ACK, ACK and it used extra crufts to calculate if it was _really_ completed. And what about the one way before SYN flooding? I remember reading a paper about TCP/IP Sequence ID prediction. I do not remember majority of that paper but it essentially pinned down that a remote attacker could predict the sequence ID number of the next packet coming in and hence forge a prepared reply (a spoofed packet destined for somewhere else). 

All these brings me to the deep question seated within me. How much more problems/inherent weaknesses can TCP/IP itself handle? Do we need a new specification AND implementation? That I don't know and I do not have enough years on my belt to design one but it sure sounds like TCP/IP _really_  isn''t designed for today's network security standard of how easy it might be for an attacker to establish DoS. This sure isn't the 70s, 80s or the 90s when programmers were a happy hacker[6]. Thankfully, CISCO IOS and Microsoft Windows has released a patch today. :-)


[0] http://www.sockstress.com 

[1] http://it.slashdot.org/story/09/09/08/1839258/Microsoft-Cisco-Finally-Patch-TCP-DoS-Flaw


[2] http://insecure.org/stf/tcpdos/outpost24-sect-sockstress.pdf (A really good paper if you are interested in network security/programming and system administrator. It is also good for learning the intricacies of TCP/IP stack from a real-world perspective as TCP off-loading implementation _in_ hardware could possibly peruse this knowledge). 

[3] I remember someone implemented SYN cookies or "canaries"? code for Linux kernel (I read about this only couple of years ago after I got more interested in network codes). Yep. it is DJB :-) the inventor of syncookies; who can forget 44 vulnerabilities that his students found in unix kernel? :-)  http://marc.info/?t=110321890800003&r=1&w=2.

[4] If you were curious and flipped here, then you'd obviously know that the userspace started all this hohalla. Post to get an ACK'ed reply in attackers machine, having a libpcap event handler that notifies the userspace code of the incoming packets and sniff the header/payload and then reply back without ever hitting the kernels' tcp stack! This is a bit confusing to me since libpcap itself would need to interact with the kernel using normal execution syscall path via libc right? Or, am I dreaming?

[6] The original "hacker" term. Yes the one that describes someone as being curious, benign and prides in intellectual drive. Who knows some day our aliens overlords might try bringing with them a system that only an hacker understand :-)