2

I am testing Netwide Assembler(NASM) and verifying the latest bug [CVE-2018-10254] Stack-buffer-overflow (out of bound read).

I am trying to overwrite the EIP/RIP and make it crash but I don't know why it is not crashing without ASAN (google sanitizer) but after compiling it with ASAN it is crashing with ASAN generated output with some shadow bytes information. But, I am new to ASAN thing and not able to figure out the information from ASAN output. I even tried to debug the full binary line by line to examine the stack and registers but still not able to know why instruction pointer is not overwriting.

For PoC, please go through this link SourceForge NASM and download the attached PoC.

I even tried to generate some dummy PoC like:

python -c 'print "\xF2"*100' >> fuzzer

I am trying to write a simple exploit code based on this vulnerability.

ASAN output (on 32bit system):

ubu@ubuntu:~/nasm_proj/nasm-2.14rc0-20180420$ ./ndisasm -b32 ../nasm_2-14-rc0_ndisasm_stack-buffer-overflow_disasm 
00000000  7F45              jg 0x47
00000002  5C                pop esp
00000003  7E01              jng 0x6
00000005  00DB              add bl,bl
00000007  0000              add [eax],al
00000009  80042440          add byte [esp],0x40
0000000D  F2                repne
0000000E  F2                repne
0000000F  F2                repne
00000010  F2                repne
00000011  D0                db 0xd0
00000012  F2                repne
00000013  F2                repne
00000014  F2                repne
00000015  F2                repne
00000016  FE                db 0xfe
00000017  FF00              inc dword [eax]
00000019  E3FE              jecxz 0x19
0000001B  085A00            or [edx+0x0],bl
=================================================================
==7768==ERROR: AddressSanitizer: stack-buffer-overflow on address 0xbffff460 at pc 0x08053a8f bp 0xbfffebd8 sp 0xbfffebc8
READ of size 1 at 0xbffff460 thread T0
    #0 0x8053a8e in disasm disasm/disasm.c:1145
    #1 0x804a945 in main disasm/ndisasm.c:319
    #2 0xb78ce636 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x18636)
    #3 0x8048fc0  (/home/ubu/nasm_proj/nasm-2.14rc0-20180420/ndisasm+0x8048fc0)

Address 0xbffff460 is located in stack of thread T0 at offset 352 in frame
    #0 0x804924b in main disasm/ndisasm.c:81

  This frame has 6 object(s):
    [32, 33) 'rn_error'
    [96, 100) 'ep'
    [160, 164) 'synclen'
    [224, 240) 'prefer'
    [288, 352) 'buffer' <== Memory access at offset 352 overflows this variable
    [384, 640) 'outbuf'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow disasm/disasm.c:1145 disasm
Shadow bytes around the buggy address:
  0x37fffe30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x37fffe40: 00 04 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x37fffe50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x37fffe60: f1 f1 f1 f1 01 f4 f4 f4 f2 f2 f2 f2 04 f4 f4 f4
  0x37fffe70: f2 f2 f2 f2 04 f4 f4 f4 f2 f2 f2 f2 00 00 f4 f4
=>0x37fffe80: f2 f2 f2 f2 00 00 00 00 00 00 00 00[f2]f2 f2 f2
  0x37fffe90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x37fffea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x37fffeb0: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x37fffec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x37fffed0: 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
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  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
==7768==ABORTING
ubu@ubuntu:~/nasm_proj/nasm-2.14rc0-20180420$

ASAN output (on 64bit system):

[feddy@localhost nasm-2.14rc0-20180420]$ ./ndisasm -b32 ../nasm_2-14-rc0_ndisasm_stack-buffer-overflow_disasm 
00000000  7F45              jg 0x47
00000002  5C                pop esp
00000003  7E01              jng 0x6
00000005  00DB              add bl,bl
00000007  0000              add [eax],al
00000009  80042440          add byte [esp],0x40
0000000D  F2                repne
0000000E  F2                repne
0000000F  F2                repne
00000010  F2                repne
00000011  D0                db 0xd0
00000012  F2                repne
00000013  F2                repne
00000014  F2                repne
00000015  F2                repne
00000016  FE                db 0xfe
00000017  FF00              inc dword [eax]
00000019  E3FE              jecxz 0x19
0000001B  085A00            or [edx+0x0],bl
=================================================================
==17328==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff6979a120 at pc 0x00000040be78 bp 0x7fff69799940 sp 0x7fff69799930
READ of size 1 at 0x7fff6979a120 thread T0
    #0 0x40be77 in disasm disasm/disasm.c:1144
    #1 0x40301a in main disasm/ndisasm.c:320
    #2 0x7fd63f92924a in __libc_start_main (/lib64/libc.so.6+0x2324a)
    #3 0x401699 in _start (/home/feddy/Documents/nasm-2.14rc0-20180420/ndisasm+0x401699)

Address 0x7fff6979a120 is located in stack of thread T0 at offset 352 in frame
    #0 0x401912 in main disasm/ndisasm.c:81

  This frame has 6 object(s):
    [32, 33) 'rn_error'
    [96, 100) 'synclen'
    [160, 168) 'ep'
    [224, 240) 'prefer'
    [288, 352) 'buffer' <== Memory access at offset 352 overflows this variable
    [384, 640) 'outbuf'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow disasm/disasm.c:1144 in disasm
Shadow bytes around the buggy address:
  0x10006d2eb3d0: 00 00 00 00 00 00 00 00 f2 f2 f3 f3 f3 f3 00 00
  0x10006d2eb3e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006d2eb3f0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 01 f2 f2 f2
  0x10006d2eb400: f2 f2 f2 f2 04 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2
  0x10006d2eb410: f2 f2 f2 f2 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00
=>0x10006d2eb420: 00 00 00 00[f2]f2 f2 f2 00 00 00 00 00 00 00 00
  0x10006d2eb430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006d2eb440: 00 00 00 00 00 00 00 00 f3 f3 f3 f3 00 00 00 00
  0x10006d2eb450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006d2eb460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006d2eb470: 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
==17328==ABORTING
[feddy@localhost nasm-2.14rc0-20180420]$ 

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.