Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Ongoing Data breach in Chicago Area Taxis

Published: 2014-03-03
Last Updated: 2014-03-03 20:23:06 UTC
by Mark Baggett (Version: 1)
0 comment(s)

Customers continue to have credit card and banking information stolen from taxi services in the Chicago area.    Customers of serveral cab services including American United, Checker, Yellow, and Blue Diamond have fallen victim to data theft over the last several weeks.  First American Bank is now advising customers to pay cash for taxi services in the area.  For more details check out Brian Krebs story.

Thanks to ISC reader Sean Thomas for the heads up.

0 comment(s)

A buffer overflow in a "Type safe" Language?

Published: 2014-03-03
Last Updated: 2014-03-03 20:10:28 UTC
by Mark Baggett (Version: 1)
4 comment(s)

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 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:

4 comment(s)
Diary Archives