Type Safe Languages and Buffer Overflows

There are those of us that do most of our software development in “Type Safe” languages such as Python, Ruby and .NET.    Sometimes we smuggly look down upon languages such as C, C++ and Assembly that are not type-safe and do not provide memory protection.   You see, type-safe programming languages are "immune" to pesky problems such as buffer-offerflows.  

Lets compare the source code of simple C and Python program that assign and print a string.   First here is the Python source code.

>>> mystring="This is my string"
>>> print mystring
This is my string

You can see that with Python you don’t have to declare a variable type.  You don’t have to specify how big your string will be.   All you do is assign a string to your variable and the Python language takes care of the rest for you.   Now lets take a look at C version of that code.

char mystring[20]=“This is my string”;
printf(“%s”, mystring);

With C the first line tells the compiler that the "mystring" variable will hold 20 characters.   The next line will assign the mystring variable the value “This is my string”.    The programmer is responsible for defining both what the variable will store and what the size of variable in memory will be.     If the programmer makes a mistake and only allocates 20 bytes of memory then tries to store 30 bytes a buffer overflow condition exists.

Since the underlying Python language takes care of all of the memory management and variable typing for you, it is "immune" to these type of problems.   So type use type-safe languages and everything will be fine.  Right? 

Last week an exploit was posted to pastebin.com that exploited a buffer overflow condition in Pythons socket.recvfrom_into() function.     The function was introduced in Python 2.5 and is still vulnerable in Python 3.   Every Python program out there that uses that function is potentially vulnerable to remote exploitation.   And the exploit for this vulnerabilty is being ditributed in the wild.  But how can this be?    It is a type safe language!   

All type safe languages do offer some protection against memory manipluation attacks, but eventually they all these languages make calls to native libraries.   So while software developers in type-safe languages are usually less likely to develop code vulnerable to buffer overflows this exploit serves as a potent reminder than all languages are vulnerable to exploitation.     Security professional should always rely on defense in depth.  

The vulnerability has been patched in the latest version of the 3.3.4 Python interpreter.    Update your interpreter soon.   Verions 2.7 interpreters are a little more complicated.  The lastest interpreter is 2.7.6 and it doesn’t contain the patch for Issue #20246.    The patch is available on the website, but is not compiled into the lastest build yet.    In this case prevention isn’t possible so detection and monitoring is essential.    Keep an eye on the Python website and watch for the latest updates.

There are a couple of chances to sign up for SANS Python programming course.  Join me for Python for Penetration testers in Reston VA March 17-21 or at SANSFire in Baltimore June 23-27.

Python bug report: http://bugs.python.org/issue20246

http://www.sans.org/event/northern-virginia-2014/course/python-for-pen-testers
http://www.sans.org/event/sansfire-2014/course/python-for-pen-testers