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

渗透技巧 10个月前 admin
42 0 0
Mute the Sound: Chaining Vulnerabilities to Achieve RCE on Outlook: Pt 2

Introduction 介绍

Using the vulnerability we described in part 1 of this blog series, we once again have the ability to play a custom sound file on the target, abusing Outlook’s reminder sound feature. To leverage this ability and transform it into a full remote code execution (RCE), we started searching for vulnerabilities in the parsing of sound files on Windows.
使用我们在本博客系列的第 1 部分中描述的漏洞,我们再次能够在目标上播放自定义声音文件,滥用 Outlook 的提醒声音功能。为了利用此功能并将其转换为完整的远程代码执行 (RCE),我们开始在 Windows 上搜索声音文件解析中的漏洞。

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 的库)中实现。那里呈现的攻击面并不大,似乎已经过审查;我们没有发现任何漏洞。

What is Audio Compression Manager?
什么是音频压缩管理器?

The Audio Compression Manager (ACM) is the code responsible for handling cases in which the codec used in the WAV file does not use a simple PCM encoding, and thus needs to be decoded by a custom decoder. Those decoders are implemented in files with the .acm extension. One popular example is the MP3 codec, which is implemented in l3codeca.acm. Each codec is handled by a driver (which is not the same as a kernel-mode driver, but similar in function), that is registered through the ACM.
音频压缩管理器 (ACM) 是负责处理 WAV 文件中使用的编解码器不使用简单 PCM 编码,因此需要由自定义解码器解码的情况的代码。这些解码器是在扩展名为 .acm 的文件中实现的。一个流行的例子是 MP3 编解码器,它是在 l3codeca.acm 中实现的。每个编解码器都由通过 ACM 注册的驱动程序(与内核模式驱动程序不同,但功能相似)处理。

Whenever a transformation is needed, such as transforming MP3 to PCM or vice versa, the ACM comes into action and manages this transformation. When we use a WAV file where PCM is not used, the ACM will be queried to see if the codec specified in the file itself exists and can handle the transformation (Figure 1). 
每当需要转换时,例如将 MP3 转换为 PCM,反之亦然,ACM 就会开始操作并管理此转换。当我们使用未使用 PCM 的 WAV 文件时,将查询 ACM 以查看文件本身中指定的编解码器是否存在并可以处理转换(图 1)。

Mute the Sound: Chaining Vulnerabilities to Achieve RCE on Outlook: Pt 2Fig. 1: Special audio codecs are loaded using the ACM
图 1:使用 ACM 加载特殊音频编解码器

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.
有了这些基础知识,我们就可以深入研究不同的编解码器。

First attempt: Out-of-bounds write to the samples buffer
首次尝试:越界写入样本缓冲区

We first tried looking at MP3, since compared with the other codecs, MP3 is much more complex. Most of the other codecs only perform somewhat simple conversions, while MP3 has multiple steps during its decoding process (Figure 2).
我们首先尝试查看 MP3,因为与其他编解码器相比,MP3 要复杂得多。大多数其他编解码器只执行一些简单的转换,而 MP3 在解码过程中有多个步骤(图 2)。

Mute the Sound: Chaining Vulnerabilities to Achieve RCE on Outlook: Pt 2Fig. 2: MP3’s decoding process [source]
图 2: MP3 的解码过程 [源代码]

MP3 audio data is organized into a series of frames, with each frame representing a small segment of audio. A frame consists of a header and the audio data. The audio data is compressed using Huffman coding. Each frame represents exactly 1,152 frequency-domain samples per channel (mono/stereo). This is partitioned into two chunks called granules, each of 576 samples. Each frame also holds information related to its decoding, called side info (Figure 3).
MP3 音频数据被组织成一系列帧,每个帧代表一小段音频。帧由标头和音频数据组成。音频数据使用霍夫曼编码进行压缩。每帧正好代表每个通道(单声道/立体声)的 1,152 个频域样本。这被分成两个称为颗粒的块,每个块有 576 个样品。每个帧还包含与其解码相关的信息,称为侧信息(图 3)。

Mute the Sound: Chaining Vulnerabilities to Achieve RCE on Outlook: Pt 2Fig. 3: Audio mono frame structure
图3:音频单声道帧结构

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 样本缓冲区)。

MP3 Huffman decoding MP3 霍夫曼解码

Huffman coding of a granule (576 samples) is implemented using code tables (instead of a binary tree). The total frequency range from 0 to 22,050 (Nyquist frequency) is partitioned into five regions (Figure 4):
颗粒(576 个样本)的霍夫曼编码是使用代码表(而不是二叉树)实现的。从0到22,050(奈奎斯特频率)的总频率范围分为五个区域(图4):

1., 2., and 3. Three regions of “big values” — samples whose value is between -8,206 to 8,206
1.、2.和3。三个“大值”区域 — 值介于 -8,206 到 8,206 之间的样本

4. “count1 region” — quadruples of values -1, 0, or 1
4. “count1 region” — 值 -1、0 或 1 的四倍

5. “rzero region” — higher frequency values are assumed to have low amplitudes, and therefore don’t need to be coded; these values are equal to 0.
5. “Rzero Region” — 假定较高的频率值具有低振幅,因此不需要编码;这些值等于 0。

Mute the Sound: Chaining Vulnerabilities to Achieve RCE on Outlook: Pt 2Fig. 4: The partition of 576 sample’s frequency lines to the different regions [http://www.mp3-tech.org/programmer/docs/mp3_theory.pdf]
图4:576个样本的频率线到不同区域的划分[http://www.mp3-tech.org/programmer/docs/mp3_theory.pdf]

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 中的此逻辑显示为伪代码。

total_samples_read = 0;

// Decode big_values region
[redacted for brevity]

// Decode count1 region [1]
for (int i = 0; i < count1; i++) {
    samples[total_samples_read++] = huff_decode(bitstream, count1_huff_table);
}
if (bits_processed > part2_3length) [2] {
    // Overread. Throw last 4 samples
    total_samples_read -= 4;
}

// Fill rzero region with zeros
for (int i = total_samples_read; i < 576; i++) {
    samples[total_samples_read++] = 0; [3]
}

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!
因此,我们在值为零的样本缓冲区之前直接进行了越界写入。整洁!

Mute the Sound: Chaining Vulnerabilities to Achieve RCE on Outlook: Pt 2Fig. 5: The out-of-bounds write from the samples buffer
图 5:样本缓冲区的越界写入

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)。

(cbSrcLength / pwfxSrc->nBlockAlign) *(pwfxSrc->wSamplesPerBlock * pwfxDst->nBlockAlign)

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

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

SrcNumberOfBlocks = cbSrcLength / pwfxSrc->WaveFormat.nBlockAlign;
  v14 = pwfxSrc->wSamplesPerBlock * pwfxDst->nBlockAlign;

  if ( 0xFFFFFFFF / v14 < SrcNumberOfBlocks )
    return ERROR_OVERFLOW;

  IsThereRemainder = cbSrcLength % pwfxSrc->WaveFormat.nBlockAlign;

  if ( IsThereRemainder )
    ++SrcNumberOfBlocks;

  DstBufferLengthInBytes = v14 * SrcNumberOfBlocks;

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 显示了导致整数溢出的值示例。

cbSrcLength = 0x71c71c72
  pwfxSrc->nBlockAlign = 8
  pwfxSrc->wSamplesPerBlock = 9
  pwfxDst->nBlockAlign = 2

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 中实现)中发生相同的行为。

Third attempt: Integer overflow in ACM (CVE-2023-36710)
第三次尝试:ACM 中的整数溢出 (CVE-2023-36710)

Finally, we found a nice vulnerability in the ACM code. As part of the process of playing a WAV file, the function mapWavePrepareHeader in the ACM manager (implemented in msacm32.drv) is called.
最后,我们在 ACM 代码中发现了一个很好的漏洞。作为播放 WAV 文件过程的一部分,将调用 ACM 管理器中的函数 mapWavePrepareHeader(在 msacm32.drv 中实现)。

This function has an integer overflow vulnerability. It calls acmStreamSize, which calls the driver’s callback. Recall that this function returns the needed size for the destination buffer. After receiving this size, mapWavePrepareHeader adds 176 bytes (the size of the stream header that will proceed the destination buffer) with no checks of overflows. The result of this addition is passed to GlobalAlloc (Figure 6).
此函数存在整数溢出漏洞。它调用 acmStreamSize,后者调用驱动程序的回调。回想一下,此函数返回目标缓冲区所需的大小。收到此大小后,mapWavePrepareHeader 将添加 176 个字节(将进入目标缓冲区的流标头的大小),而不检查溢出。此添加的结果将传递给 GlobalAlloc(图 6)。

Mute the Sound: Chaining Vulnerabilities to Achieve RCE on Outlook: Pt 2Fig. 6: The vulnerable code in mapWavePrepareHeader
图 6:mapWavePrepareHeader 中的易受攻击代码

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 应用程序上下文(或其他即时消息应用程序)中被成功利用。

Summary 总结

This blog series covered research that began with a vulnerability that was exploited in the wild. (Read Part 1, if you haven’t already.) The research journey then continued by looking for bypasses, and finally found a companion vulnerability to chain it to in order to achieve a zero-click RCE chain. Although those vulnerabilities are fixed, attackers continue to look for similar attack surfaces and vulnerabilities that can be remotely exploited.
本博客系列涵盖了从在野外被利用的漏洞开始的研究。(如果您尚未阅读第 1 部分,请阅读。然后,研究之旅继续寻找旁路,最终找到了一个伴随的漏洞将其链接到它,以实现零点击RCE链。尽管这些漏洞已修复,但攻击者仍会继续寻找类似的攻击面和可被远程利用的漏洞。

As of now, the attack surface in Outlook that we researched still exists, and new vulnerabilities can be found and exploited. Although Microsoft patched Exchange to drop mails containing the PidLidReminderFileParameter property, we can not rule out the possibility of bypassing this mitigation.
截至目前,我们研究的 Outlook 中的攻击面仍然存在,并且可以发现和利用新的漏洞。尽管 Microsoft 修补了 Exchange 以丢弃包含 PidLidReminderFileParameter 属性的邮件,但我们不能排除绕过此缓解措施的可能性。

Appendix 附录

This site lists all of the media types and codecs available in Microsoft’s Media Foundation.
此站点列出了 Microsoft 媒体基础中提供的所有媒体类型和编解码器。

Our testing indicates that only the following codecs are available through WAV in practice:
我们的测试表明,在实践中,只有以下编解码器可以通过 WAV 获得:

1 — PCM 1 — 相变材料

2 — ADPCM

6 — A-LAW 6 — A-法律

7 — U-LAW 7 — U-法律

11 — IMA ADPCM

31 — GSM 6.10

55 — MPEG-1 Audio Layer III (MP3)
55 — MPEG-1 音频层 III (MP3)

00000003_0000_0010_8000_00aa00389b71 — IEEE Float
00000003_0000_0010_8000_00aa00389b71 — IEEE 浮点数

00000008-0000-0010-8000-00aa00389b71 — DTS Audio
00000008-0000-0010-8000-00aa00389b71 — DTS 音频

00000092-0000-0010-8000-00aa00389b71 — Dolby Digital
00000092-0000-0010-8000-00aa00389b71 — 杜比数字 (Dolby Digital) 技术

00000164-0000-0010-8000-00aa00389b71 — Microsoft WMA

 

原文始发于Ben Barnea:Mute the Sound: Chaining Vulnerabilities to Achieve RCE on Outlook: Pt 2

版权声明:admin 发表于 2023年12月21日 下午5:51。
转载请注明:Mute the Sound: Chaining Vulnerabilities to Achieve RCE on Outlook: Pt 2 | CTF导航

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...