PHP ‘socket_connect()’ Function Stack Buffer Overflow – CVE-2011-1938

A nice simple vulnerability today: CVE-2011-1938. I’m amazed I didn’t see this the first time around?

The vulnerability describes a buffer overflow within the PHP ‘socket_connect()’ function. The source file for this function can be found at /ext/sockets/sockets.c and the problem was with the way that PHP handled AF_UNIX connections.


PHP_FUNCTION(socket_getpeername)
{
zval *arg1, *arg2, *arg3 = NULL;
php_sockaddr_storage sa_storage;
php_socket *php_sock;
struct sockaddr *sa;
struct sockaddr_in *sin;
#if HAVE_IPV6
struct sockaddr_in6 *sin6;
char addr6[INET6_ADDRSTRLEN+1];
#endif
struct sockaddr_un *s_un;
char *addr_string;
socklen_t salen = sizeof(php_sockaddr_storage);

if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rz|z", &arg1, &arg2, &arg3) == FAILURE) {
return;
}
...
case AF_UNIX:
memset(&s_un, 0, sizeof(struct sockaddr_un));

s_un.sun_family = AF_UNIX;
memcpy(&s_un.sun_path, addr, addr_len);
retval = connect(php_sock->bsd_socket, (struct sockaddr *) &s_un, (socklen_t) XtOffsetOf(struct sockaddr_un, sun_path) + addr_len);
break;

As you can see, the memcpy() function copies the user supplied path into “s_un.sun_path”, a mere 108 bytes (default on Linux systems) worth of space allocated for the path. The inevitable happens and we are able to overflow the buffer and take over the function return address.

The PHP development team have since patched this problem, by simply adding bounds checking to the user supplied buffer:


case AF_UNIX:
if (addr_len >= sizeof(s_un.sun_path)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Path too long", php_sock->type);
RETURN_FALSE;
}

memset(&s_un, 0, sizeof(struct sockaddr_un));

s_un.sun_family = AF_UNIX;
memcpy(&s_un.sun_path, addr, addr_len);
retval = connect(php_sock->bsd_socket, (struct sockaddr *) &s_un, (socklen_t) XtOffsetOf(struct sockaddr_un, sun_path) + addr_len);
break;
Advertisements

Learning Ruby

I have just purchased the book ‘The Ruby Programming Language’ to start my journey with Ruby. Really there are 2 reasons as to why I have chosen to learn this language:

  • Metasploit
  • Web Development
  • Metasploit has often been a bit of a black-box for me, and coming from a C / Python development background, many of the concepts seemed quite alien, forcing any bespoke exploits to be cobbled together using Python (I have lost count of the amount of times I have had to write a TCP Client in Python).

    The second reason may seem a bit strange to people in the web development world. Most people opt for PHP / Asp.NET as their core development framework, so why Ruby ? Well I learn by Doing, and what better way to practice my new found ruby skills than by throwing myself in at the deep end with some Ruby on Rails programming.

    Initial opinions of this language are favorable.. I mean who can deny that Ruby offers some sensible (but initially strange) ways of doing things. You have no idea how strange I found it to write:

    
    
    1.upto(20) { |i| print “Number #{i}\n” }
    
    
    Insead of the usual
    
    
    while(i < 20):
    print “Number %d” % (i)
    On top of this, I have the worrying abstract world of the MVC methodology to cope with when learning Rails. Whilst I have some exposure to .NET web application programming, nothing quite gets you ready for what MVC framework in a new language has to throw at you… wish me luck 🙂