Fuzzing Baseband Implementations

Today there are only a few different implementations of GSM protocol stacks, which are used in almost all mobile devices. In contrast to other popular communication technologies like wireless LAN, which received a lot of scrutiny, these implementations of the GSM protocol stack still lack a thorough and independent analysis. This is due to the fact that the required GSM hardware was very expensive in the past, and due to the lack of open source implementations of the GSM protocol stack. But with the recent availability of open source projects like OpenBSC (for a description of OpenBSC see 4.1.1.4.1) and OpenBTS²¹ it became possible to analyze the quality and reliability of these implementations.

In the context of the ASMONIA project some practical tests regarding the fuzzing of baseband implementations were made. Fuzzing means injecting various malformed protocol messages in order to test an implementation for its robustness with respect to such malformed messages. The fuzzing framework that was developed and used for this purpose is depicted in Figure 10.

21 http://openbts.sourceforge.net/

Figure 10 Fuzzing Framework Architecture

There are three main components, which serve different purposes. The first one is the combination of OpenBSC and the nanoBTS. Those are needed to run the GSM cell. They provide the infrastructure to establish a connection to the targeted mobile devices. The nanoBTS is physically connected to a computer running OpenBSC via an Ethernet connection.

The second big part also consists of two elements. On the one hand Sulley²², a framework which can be used to develop fuzzers, is used for generating and sending the data that should be tested with the phones. On the other hand there is the ipaccess-proxy which makes it possible to inject the data generated by Sulley into the GSM network in order to send it to the target. The ipaccess-proxy is located between the nanoBTS and OpenBSC.

The third component is the monitoring and logging facility. Again they consist of more than one part. First the Gammu library is used to monitor the status of the mobile devices during a fuzzing session. This information is combined with the output of Sulley, which makes it better possible to relate the crash of a phone to the certain message, which most likely caused the

22 http://code.google.com/p/sulley/

crash. Similar to that is the tcpdumpserver, which monitors and logs the traffic on the Abis interface. This offers a way to record all data exchanged between the GSM network and the mobile device and a way to draw conclusions about the status of the phone by interpreting its reactions.

The steps which are performed during a fuzzing session are described in the following: First it is necessary to establish a GSM cell and make the mobile station to be fuzzed attach to it.

After that, the tcpdumpserver has to be started which then waits for commands. Then the session is started using a Sulley script for a specific test case. Sulley prepares the messages needed for the session. Then, recording on the Abis interface is started by sending a command to the tcpdumpserver. The Sulley script automatically opens a logical channel (usually a SDCCH) to the target by the use of the OpenBSC telnet interface. If the phone is supported by Gammu, the state of the phone can be determined. After the logical channel is successfully established and the mobile device is in the correct state the next step is to open a connection to the MS/Phone on the data link layer. This is achieved by injecting a prepared Establish Request message towards the nanoBTS which then takes care of opening and maintaining this DLL connection. Now the setup is ready for the actual messages that should be sent to the target.

The general approach of fuzzing is to inject more or less random data into software through a given interface, and watch for instabilities, anomalies and other unwanted or unexpected behavior. With the described setup it is possible to inject messages on the network layer of GSM and not on lower layers of the protocol stack, as they are managed by the BTS and are therefore not available for fuzzing. This means that only L3 and higher protocol layers can be tested. Most important is the fact that nearly all information is exchanged in IEs that are either of the form Length Value (LV) or Type Length Value (TLV). In both cases the length fields are the most promising parts when it comes to detecting bugs in the implementations of GSM software stacks and therefore these fields were the main target for the fuzzing tests.

After having tested 13 mobile devices, it became apparent that the most successful way to attack a phone using the GSM protocol stack is the Short Message Service (SMS). Six of the phones, which were tested, showed errors when processing fuzzed short messages. Of the five different types of short messages which were tested, two types triggered no errors at all.

The rest of the messages triggered errors like the following (amongst others):

 SMS applications crashed when trying to read certain received messages.

 Whole phones crashed when trying to read certain messages. Sometimes these short messages could not be deleted anymore.

 Mobile devices crashed and rebooted. After the reboot they were unresponsive and unstable until all messages were deleted.

 Phones crashed just after having received certain messages.

 One phone even crashed on receiving a SMS and was broken afterwards.

Most crashes were triggered using concatenated SMSs, so it seems probable that a combination of incorrect length fields and different coding schemes lead to memory corruptions while reassembling messages parts. Another interesting result is that despite the detailed GSM specification some implementations behave differently regarding aspects like silent calls, sending of acknowledgements in the SMS delivery and Paging Requests.