Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

heap-buffer-overflow in function readFromBMP #6

Closed
fouzhe opened this issue Jul 23, 2018 · 1 comment
Closed

heap-buffer-overflow in function readFromBMP #6

fouzhe opened this issue Jul 23, 2018 · 1 comment

Comments

@fouzhe
Copy link

fouzhe commented Jul 23, 2018

I used Clang 6.0 and AddressSanitizer to build jpeg-encoder, this file can cause heap-buffer-overflow in function readFromBMP when executing this command:

./a.out heap_buffer_overflow_readFromBMP

This is the ASAN information:

=================================================================
==328==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x616000000368 at pc 0x00000049ea5c bp 0x7fff6b99bdb0 sp 0x7fff6b99b560
WRITE of size 24 at 0x616000000368 thread T0
    #0 0x49ea5b in fread /home/fouzhe/llvm/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:978
    #1 0x51c515 in JpegEncoder::readFromBMP(char const*) /home/fouzhe/my_fuzz/jpeg_encoder/jpeg_encoder.cpp:202:17
    #2 0x51a88b in main /home/fouzhe/my_fuzz/jpeg_encoder/test.cpp:16:14
    #3 0x7f7a716a882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #4 0x41a638 in _start (/home/fouzhe/my_fuzz/jpeg_encoder/a.out+0x41a638)

0x616000000368 is located 192 bytes to the right of 552-byte region [0x616000000080,0x6160000002a8)
allocated by thread T0 here:
    #0 0x4de868 in __interceptor_malloc /home/fouzhe/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:88
    #1 0x7f7a716f5cdc  (/lib/x86_64-linux-gnu/libc.so.6+0x6dcdc)

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/fouzhe/llvm/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:978 in fread
Shadow bytes around the buggy address:
  0x0c2c7fff8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2c7fff8020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2c7fff8030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2c7fff8040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2c7fff8050: 00 00 00 00 00 fa fa fa fa fa fa fa fa fa fa fa
=>0x0c2c7fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa[fa]fa fa
  0x0c2c7fff8070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2c7fff8080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2c7fff8090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2c7fff80a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2c7fff80b0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
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
==328==ABORTING
@thejinchao
Copy link
Owner

Thank you, but this code is just an introduction to the basic JPEG algorithm, and I definitely didn’t consider security too much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants