A stack-buffer-overflow in ZydisInputPeek.

[standaside]

Description

A stack-buffer-overflow was discovered in zydis.The issue is being triggered in function ZydisInputPeek at /root/zydis/asan_build/ZydisDisasm+0x613f4.

Version

4022f22

Environment

Ubuntu 18.04，64bit

Command

Compile test program:

$cmake ..
$make

Compile test program with address sanitizer:

Update Makefile:

SET (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=address -fno-omit-frame-pointer")
SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address -fno-omit-frame-pointer ")
SET (CMAKE_LINKER_FLAGS "${CMAKE_LINKER_FLAGS} -fsanitize=address  -lasan -lstdc++ ")
SET (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsanitize=address  -lasan -lstdc++ ")

Compile program:

$mkdir asan_build &&cd asan_build
$export CC=/usr/bin/gcc
$export CXX=/usr/bin/g++
$cmake ..
$make

Result

The result of running without ASAN:

$cd build
$./ZydisDisasm -real sync_out/fuzzer04/crashes/zydisinputpeek

sub ax, 0x3030
xor byte ptr ds:[bx+si*1], dh
xor byte ptr ds:[bx+si*1], dh
......
add byte ptr ds:[bx+si*1], al
add byte ptr ds:[bx+si*1], al
Segmentation fault (core dumped)

Information obtained by using ASAN:

$cd asan_build
$./ZydisDisasm -real ../build/sync_out/fuzzer04/crashes/zydisinputpeek

sub ax, 0x3030
xor byte ptr ds:[bx+si*1], dh
xor byte ptr ds:[bx+si*1], dh
.......
xor byte ptr ds:[bx+si*1], dh
xor byte ptr ds:[bx+si*1], dh
xor byte ptr ds:[bx+si*1], dh
=================================================================
==22482==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffe410 at pc 0x5555555b53f5 bp 0x7fffffffd3b0 sp 0x7fffffffd3a0
READ of size 1 at 0x7fffffffe410 thread T0
    #0 0x5555555b53f4 in ZydisInputPeek (/root/zydis/asan_build/ZydisDisasm+0x613f4)
    #1 0x5555555c8db6 in ZydisCollectOptionalPrefixes (/root/zydis/asan_build/ZydisDisasm+0x74db6)
    #2 0x5555555d4197 in ZydisDecoderDecodeInstruction (/root/zydis/asan_build/ZydisDisasm+0x80197)
    #3 0x5555555d3c6f in ZydisDecoderDecodeFull (/root/zydis/asan_build/ZydisDisasm+0x7fc6f)
    #4 0x5555555b4f85 in main (/root/zydis/asan_build/ZydisDisasm+0x60f85)
    #5 0x7ffff71df0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #6 0x5555555b454d in _start (/root/zydis/asan_build/ZydisDisasm+0x6054d)

Address 0x7fffffffe410 is located in stack of thread T0 at offset 3264 in frame
    #0 0x5555555b4618 in main (/root/zydis/asan_build/ZydisDisasm+0x60618)

  This frame has 6 object(s):
    [48, 68) 'decoder' (line 61)
    [112, 472) 'instruction' (line 127)
    [544, 1064) 'operands' (line 128)
    [1200, 1784) 'formatter' (line 99)
    [1920, 2176) 'format_buffer' (line 131)
    [2240, 3264) 'buffer' (line 110) <== Memory access at offset 3264 overflows [this](https://github.com/standaside/stas/blob/main/zydis/zydisinputpeek) variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/root/zydis/asan_build/ZydisDisasm+0x613f4) in ZydisInputPeek
Shadow bytes around the buggy address:
  0x10007fff7c30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7c40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7c50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7c60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7c70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10007fff7c80: 00 00[f3]f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3
  0x10007fff7c90: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7ca0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7cb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7cc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7cd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==22482==ABORTING

Poc

Poc file is this.

[athre0z]

None of your PoCs reproduce on my machine. Can you provide a Dockerfile?

[standaside]

------------------ 原始邮件 ------------------ 发件人: "zyantific/zydis" ***@***.***>; 发送时间: 2022年2月18日(星期五) 晚上9:05 ***@***.***>; ***@***.******@***.***>; 主题: Re: [zyantific/zydis] A stack-buffer-overflow in ZydisInputPeek. (Issue #318) None of your PoCs reproduce on my machine. Can you provide a Dockerfile? — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.Message ID: ***@***.***>

[athre0z]

Your response is empty.

[standaside]

------------------ 原始邮件 ------------------ 发件人: "zyantific/zydis" ***@***.***>; 发送时间: 2022年2月18日(星期五) 晚上9:33 ***@***.***>; ***@***.******@***.***>; 主题: Re: [zyantific/zydis] A stack-buffer-overflow in ZydisInputPeek. (Issue #318) Your response is empty. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.Message ID: ***@***.***>

[athre0z]

Please respond via web rather than via mail.

[standaside]

I'm really sorry that I didn't understand you yesterday. My Dockerfile is this.

[athre0z]

What I was hoping for is a Dockerfile that builds Zydis, downloads your PoC and finally executes it, reproducing the issue.

I'm asking because this ensures that we're doing exactly the same things. The Dockerfile your provided is from AFL++. I built Zydis within that container and your PoC also doesn't reproduce here.

Here's how I attempted to reproduce:

FROM ubuntu:18.04

RUN apt-get update && apt-get upgrade -y
RUN apt-get install cmake build-essential git wget -y
RUN git clone --recursive --branch=v3.2.1 https://github.com/zyantific/zydis.git && mkdir zydis/build
WORKDIR zydis/build

RUN cmake "-DCMAKE_C_FLAGS=-fsanitize=address -fno-omit-frame-pointer" \
    "-DCMAKE_CXX_FLAGS=-fsanitize=address -fno-omit-frame-pointer" \
    "-DCMAKE_LINKER_FLAGS=-fsanitize=address  -lasan -lstdc++" \
    "-DCMAKE_EXE_LINKER_FLAGS=-fsanitize=address  -lasan -lstdc++" \
    ..


RUN make; true # ignore ZydisPerfTest build issue

RUN wget https://raw.githubusercontent.com/standaside/stas/main/zydis/zydisinputpeek
CMD ["/zydis/build/ZydisDisasm", "-real", "/zydis/build/zydisinputpeek"]

$ docker build -t repro .
$ docker run --rm -ti repro

It runs through without any crashes.

[standaside]

I'm sorry to bother you again. After seeing your feedback, I confirmed it again yesterday, but it still showed errors. I wonder if it's because the result is too long that you didn't finish it? The verification results are at the bottom. I specially made all the results into a document, in this link, I hope to help you.

[athre0z]

Yes, I did check the end. It doesn't crash. I invite you to take my Dockerfile and run it on your system to see whether you can reproduce it.

Since we're fuzzing the code paths that you encountered crashes in quite heavily ourselves via oss-fuzz (50+ cores fuzzing 24/7), I'd say the most likely scenario is that something is wrong with your build (mixed up wrong header / sources files, mixed up obj file from different versions, ...).

To make sure: the commit that you built is 4022f22 (v3.2.1)?

[standaside]

I'm really sorry that I didn't submit it clearly. I confirm that this is the correct version.

[mappzor]

@standaside Are you sure fuzzing is done on v3.2.1 instead of master? I reproduced this crash on master but not on v3.2.1. It's crashing because of API changes made in 4.0.

Since we're fuzzing the code paths that you encountered crashes in quite heavily ourselves via oss-fuzz (50+ cores fuzzing 24/7), I'd say the most likely scenario is that something is wrong with your build (mixed up wrong header / sources files, mixed up obj file from different versions, ...).

#264 😉

[fanghejun]

Hello, has the problem he submitted been solved in the latest version?

[flobernd]

@fanghejun Yes, have a look at the fix from mappzor.

[fanghejun]

@flobernd Thanks a lot!

[standaside]

I'm very sorry for the wrong version cognition. I think I'll look forward to the version in advance and won't repeat this problem.