Icy Silence

If you are reading this post, you may possibly be interested in the stack overflow vulnerability on the Netgear WG6024, published here.
The vulnerability can be triggered by logging into the device and changing his admin password to something a bit longer than 128 characters.
This can be done by sending a proper POST request to the web server: either via some purposely written code or bypassing client side checks on the dedicated web page on the management interface
In both ways an overly long password will be saved in flash memory and will be used during authentication, overflowing a buffer on the stack and allowing for remote code execution.
In any case password will be “permanently” changed, web server will crash at each authentication attempt and reverting to a sane situation may require resetting the whole device, losing the whole configuration.

Reset can be performed by pressing the little button on the rear side of the device for more than 20 seconds, but, another solution is possible by using the serial interface present on the access point’s board, shown in the picture below along with its pinout.



That is a 3.3V TTL serial interface that can be used by means of proper a TTL-USB converter.
Please note that the connector is originally unpopulated in the stock AP, so I needed to solder some pins on the board, in order to connect to the serial interface with my TTL-USB converter and start a normal session over the serial interface.
Once connected, password can be restored by using the nvram command and restarting the AP in the following way:

nvram set http_passwd=password && nvram commit && /sbin/reboot

The password will be changed to “password” and will not overflow the buffer anymore; the web server will not crash during authentication and the web management interface can then be accessed in the usual way.
The whole AP configuration will remain untouched and will not force the victim (you? ;)) to go through the annoying re-configuration process.

After some months spent working and performing research on embedded devices, I’m now able to present some of the results..

My submission for CONfidence 2010 has been accepted and I have been selected as a presenter for the conference, where I will be speaking on the security of access points in a talk named “(Too much) Access Points – Exploitation Roundup”.
As widely known, research on wireless devices has been focused on finding vulnerabilities, mostly, at the communication or configuration level, but not so much material is available on the actual exploitation of these devices, or, more generally, on the exploitation of embedded devices.
The talk focuses on the execution of arbitrary code on the selected targets by exploitation of binary level vulnerabilities on the Linux/MIPS platform, that is broadly used in networking embedded devices. Live demonstration of specific attack scenarios will be also provided.

Further details on the talk are available on the CONFidence 2010 website:
http://2010.confidence.org.pl/prelegenci/cristofaro-mune

..but for the real juice I suggest to come to CONFidence 2010, where lots of interesting talks will be presented, that I’m eager to attend myself 🙂
See you in Krakow!

The latest developments of the “Hijacking Mobile Data Connections” attack, that has been shown at BlackHat Europe 2009 in Amsterdam, will be presented tomorrow in a talk at the Deepsec 2009 conference by my friends from Mobile Security Lab.
The talk will step further in the in and outs and of the attack technique, exposing a good number of all the clever tricks a proficient attacker may use for maximizing the effectiveness of an hijacking attack.
I brought some ideas to the present work, so, as a co-author, I would have loved to be in Vienna and be presenting again with them, but, unfortunately, this time, I have not been able to take part to the conference.
So, this is my personal ‘In bocca al lupo’* to them for the talk 🙂

* (‘Best wishes’)

The Pidgin IRC TOPIC message DoS vulnerability has received a CVE number: CVE-2009-2703.

Pidgin 2.6.2 fixes the vulnerability and is now available for download at the Pidgin website (http://www.pidgin.im).
It worths also mentioning that Pidgin has now a specific page that provides information for dealing with Pidgin security bugs at http://pidgin.im/security
The page also reports an e-mail address for security issues communications.

Libpurple is the communication core of several IM clients, such as Pidgin and Adium, that allows communications over a great number of IM protocols.
A vulnerability that may allow a malicious IRC server to crash Pidgin, or other clients relying on libpurple, by means of a malformed TOPIC message, is present in the libpurple release of Pidgin 2.6.1, that is the latest release at the time of writing.
Such vulnerability is hereby discussed, but, for better comprehension, a brief overview of how a TOPIC message is handled in libpurple is needed.

The TOPIC message is an IRC message, used when the topic in an IRC channel (room) is changed or for retrieving information about the current topic. (ref. RFC1459 by J. Oikarinen)

The message:

:niceone TOPIC #room :relativistic binary pulsars\r\n

will be sent by the IRC server to the clients in the room, informing that the user niceone has set the topic for #room to “relativistic binary pulsars”. The CRLF sequence clearly marks the end of the message.

All the functions needed for handling IRC messages are located inside libpurple/protocols/irc in the pidgin source tree.

[1] The first function relevant to our discussion is read_input located into irc.c:

605: read input(struct irc_conn *irc, int len)

It processes the message received via the irc_conn struct by searching for the first occurrence of ‘\n’ or ‘\r\n’ and replacing its first char with ‘\0’, in order to turn the message into a null-terminated string.
The function irc_parse_msg then is called at line 625 of irc.c:

625: irc_parse_msg(irc, cur) //cur points to the string start.

[2] irc_parse_msg, located into parse.c, performs basic checks on the message syntax, and uses the command (TOPIC) for identifying the proper member into an array of structures (_irc_msgs[] in parse.c), describing the callback function for the specific message. The TOPIC message callback function is irc_msg_topic.
The structure reports also information on the information needed by the callback function, that are passed in an array of pointers.
A zero filled array of two pointers is initialized at:

691: args = g_new0(char *, strlen(msgent->format))

A ‘for loop’ parses the remaining part of the message and fills the args array, with the room name and the topic message.
Then the function irc_msg_topic is called:

723: (msgent->cb)(irc, msgent->name, tmp, args);

[3] irc_msg_topic, located in msgs.c, directly uses the information available into args array, performing no checks and calls the function irc_mirc2txt with the topic string as argument:

449: topic = irc_mirc2txt (args[1])

[4] irc_msg_mirc2txt, located into parse.c, attempts to make a copy of the strings, without performing any check on the input parameter:

466: char *result = g_strdup (string);	//args[1] is string here
467: for (i = 0, j = 0; result[i]; i++) {

and then parses it using result as a pointer, without performing checks on it.

Now, onto the vulnerability!
Let’s consider now the following message:

:hostile TOPIC\r\n #r00m :dis-topic\r\n

In [1] it will be changed by read_input into:

:hostile TOPIC\0\n #r00m :dis-topic\r\n

In [2] it will pass the semantic checks performed by irc_parse_msg (only the presence of “:” and of at least a space is required).
irc_msg_topic will be correctly identified as the callback function, but the filling of the zero initialized args vector (with room name and topic) will fail, because of the null byte right after TOPIC.
In [3] irc_msg_topic will be called with a NULL filled array as argument
In [4] g_strdup will return NULL, because args[1] is NULL.
Finally, result will then be a NULL pointer and by dereferencing it in the following for loop, the process crashes with a SEGFAULT for accessing memory at addres 0x0.

The lack of checks for NULL pointers in irc_msg_topic and irc_mirc2txt led to a NULL ptr dereference vulnerability and to a possible Denial of Service.
It worths noticing that most of the callback functions described in _irc_msgs struct DO have checks for NULL input parameters.

Same reasoning and consequences applies also to the message:

:hostile TOPIC #r00m\r\n :dis-topic\r\n

that is able to trigger the vulnerability as well.

This has been also confirmed on Windows platform, below a screenshot of location where crash occurs, located inside libirc.dll

The highlighted instruction is where segfaults occurs, it is a pointer dereference via the eax register, that holds the NULL return value of the g_strdup function.

This vulnerability can be exploited by a malicious IRC server, or by a malicious party that is mitm’ing the connection (possibly a proxy).
It is not required that the client is inside a specific room for triggering the vulnerability, the message parsing will occur upon message reception, regardless of the client status. Just the connection to the IRC server is required.
Being a NULL pointer dereference vulnerability, its exploitation leads to a Denial of Service condition, but code execution seems not to be possible in this context.

A quickly coded proof of concept code is available here