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.
Outlook 要播放的声音文件采用波形音频文件格式 （WAV）。它通过 PlaySound 函数播放，该函数接收声音文件路径。PlaySound 将加载文件，对其进行解析，然后调用 soundOpen，后者将调用不同的 wave 函数，例如 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.
WAV 文件充当多个音频编解码器的容器（或包装器）。编解码器是对数据流（如图像、视频或音频）进行编码或解码的程序或代码。通常，编解码器将是脉冲编码调制 （PCM） 编码，这是一种表示采样模拟信号的简单方法。

There are three major attack surfaces where we can search for vulnerabilities:
我们可以在三个主要的攻击面上搜索漏洞：

1. WAV format parsing WAV 格式解析

2. Audio Compression Manager 
   音频压缩管理器

3. Different audio codecs 不同的音频编解码器

WAV format parsing WAV 格式解析

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.
WAV 格式分析在 winmm.dll 中的函数 soundInitWavHdr（实现 Windows 多媒体 API 的库）中实现。那里呈现的攻击面并不大，似乎已经过审查;我们没有发现任何漏洞。

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 驱动程序都必须实现 acmdStreamSize 和 acmdStreamOpen 等函数。第一个返回转换输出所需的大小（以字节为单位）;第二个创建流结构并设置相应的字段，例如解码回调函数。

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.
ACM 的攻击面并不大。然而，我们设法在该代码中发现了一个漏洞，我们将在后面的这篇博文中展示。

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:
对于最后一个攻击面，我们默认安装了不同的音频编解码器。编解码器在 WAV 文件中使用两种不同的方式指定：

1. The wFormatTag in the FORMAT chunk
   FORMAT 区块中的 wFormatTag

2. If the wFormatTag is WAVE_FORMAT_EXTENSIBLE, then SubFormat will hold the GUID for the audio codec.
   如果 wFormatTag WAVE_FORMAT_EXTENSIBLE，则 SubFormat 将保存音频编解码器的 GUID。

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.
音频信号是连续的波形。为了进行数字处理，我们需要将其从模拟信号转换为数字信号（例如，使用ADC转换器）。这种转换是模拟信号的离散化。为此，我们在均匀分布的数据点（称为样本）中对模拟信号进行多次采样。采样率（也称为采样频率）决定了每秒采集的样本数。更高的采样率可以捕获更多细节，但它们也需要更多的存储和处理。

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.
除了采样率之外，我们还有样本大小，即每个样本使用的位数。同样，样本量越大，样本的质量就越好（或更接近原始声音）。样本数量通常为每个样本 16 位或 24 位。

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.
音频编解码器基于心理声学模型。心理声学是对声音感知和听力学的科学研究——人类听觉系统如何感知各种声音。例如，人类的听觉范围在 20 Hz 到 20,000 Hz 之间。因此，为了进一步减小文件大小，音频编解码器可能会摆脱人类听不到的频率。此外，如果信号的音量不足以让人耳听到，音频编解码器可以消除信号。例如，如果小于 20 分贝，则不会听到 60 Hz 的声音。

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.
信号的分析、解释和修改是使用滤波器组执行的，滤波器组将信号划分为子带 – 不同的分量频带，可以更详细地检查和操作信号的特定部分。常用的滤波器组是DCT和多相滤波器组。

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).
作为 MP3 解码过程的一部分执行的大多数操作都很复杂，虽然从理论上讲，它们可能是寻找微妙漏洞的一个有趣（且很酷）的地方，但在实践中，许多操作（例如修改后的 DCT、多相滤波器组和混叠减少）都是在缓冲区上执行的，该缓冲区持续保存 576 个样本的值。因此，在此处发现越界写入漏洞是不合理的。一个有趣的地方是霍夫曼解码，因为它自然而然地适用于更动态的数据（而不是 576 样本缓冲区）。

Each region has its own Huffman tables (except for the 0 region), and thus samples of different frequencies are coded differently.
每个区域都有自己的霍夫曼表（0 区域除外），因此不同频率的样本编码不同。

The classification of samples into regions relies on the following variables:
将样本分类为区域依赖于以下变量：

• big_values — specifies how many total samples are in the big values region
  big_values — 指定大值区域中的总样本数

• region0_count and region1_count — partitions the big_values into subregions; subtracting their sum from big_values yields the number of samples in region2.
  region0_count 和 region1_count — 将big_values划分为多个子区域;从 big_values 中减去它们的总和，得到 Region2 中的样本数。

• part2_3length — specifies how many bits are used for scalefactors (part 2) and how many for the Huffman coding (part 3)
  part2_3length — 指定比例因子（第 2 部分）和霍夫曼编码（第 3 部分）使用的位数

The process of decoding the 576 samples happens as follows:
解码 576 个样本的过程如下：

• Decode the samples in the big_values region
  解码big_values区域中的样本

• Decode the samples in count1 region
  解码 count1 区域中的样本

• 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)
  如果处理的位数大于 part2_3length，那么我们实际上已经解码了所有输入数据，甚至超读数据——因此，从 total_samples_read 中减去 4（即丢弃这些输入位）

• If there are samples left, fill them with the 0 (this forms the 0 region)
  如果还有剩余样本，请用 0 填充它们（这形成 0 区域）

This logic in Table 1 is shown as pseudo-code.
表 1 中的此逻辑显示为伪代码。

Table 1: Pseudo-code of huffman decoding logic
表 1：霍夫曼解码逻辑的伪代码

Unfortunately, the code misses one specific edge case, which leads to an integer underflow.
不幸的是，代码遗漏了一个特定的边缘情况，这会导致整数下溢。

• Big values region size is 0
  大值区域大小为 0

• Count1 region size is 0
  Count1 区域大小为 0

• Part2_3length is 0 Part2_3length 为 0

• Bits_processed is more than 0
  Bits_processed大于 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:
在这种特定情况下，bits_processed将大于 part2_3length（在比例因子解码期间，它在解码过程之前达到非零值）。因此，代码将“抛出”最后四个示例。由于代码未处理任何样本，因此total_samples_read为 0。我们将在这里进行下溢，代码认为我们处理了 -4 个样本。现在，它将填充 0 区域，如下所示：

• Set the buffer pointer to &samples[total_samples_read]. This points to 16 bytes before the samples buffer.
  将缓冲区指针设置为 &s[total_samples_read]。这指向样本缓冲区之前的 16 个字节。

• Set the write size as 576 – total_samples_read = 576 – (-4) = 580 integers.
  将写入大小设置为 576 – total_samples_read = 576 – （-4） = 580 个整数。

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.
那么，为什么这个漏洞没有收到CVE呢？样本缓冲区是结构的一部分，样本缓冲区前面的字段是比例因子数组。这是一个包含我们已经控制的字段的数组，因此我们在这里并没有真正产生有趣的影响。

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.
在代码对样本进行反量化后，也会发生相同的漏洞。它再次填充 0 区域，这次是用去量化的缓冲区填充。想猜猜去量化缓冲区之前是什么吗？霍夫曼解码的样本缓冲液。这与我们之前看到的样本缓冲区相同，我们也可以控制它。所以，再一次，我们没有真正的影响。

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.
这些越界写入仍然存在于MP3解码器中（可通过WAV和.mp3文件访问），根据Microsoft的说法，它们将来可能会得到修复。虽然在编解码器反转过程中没有发现任何有影响的漏洞，但我们认为解码器所承载的不同复杂操作中可能隐藏着漏洞。

Second attempt: Integer overflow in the IMA ADPCM codec
第二次尝试：IMA ADPCM 编解码器中的整数溢出

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.
我们的下一个尝试将是 IMA ADPCM 编解码器，它是在 imaadp32.acm 中实现的。正如我们现在所知道的，ACM 将管理不同编解码器之间的转换。要注册编解码器，代码必须实现 ACM 函数。其中一个函数是 acmStreamSize，它返回目标缓冲区所需的字节数。

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).
IMA ADPCM 编解码器根据输入有效负载的大小 （cbSrcLength）、对齐方式 （nBlockAlign） 和每个块的样本数 （wSamplesPerBlock;表2）。

Table 2: Buffer size calculation
表 2：缓冲区大小计算

Before multiplying, the code makes sure the computation will not result in an integer overflow (Table 3).
在乘法之前，代码确保计算不会导致整数溢出（表 3）。

Table 3: Computation check intending to prevent integer overflow
表 3：旨在防止整数溢出的计算检查

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.
这种检查显然不足以防止溢出。如果 cbSrcLength / pwfxSrc->nBlockAlign 的除法中有余数，则代码将递增 （cbSrcLength / pwfxSrc->nBlockAlign） 的结果，该结果用于乘法。溢出检查不包括此增量。因此，我们仍然可以通过指定自定义值来溢出目标缓冲区长度。

We need to provide cbSrcLength that has a remainder when divided by pwfxSrc->nBlockAlign.
我们需要提供 cbSrcLength，该长度除以 pwfxSrc->nBlockAlign 时具有余数。

Table 4 shows an example of values leading to an integer overflow.
表 4 显示了导致整数溢出的值示例。

Table 4: Example of values leading to integer overflow
表 4：导致整数溢出的值示例

This results in a destination buffer of 0xE bytes, while the destination buffer should be much larger.
这会导致目标缓冲区为 0xE 字节，而目标缓冲区应大得多。

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.
尽管这看起来像是可能导致越界写入的整数溢出，但 decode 函数会正确地确保在分配的缓冲区之后不会发生写入，并且不会假定缓冲区分配了正确的大小。

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).
因此，尽管我们提供了多个示例，但实际上，当目标缓冲区已满时，代码会停止。在 AD PCM 编解码器（在 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:
这是一个可利用的问题。我们可以通过使 acmStreamSize 返回一个介于 0xffffff50 到 0xffffffff 之间的值，使 GlobalAlloc 分配一个非常小的缓冲区而不是一个很大的缓冲区。在此分配之后，我们可能导致两次越界写入：

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.
为了触发漏洞，我们需要提供一个WAV样本，其大小在解码时将大于或等于0xffffff50。虽然这听起来很容易实现，但我们在整个尝试过程中发现，在某些编解码器中可能无法实现。例如，使用 MP3 编解码器时，作为计算的一部分，需要乘以 1,152 或 576（即每帧的样本数）。该计算的结果永远不会在我们想要的范围内。

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. 
最后，我们设法使用 IMA ADP 编解码器触发了该漏洞。文件大小约为 1.8 GB。通过对计算执行数学限制运算，我们可以得出结论，IMA ADP 编解码器的最小文件大小为 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).
当有可用于动态构建漏洞的脚本引擎时，利用此类漏洞变得更加容易。由于 Windows Media Player 没有，因此利用可能更具挑战性。这可能仍然是可能的（正如 Chris Evans 在他的博客文章“推进漏洞利用：针对 Linux 桌面的无脚本 0day 漏洞利用”中所证明的那样）。但是，此漏洞更有可能在 Outlook 应用程序上下文（或其他即时消息应用程序）中被成功利用。