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
Comments
|
Thx for the report, I'll have a look when time permits. |
|
@joachimmetz any update on that? |
|
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 |
|
@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. |
|
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?
|
|
This CVE flew under my radar yesterday and that's why asked for an update from your side. The description mention |
yeah but it not properly assessed, there is NO EVIDENCE of this leading to "execute arbitrary code"
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. |
|
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? |
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. |
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. |
|
Ironically Mitre points to their process/guidelines https://cve.mitre.org/cve/cna/rules.html#section_7_assignment_rules 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: Then why bother? Stop wasting everyone else their time |
|
I reported this bug in 2018, and I never applied for CVE-ID for this issue. |
|
@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.
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. |
|
@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. |
|
@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. |
|
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: |
|
@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). |
|
Glad to see that MITRE disputed CVE-2020-18900. Thank @joachimmetz for the interesting discussion that came out from this thread. |
|
@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. |
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:
And
The text was updated successfully, but these errors were encountered: