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

Incorrect use of network_share_name_offset for device_name in liblnk_location_information.c #38

Closed
RootUp opened this issue Sep 13, 2019 · 6 comments
Assignees
Labels

Comments

@RootUp
Copy link

RootUp commented Sep 13, 2019

As i understand from issue #13 the bug was patched in commit 63b54a3 but while fuzzing lnkinfo from the master branch, I still encounter this issue. I complied liblnk with gcc and g++ enabling ASAN the fuzzing results showed me a heap-buffer-overflow in liblnk_location_information.c

ASAN

==28798==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60b000000151 at pc 0x5581cae93d41 bp 0x7ffe7f8128c0 sp 0x7ffe7f8128b0
READ of size 1 at 0x60b000000151 thread T0
    #0 0x5581cae93d40 in liblnk_location_information_read_data /home/input0/liblnk/liblnk/liblnk_location_information.c:1328
    #1 0x5581cae948b8 in liblnk_location_information_read /home/input0/liblnk/liblnk/liblnk_location_information.c:1914
    #2 0x5581cae6e39f in liblnk_file_open_read /home/input0/liblnk/liblnk/liblnk_file.c:1282
    #3 0x5581cae6e39f in liblnk_file_open_file_io_handle /home/input0/liblnk/liblnk/liblnk_file.c:628
    #4 0x5581cae6fb86 in liblnk_file_open /home/input0/liblnk/liblnk/liblnk_file.c:346
    #5 0x5581cad4ff8a in info_handle_open_input /home/input0/liblnk/lnktools/info_handle.c:415
    #6 0x5581cad4c16b in main /home/input0/liblnk/lnktools/lnkinfo.c:265
    #7 0x7ff3e71a4b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #8 0x5581cad4f029 in _start (/home/input0/liblnk/lnktools/lnkinfo+0x48029)

0x60b000000151 is located 0 bytes to the right of 97-byte region [0x60b0000000f0,0x60b000000151)
allocated by thread T0 here:
    #0 0x7ff3e7871b50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50)
    #1 0x5581cae9471c in liblnk_location_information_read /home/input0/liblnk/liblnk/liblnk_location_information.c:1883

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/input0/liblnk/liblnk/liblnk_location_information.c:1328 in liblnk_location_information_read_data
Shadow bytes around the buggy address:
  0x0c167fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c167fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c167fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c167fff8000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c167fff8010: 00 00 00 00 00 fa fa fa fa fa fa fa fa fa 00 00
=>0x0c167fff8020: 00 00 00 00 00 00 00 00 00 00[01]fa fa fa fa fa
  0x0c167fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff8070: fa fa fa fa fa fa fa fa 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
==28798==ABORTING

I've attached poc.zip for reference, I also observed the program don't return me any SEGFAULT when I passed the above corpus (Disabling ASAN). Request maintainer to please have a look or suggest if I am missing something here.

@joachimmetz
Copy link
Member

thx, I'll have a more detailed look when time permits

judging by the code path it could be an out-of-bounds read that asan is flagging
https://github.com/libyal/liblnk/blob/master/liblnk/liblnk_location_information.c#L1328

what are your exact compiler flags?

@RootUp
Copy link
Author

RootUp commented Sep 13, 2019

Thanks for looking into this, below are my flags for compilation and make.
CC=afl-gcc CXX=afl-g++ ./configure --disable-shared
AFL_USE_ASAN=1 make

@joachimmetz joachimmetz changed the title heap-buffer-overflow in liblnk_location_information.c AddressSanitizer: heap-buffer-overflow in liblnk_location_information.c Sep 14, 2019
@joachimmetz
Copy link
Member

joachimmetz commented Oct 6, 2019

This is a OOB read of 1. Mainly triggered because ASAN being strict about this. I'll address the issue.

POCs are not considered a valid files and hit other safe guards.

Yet another example of Mitre CVE failing to do due diligence. Also see: https://nvd.nist.gov/vuln/detail/CVE-2019-17264

@joachimmetz joachimmetz changed the title AddressSanitizer: heap-buffer-overflow in liblnk_location_information.c Incorrect use of network_share_name_offset for device_name in liblnk_location_information.c Oct 6, 2019
@joachimmetz
Copy link
Member

joachimmetz commented Oct 6, 2019

The underlying issue is logical of nature. network_share_name_offset is used but this should be device_name_offset. Marking as bug solely for this reason.

Seeing the POCs are considered invalid to begin with this is mainly an issue with little/no impact.

@joachimmetz
Copy link
Member

Addressed in c4d04de

@joachimmetz
Copy link
Member

joachimmetz commented Oct 11, 2019

And again NVD showing their incompetence as well https://nvd.nist.gov/vuln/detail/CVE-2019-17264

Access Vector (AV): Network
Access Complexity (AC): Medium
Authentication (AU): None
Confidentiality (C): Partial
Integrity (I): Partial
Availability (A): Partial
Additional Information:
Victim must voluntarily interact with attack mechanism
Allows unauthorized disclosure of information
Allows unauthorized modification
Allows disruption of service
  1. the project has no network capabilities which has been indicated to NVD now multiple times Incorrect and misleading security advisories CVE-2018-12096, CVE-2018-12097 and CVE-2018-12098 #33
  2. the size of the OOB read is 1
  3. there is no proof of disclosure, also since an error path is triggered

So NVD assessment is complete BS as multiple times before. Again it is highly ironic that organizations that want to improve security of existing code bases, are run as a complete shit show.

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

No branches or pull requests

2 participants