Mute the Sound: Chaining Vulnerabilities to Achieve RCE on Outlook: Pt 2

Attack surfaces

The sound file to be played by Outlook is in Waveform Audio File Format (WAV). It is played through the PlaySound function, which receives the sound file path. PlaySound is going to load the file, parse it, and then call soundOpen which will call the different wave functions, such as waveOutOpen.

WAV files act as a container (or wrapper) for multiple audio codecs. A codec is a program or code that encodes or decodes a data stream (such as image, video, or audio). Usually, the codec will be pulse -code modulation (PCM) encoding, which is a simple way to represent sampled analog signals.

There are three major attack surfaces where we can search for vulnerabilities:

1. WAV format parsing

2. Audio Compression Manager 

3. Different audio codecs

WAV format parsing

WAV format parsing is implemented inside the function soundInitWavHdr in winmm.dll (the library that implements Windows Multimedia API). The attack surface presented there is not large and seems to have been reviewed; we did not find any vulnerabilities there.

Each ACM driver must implement functions such as acmdStreamSize and acmdStreamOpen. The first returns the size (in bytes) needed for the output of the transformation; the second one creates a stream struct and sets the appropriate fields, such as the decoding callback function.

ACM’s attack surface is not that large. Yet, we managed to find a vulnerability in that code, as we’ll show later in this blog post.

Different audio codecs

For the last attack surface, we have different audio codecs that are installed by default. The codec is specified in the WAV file using two different ways:

1. The wFormatTag in the FORMAT chunk

2. If the wFormatTag is WAVE_FORMAT_EXTENSIBLE, then SubFormat will hold the GUID for the audio codec.

The list of available codecs is described in the Appendix.

Audio signal processing basics

Before diving into the code, let's familiarize ourselves with some of the basics of audio signal processing. If you’re already familiar with these concepts, feel free to skip to the next section.

When we hear sound, what we actually hear is vibration that propagates through a transmission medium. Sound is the reception of those vibration waves as picked up by our ears and perceived by our brain.

An audio signal is a continuous waveform. To process it digitally, we need to convert it from an analog signal to a digital signal (e.g., using an ADC converter). This conversion is the discretization of the analog signal. To do it, we sample the analog signal multiple times in evenly spaced data points (called samples). The sampling rate (also known as sampling frequency) determines how many samples are taken per second. Higher sampling rates capture more details, but they also require more storage and processing.

Other than the sampling rate, we have the sample size, which is how many bits are used for each sample. Once again, the higher the sample size is, the better quality (or closer to the original sound) the sample is. Sample sizes are usually 16 bits or 24 bits per sample.

Audio codecs are based on psycho-acoustic models. Psycho-acoustics is the scientific study of sound perception and audiology — how the human auditory system perceives various sounds. For example, the human hearing range is between 20 Hz to 20,000 Hz. Thus, to further reduce the file size, audio codecs may get rid of frequencies that can not be heard by humans. Additionally, the audio codec can get rid of signals if their volume is not strong enough for the human ear to hear. For example, a 20 Hz sound won’t be heard if it’s less than 60 decibels.

There are many more examples of psycho-acoustic models; for example, the masking of quiet signals when they are close in frequency or time to a loud signal.

The analysis, interpretation, and modification of signals are performed using filter banks, which divide the signal into subbands — distinct bands of components that allow for a more detailed examination and manipulation of specific portions of the signal. Commonly used filter banks are the DCT and polyphase filter banks.

With this basic knowledge in mind, we can dive into researching different codecs.

Most of the operations performed as part of the MP3 decoding process are complex, and while theoretically they could be an interesting (and cool) place to look for subtle vulnerabilities, in practice many of the operations (such as the modified DCT, polyphase filterbank and  alias reduction) are carried out on a buffer that constantly holds values for 576 samples. Thus, finding an out-of-bounds write vulnerability here is not plausible. One interesting place is the huffman decoding, as naturally it works on more dynamic data (as opposed to the 576 sample buffer).

Each region has its own Huffman tables (except for the 0 region), and thus samples of different frequencies are coded differently.

The classification of samples into regions relies on the following variables:

• big_values — specifies how many total samples are in the big values region

• region0_count and region1_count — partitions the big_values into subregions; subtracting their sum from big_values yields the number of samples in region2.

• part2_3length — specifies how many bits are used for scalefactors (part 2) and how many for the Huffman coding (part 3)

The process of decoding the 576 samples happens as follows:

• Decode the samples in the big_values region

• Decode the samples in count1 region

• If the number of bits processed is greater than part2_3length, then we’ve practically decoded all input data, and even overread data — therefore, subtract 4 from total_samples_read (i.e., discard these input bits)

• If there are samples left, fill them with the 0 (this forms the 0 region)

This logic in Table 1 is shown as pseudo-code.

Table 1: Pseudo-code of huffman decoding logic

Unfortunately, the code misses one specific edge case, which leads to an integer underflow.

• Big values region size is 0

• Count1 region size is 0

• Part2_3length is 0

• Bits_processed is more than 0

In this specific case, bits_processed is going to be larger than part2_3length (it reaches a non-zero value prior to the decoding process during scalefactors decoding). Thus, the code is going to “throw” the last four samples. As the code did not process any samples, total_samples_read is 0. We’re going to have an underflow here, and the code thinks we processed -4 samples. Now, it’s going to fill the 0 region as follows:

• Set the buffer pointer to &samples[total_samples_read]. This points to 16 bytes before the samples buffer.

• Set the write size as 576 - total_samples_read = 576 - (-4) = 580 integers.

Thus, we have an out-of-bounds write directly before the samples buffer with the value zero. Neat!

So why didn’t this vulnerability receive a CVE? The samples buffer is part of a struct, and the field right before the samples buffer is the scalefactor array. This is an array with fields we already control, and thus we don’t really have an interesting impact here.

The same vulnerability happens also after the code has dequantized the samples. It once again fills the 0 region, this time with the dequantized buffer. Want to guess what’s before the dequantized buffer? The Huffman decoded sample buffer. This is the same samples buffer we saw earlier, which we also have control over. So, once again, we don’t have real impact.

Those out-of-bounds writes still exist in the MP3 decoder (both accessible through WAV and through .mp3 files), and according to Microsoft they may be fixed in the future. Although no impactful vulnerability was found during the reversing of the codec, we believe there may be vulnerabilities that hide in the different complex operations carried by the decoder.

Second attempt: Integer overflow in the IMA ADPCM codec

Our next attempt is going to be the IMA ADPCM codec, which is implemented in imaadp32.acm. As we now know, the ACM is going to manage transformations from and between different codecs. To register a codec, the code must implement ACM functions. One such function is the acmStreamSize, which returns the number of bytes needed for the destination buffer.

The IMA ADPCM codec calculates the destination buffer size based on the size of the input payload (cbSrcLength), alignment (nBlockAlign), and samples per block (wSamplesPerBlock; Table 2).

Table 2: Buffer size calculation

Before multiplying, the code makes sure the computation will not result in an integer overflow (Table 3).

Table 3: Computation check intending to prevent integer overflow

This check apparently is not enough to prevent an overflow. If there's a remainder in the division of cbSrcLength / pwfxSrc->nBlockAlign, the code increments the result of (cbSrcLength / pwfxSrc->nBlockAlign), which is used in the multiplication. The overflow check doesn't cover this incrementation. As a result, we can still overflow the destination buffer length by specifying custom values.

We need to provide cbSrcLength that has a remainder when divided by pwfxSrc->nBlockAlign.

Table 4 shows an example of values leading to an integer overflow.

Table 4: Example of values leading to integer overflow

This results in a destination buffer of 0xE bytes, while the destination buffer should be much larger.

Although this seems like a integer overflow that can lead to an out-of-bounds write, the decode function correctly makes sure that no writes happen after the allocated buffer, and does not assume that the buffer was allocated with the correct size.

So, although we provide multiple samples, in practice when the destination buffer is full, the code stops. The same behavior happens in the AD PCM codec (implemented in msadp32.acm).

This is an exploitable issue. We can cause GlobalAlloc to allocate a really small buffer instead of a large one by causing acmStreamSize to return a value between 0xffffff50 to 0xffffffff. After this allocation we can cause two out-of-bounds writes:

1. The stream header values, such as the struct size, source, and destination buffer pointers and sizes. These values are partially controllable.

2. The codec’s decoded values. These values are fully controlled.

To trigger the vulnerability we need to provide a WAV sample with a size, when decoded, that will be bigger or equal to 0xffffff50. Although this sounds easy to accomplish, we found throughout our attempts that it might not be possible to achieve in some codecs. For example, with the MP3 codec, as part of the calculation there’s a multiplication by either 1,152 or 576 (which are the number of samples per frame). The result of that calculation will never be in the range we want.

Finally, we managed to trigger the vulnerability using the IMA ADP codec. The file size is approximately 1.8 GB. By performing the math limit operation on the calculation we can conclude that the smallest possible file size with IMA ADP codec is 1 GB. 

Exploitation of such a vulnerability is made easier when there’s a scripting engine available for dynamically crafting an exploit. Since Windows Media Player doesn’t have one, exploitation can be more challenging. This might be still possible (as demonstrated by Chris Evans in his “Advancing exploitation: a scriptless 0day exploit against Linux desktops” blog post). Yet, there are more chances for this vulnerability to be successfully exploited in the Outlook application context (or other instant messaging applications).