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

OOB read of 1 and 2 in libexe_io_handle_read_coff_optional_header of libexe 20180812 #1

Closed
wcventure opened this issue Sep 1, 2018 · 19 comments
Assignees

Comments

@wcventure
Copy link

Multiple heap-buffer-overflow errors inside function libexe_io_handle_read_coff_optional_header in libexe_io_handle.c

We found with our fuzzer multiple heap-buffer-overflow errors inside function libexe_io_handle_read_coff_optional_header. The version we use is "exeinfo 20180812".

These can be triggered when compiled with address sanitizer and run with exe file.

Here is the POC files:
POC_files.zip

For example:

=================================================================
==109161==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000051 at pc 0x7f84e022ab5d bp 0x7fff952dad00 sp 0x7fff952dacf0
READ of size 1 at 0x602000000051 thread T0
    #0 0x7f84e022ab5c in libexe_io_handle_read_coff_optional_header /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_io_handle.c:1093
    #1 0x7f84e022c06d in libexe_io_handle_read_coff_header /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_io_handle.c:985
    #2 0x7f84e022c5f2 in libexe_io_handle_read_pe_header /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_io_handle.c:754
    #3 0x7f84e022ca2d in libexe_io_handle_read_extended_header /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_io_handle.c:429
    #4 0x7f84e022d306 in libexe_io_handle_read_file_header /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_io_handle.c:262
    #5 0x7f84e022212a in libexe_file_open_read /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_file.c:865
    #6 0x7f84e0223454 in libexe_file_open_file_io_handle /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_file.c:660
    #7 0x7f84e0223d7e in libexe_file_open /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_file.c:379
    #8 0x405cc3 in info_handle_open_input /home/wcventure/Documents/Fuzzing_Object/libexe/exetools/info_handle.c:301
    #9 0x402c7e in main /home/wcventure/Documents/Fuzzing_Object/libexe/exetools/exeinfo.c:260
    #10 0x7f84dfdec82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #11 0x403708 in _start (/home/wcventure/Documents/Fuzzing_Object/libexe/build/bin/exeinfo+0x403708)

0x602000000051 is located 0 bytes to the right of 1-byte region [0x602000000050,0x602000000051)
allocated by thread T0 here:
    #0 0x7f84e07e0b90 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb90)
    #1 0x7f84e022738c in libexe_io_handle_read_coff_optional_header /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_io_handle.c:1048

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_io_handle.c:1093 in libexe_io_handle_read_coff_optional_header
Shadow bytes around the buggy address:
  0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c047fff8000: fa fa 00 00 fa fa 04 fa fa fa[01]fa fa fa fa fa
  0x0c047fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8050: 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
==109161==ABORTING

And

=================================================================
==37887==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60e0000001ca at pc 0x7f9a68633229 bp 0x7ffd49fad890 sp 0x7ffd49fad880
READ of size 2 at 0x60e0000001ca thread T0
    #0 0x7f9a68633228 in libexe_io_handle_read_coff_optional_header /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_io_handle.c:1812
    #1 0x7f9a6863406d in libexe_io_handle_read_coff_header /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_io_handle.c:985
    #2 0x7f9a686345f2 in libexe_io_handle_read_pe_header /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_io_handle.c:754
    #3 0x7f9a68634a2d in libexe_io_handle_read_extended_header /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_io_handle.c:429
    #4 0x7f9a68635306 in libexe_io_handle_read_file_header /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_io_handle.c:262
    #5 0x7f9a6862a12a in libexe_file_open_read /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_file.c:865
    #6 0x7f9a6862b454 in libexe_file_open_file_io_handle /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_file.c:660
    #7 0x7f9a6862bd7e in libexe_file_open /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_file.c:379
    #8 0x405cc3 in info_handle_open_input /home/wcventure/Documents/Fuzzing_Object/libexe/exetools/info_handle.c:301
    #9 0x402c7e in main /home/wcventure/Documents/Fuzzing_Object/libexe/exetools/exeinfo.c:260
    #10 0x7f9a681f482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #11 0x403708 in _start (/home/wcventure/Documents/Fuzzing_Object/libexe/build/bin/exeinfo+0x403708)

0x60e0000001ca is located 10 bytes to the right of 160-byte region [0x60e000000120,0x60e0000001c0)
allocated by thread T0 here:
    #0 0x7f9a68be8b90 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb90)
    #1 0x7f9a6862f38c in libexe_io_handle_read_coff_optional_header /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_io_handle.c:1048

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/wcventure/Documents/Fuzzing_Object/libexe/libexe/libexe_io_handle.c:1812 in libexe_io_handle_read_coff_optional_header
Shadow bytes around the buggy address:
  0x0c1c7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff8000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c1c7fff8010: 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa
  0x0c1c7fff8020: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c1c7fff8030: 00 00 00 00 00 00 00 00 fa[fa]fa fa fa fa fa fa
  0x0c1c7fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff8080: 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
==37887==ABORTING
@joachimmetz
Copy link
Member

Thx for the report, I'll have a look when time permits.

@StayPirate
Copy link

@joachimmetz any update on that?

@joachimmetz
Copy link
Member

joachimmetz commented Aug 23, 2021

Thx for the reminder, so based on the ASAN output, this is an OOB read of 1 or 2, which depending on compiler+flags could be a non-issue. I'll see if the POC still reproduces since I started using ossfuzz a while ago.

However note that this project is, as per README, still experimental

@joachimmetz
Copy link
Member

@StayPirate I'm closing this, I ran a 64-bit asan build of HEAD against the attached POC files with exeinfo. ASAN flags no OOB read issues. E.g.

exeinfo 20210701

Unable to open: /tmp/crashes/id:000011,sig:06,src:000015,op:int8,pos:252,val:+127.
libexe_coff_optional_header_read_data: invalid data size value too small.
libexe_coff_optional_header_read_file_io_handle: unable to read COFF optional header at offset: 256 (0x00000100).
libexe_io_handle_read_pe_header: unable to read COFF optional header.
libexe_io_handle_read_extended_header: unable to read PE/COFF header.
libexe_io_handle_read_file_header: unable to read extended header.
libexe_file_open_read: unable to read file header.
libexe_file_open_file_io_handle: unable to read from file handle.
libexe_file_open: unable to open file: /tmp/crashes/id:000011,sig:06,src:000015,op:int8,pos:252,val:+127.
info_handle_open_input: unable to open input file.

@joachimmetz joachimmetz changed the title Multiple heap-buffer-overflow errors inside function libexe_io_handle_read_coff_optional_header in libexe_io_handle.c OOB read of 1 in libexe_io_handle_read_coff_optional_header Aug 23, 2021
@joachimmetz joachimmetz self-assigned this Aug 23, 2021
@joachimmetz joachimmetz changed the title OOB read of 1 in libexe_io_handle_read_coff_optional_header OOB read of 1 and 2 in libexe_io_handle_read_coff_optional_header of libexe 20180812 Aug 23, 2021
@joachimmetz
Copy link
Member

joachimmetz commented Aug 24, 2021

And yet another useless and incorrect CVE report https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-18900. When is Mitre CVE going to take their responsibility in doing some quality assurance? Or is their only goal in life to add more administrative burden on people and make effective information security impossible?

A heap-based buffer overflow in the libexe_io_handle_read_coff_optional_header function of libyal libexe before 20181128 allows attackers to execute arbitrary code.
  1. There is no proof this is a vulnerability, weakness yes, vulnerability depends on many more factors no data was provided about this
  2. an OOB read does not necessary lead to execute arbitrary code, not sure who filed this but it looks like Mitre has not done any due diligence again. Mitre and such reports remain to be f-ing useless and wasting peoples time to actual help secure software

@StayPirate
Copy link

This CVE flew under my radar yesterday and that's why asked for an update from your side. The description mention before 20181128, I think this is related to @wcventure first comment when he said The version we use is "exeinfo 20180812".
Since many packagers build your tool based on release tags and you tested it against the HEAD reference, could you confirm the same bug is also mitigated at the last release tag (20210424)?

@joachimmetz
Copy link
Member

joachimmetz commented Aug 24, 2021

This CVE flew under my radar yesterday and that's why asked for an update from your side

yeah but it not properly assessed, there is NO EVIDENCE of this leading to "execute arbitrary code"
this is yet another example of the incompetence of Mitre to provide a reliable and responsible vulnerability reporting process

Since many packagers build your tool based on release tags and you tested it against the HEAD reference

Why what value does this administrative nonsense add? this project does not recommend people to package or redistribute it in the first place (experimental, pre-releases only). Nor did anyone of these packagers inquired/assessed risk before deciding to package it. This is the responsibility of packagers to ensure binaries are safely build, up to date and come with the necessary additional security controls. This project has no direct control over that.

@StayPirate
Copy link

There are community managed repositories in some distros where your tools can be packaged by anyone. I agree with you that the packager first and the end-user after are responsible for what they package/install. I also agree that this bug requires much more research before being flagged as "arbitrary code execution". Anyway, this bug can for sure leads to a partial deny-of-service since the process can be crashed by passing a user-controlled input. I'm not aware of any rule that prohibits assigning CVEs to open-source projects even in their experimental phase.

In other words, even if I agree with you about the poor accuracy of this MITRE report, soon vulnerability scanners and many other security-related tools will ingest this CVE ID and will start throwing alerts about that. Some steps can be taken here to make this smooth for the future, like point-out from which release this bug has been mitigated or reaching out MITRE to properly update the report. What do you think?

@joachimmetz
Copy link
Member

In other words, even if I agree with you about the poor accuracy of this MITRE report, soon vulnerability scanners and many other security-related tools will ingest this CVE ID and will start throwing alerts about that.

Agree, this process is broken by design for Open Source. If you want to read my previous experience on how useless Mitre and CVE are for Open Source, PTAL libyal/libevt#5. And Mitre knows, but does not take responsibility. So in the end they are making information security worse for everyone in the process.

FYI I've filed a dispute with Mitre already.

@joachimmetz
Copy link
Member

joachimmetz commented Aug 24, 2021

Anyway, this bug can for sure leads to a partial deny-of-service since the process can be crashed by passing a user-controlled input.

There is also no proof of that either. For a small OOB-read to be any vulnerability impact it would either need to lead to accessing a memory range that is not allowed (leading to crash) or if the information can be used to control further execution. I've not seen any analysis of both these scenarios in the context of this issue or any additional report about this. For now this is pure speculation.

For more context on an OOB-read see Mitre's own CWE definition: https://cwe.mitre.org/data/definitions/125.html There are many "can" and "might" and other speculative terminology in this definition, for which I've not seen any facts to back up these conditions actually apply.

A lot of time is wasted with these speculations, while tooling can be build / exists to give a decent impact assessment of a weakness in source in existing binaries.

@joachimmetz
Copy link
Member

joachimmetz commented Aug 24, 2021

Ironically Mitre points to their process/guidelines https://cve.mitre.org/cve/cna/rules.html#section_7_assignment_rules

7.4 Requirements for Assigning a CVE ID
Not all vulnerabilities receive a CVE ID. CVE IDs are meant to help two or more parties communicate about a vulnerability. If assigning a CVE ID would not achieve this goal, then a CVE ID should not be assigned. The following rules are meant to ensure the goal is achieved.

Apparently Mitre considers copy-pasting unverified reports without checking with key stakeholder like project maintainers as sufficient "communication about a vulnerability". Unclear to me how that is helping to make open source software more secure, if you don't include the project maintainers ¯\_(ツ)_/¯

And an additional statement from Mitre confirms this:

We do not have to resources to confirm beyond the researchers good faith attempt.

Then why bother? Stop wasting everyone else their time

@wcventure
Copy link
Author

I reported this bug in 2018, and I never applied for CVE-ID for this issue.
I don't know why it is necessary to assign a CVE-ID recently.

@joachimmetz
Copy link
Member

joachimmetz commented Aug 25, 2021

@wcventure thx for confirming, I did not suspect you to have filed for a CVE since you reported this in 2018 as a clean issue report without speculation, and the CVE was filed in 2020 with very speculative claims. Thx again for raising the issue back in 2018.

I don't know why it is necessary to assign a CVE-ID recently.

Me neither, my suspicion, some people are obsessed with having all "vulnerabilities" tracked as CVEs. Not realizing that they are adding a huge administrative burden decremental to making things actually secure.

@hongxuchen
Copy link

@joachimmetz Agreed. personally I would like MITRE to uncover the CVE requesters' information to classified people (e.g., maintainers of certain projects) before actually assigning the CVE IDs. And for those keep requesting low-quality CVEs, there should be a punishment mechanism for them.

@joachimmetz
Copy link
Member

joachimmetz commented Aug 25, 2021

@hongxuchen IMHO for most FOSS rarely a CVE is needed. There are good solutions to uncover a lot of the missing sanity checks e.g. OSSFuzz. I would argue that a CVE only makes sense for critical, proven and reproducible vulnerabilities in core and widely used FOSS component and having to coordinate that across many different consumers. Most/Some of these have their own CNA that knows what they are doing and not relying on Mitre.

Not sure, but some recent efforts like https://github.com/ossf/scorecard might be more beneficial for FOSS at scale.

@joachimmetz
Copy link
Member

joachimmetz commented Aug 28, 2021

No additional validation by Nist NVD either https://nvd.nist.gov/vuln/detail/CVE-2020-18900, or vulndb https://vuldb.com/?id.181207 both of which apparently did not even get the CWE classification right. The ASAN output clearly indicates:READ of size 1

@joachimmetz
Copy link
Member

joachimmetz commented Sep 11, 2021

@wcventure FYI about https://wcventure.github.io/ a fuzzer finding is NOT a vulnerability assessment without a proper impact/risk analysis. Stop referring to CVE-2020-18900 as a vulnerability or some of the others without the evidence to back it up; stop spreading misinformation. This is code weakness, a bug, without an actual deployed binary to map it against it is a purely hypothetical issue. A vulnerability claim/report should include the conditions under which a weakness introduces tangible risk, until date this information has not been presented.

Also change "Heap Buffer Overflow" (https://cwe.mitre.org/data/definitions/122.html) into a more accurate description of the issue namely "Out-of-bound read" (https://cwe.mitre.org/data/definitions/125.html).

@StayPirate
Copy link

Glad to see that MITRE disputed CVE-2020-18900. Thank @joachimmetz for the interesting discussion that came out from this thread.

@joachimmetz
Copy link
Member

joachimmetz commented Sep 17, 2021

@StayPirate to be explicit Mitre did not do shit. I disputed it, they just updated the information after multiple back-and-forths with them. However they should step up, take responsibility and fix this broken process that they impose on others.

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

4 participants