DIPlib / diplib

Quantitative Image Analysis in C++, MATLAB and Python
https://diplib.org
Apache License 2.0
228 stars 50 forks source link

stack-buffer-overflow of ImageReadICS #81

Closed NigelX closed 3 years ago

NigelX commented 3 years ago

Hi

I found an crash erro.

System info: Ubuntu 20.04 : clang 10.0.0 , gcc 9.3.0

DIPliB Release v3.0.0

commit:7db848500f4cc5db676b32e9a95dcbc94d976339

[poc2.zip](https://github.com/DIPlib/diplib/files/6966702/poc2.zip) (edit: careful with this, looks malicious)


Verification steps: 1.Get the source code of DIPliB 2.Compile the DIPliB and poc.c

$ cd diplib
$ mkdir build && cd build
$ cmake ../ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_FLAGS="-O2 -fno-omit-frame-pointer -g -fsanitize=address" -DCMAKE_CXX_FLAGS="-O2 -fno-omit-frame-pointer -g -fsanitize=address"
$ make -j 32
$ sudo make install
$ cp src/libDIP.so ./
$ clang++ -g poc.cc -O2 -fno-omit-frame-pointer -fsanitize=address  -fsanitize-coverage=bb -I/usr/local/include -lDIP -L. -Wl,-rpath,. -o poc

3.run poc

$ ./poc crash.ics

asan info

=================================================================
==3089305==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd029cb0e8 at pc 0x7f3d94d20309 bp 0x7ffd029ca450 sp 0x7ffd029ca448
READ of size 8 at 0x7ffd029cb0e8 thread T0
    #0 0x7f3d94d20308 in IcsReadIcs /home/topsec/Downloads/diplib/dependencies/libics/libics_read.c:900:45
    #1 0x7f3d94ce8157 in IcsOpen /home/topsec/Downloads/diplib/dependencies/libics/libics_top.c:133:17
    #2 0x7f3d92cf4f4f in dip::(anonymous namespace)::IcsFile::IcsFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*) /home/topsec/Downloads/diplib/src/file_io/ics.cpp:262:42
    #3 0x7f3d92ce7d64 in dip::ImageReadICS(dip::Image&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, dip::DimensionArray<dip::Range> const&, dip::Range const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/topsec/Downloads/diplib/src/file_io/ics.cpp:437:12
    #4 0x4c894f in dip::ImageReadICS(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, dip::DimensionArray<dip::Range> const&, dip::Range const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /usr/local/include/diplib/file_io.h:89:4
    #5 0x4c894f in main /home/topsec/Downloads/diplib/build/poc.cc:19:19
    #6 0x7f3d919840b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    #7 0x41d5bd in _start (/home/topsec/Downloads/diplib/build/poc+0x41d5bd)

Address 0x7ffd029cb0e8 is located in stack of thread T0 at offset 3208 in frame
    #0 0x7f3d94d188af in IcsReadIcs /home/topsec/Downloads/diplib/dependencies/libics/libics_read.c:373

  This frame has 13 object(s):
    [32, 40) 'saveptr.i2073' (line 244)
    [64, 1088) 'line.i' (line 199)
    [1216, 1224) 'saveptr.i' (line 201)
    [1248, 1256) 'fp' (line 376)
    [1280, 1283) 'seps' (line 379)
    [1296, 2320) 'line' (line 380)
    [2448, 2800) 'order' (line 390)
    [2864, 2952) 'sizes' (line 391)
    [2992, 3080) 'origin' (line 392)
    [3120, 3208) 'scale' (line 393) <== Memory access at offset 3208 overflows this variable
    [3248, 3600) 'label' (line 394)
    [3664, 4016) 'unit' (line 395)
    [4080, 4088) 'saveptr' (line 398)
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 /home/topsec/Downloads/diplib/dependencies/libics/libics_read.c:900:45 in IcsReadIcs
Shadow bytes around the buggy address:
  0x1000205315c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000205315d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000205315e0: 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 f2 f2
  0x1000205315f0: f2 f2 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2
  0x100020531600: f2 f2 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2
=>0x100020531610: f2 f2 00 00 00 00 00 00 00 00 00 00 00[f2]f2 f2
  0x100020531620: f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100020531630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100020531640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 f2
  0x100020531650: f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00
  0x100020531660: 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
==3089305==ABORTING

Thank you, Product Security

NigelX commented 3 years ago

Please check this link https://cwe.mitre.org/data/definitions/121.html

crisluengo commented 3 years ago

This is an actual typo in libics. I will submit a pull request upstream.

Sorry for misjudging you. I would suggest, next time you submit broken image files in a bug report, that you explain what you did to the file and why. Dumping broken files like this without explanation is very suspicious.

I will look into these other two reports as well. Thank you.