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 and misleading security advisories CVE-2018-12096, CVE-2018-12097 and CVE-2018-12098 #33

Closed
joachimmetz opened this issue Jul 5, 2018 · 0 comments
Assignees

Comments

@joachimmetz
Copy link
Member

joachimmetz commented Jul 5, 2018

Incorrect and misleading security advisories

Recently I was made aware of CVE-2018-12096, CVE-2018-12097 and CVE-2018-12098.

First of all I was surprised to see this “Security Advisories” (quotation intended) seeing neither Mitre (who are responsible for issuing CVEs) nor the reporter had reached out me. Seeing I’m the maintainer of liblnk.

The reporter 熊文彬 <bear.xiong () dbappsecurity com cn> did not reach out to this project. So apparently this reporter does not care much for getting bugs fixed.

First some context

Liblnk clearly indicates it has alpha status and HEAD, which is work in progress. So it will likely contain bugs.

See Wikipedia for an explanation of alpha: https://en.wikipedia.org/wiki/Software_release_life_cycle#Alpha

You cannot expect normal (open source) development if every pre-release or development version is scrutinized as stable software. It will take time and effort to get to stable and secure.

Lack of due diligence

Neither Mitre nor the reporter did reach out to me, as the project maintainer, before they made their "advisory" (quotation intended).

@hongxuchen did the responsible thing and let me know about the reported issues via #13

Mitre and NVD and their arbitrary CVE process

The status of CVE-2018-12096, CVE-2018-12097 and CVE-2018-12098 reads:

This vulnerability is currently awaiting analysis.

How can you post an advisory if have not done your analysis?

... in liblnk through 2018-04-19 allows remote attackers to cause an information
disclosure (heap-based buffer over-read) via a crafted lnk file.

Until date I have not seen any proof how a special crafted lnk file would cause information disclosure.

Also until date Mitre has not provided any evidence of their claims after numerous requests to do so.

As seen in http://seclists.org/fulldisclosure/2018/Jun/33 CVE-2018-12096 describes an OOB read bug in libuna not in liblnk.

 READ of size 1 at 0x60200000006f thread T0
     #0 0x58f616 in libuna_utf8_string_size_from_byte_stream /home/xxx/liblnk/libuna/libuna_utf8_string.c:82:6
     #1 0x606cf0 in liblnk_data_string_get_utf8_string_size /home/xxx/liblnk/liblnk/liblnk_data_string.c:434:12
     #2 0x5ea89c in liblnk_file_get_utf8_command_line_arguments_size /home/xxx/liblnk/liblnk/liblnk_file.c:5301:6
     #3 0x52cdc9 in info_handle_command_line_arguments_fprint /home/xxx/liblnk/lnktools/info_handle.c:1792:11
     #4 0x52ecf4 in info_handle_file_fprint /home/xxx/liblnk/lnktools/info_handle.c:2624:6
     #5 0x52fc63 in main /home/xxx/liblnk/lnktools/lnkinfo.c:277:6
     #6 0x7f79fb92282f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:291
     #7 0x42c678 in _start (/home/xxx/liblnk/lnktools/lnkinfo+0x42c678)

It is now August 8, 2018 Mitre CVE has not responded to multiple inquiries (except for their auto-response). Again Mitre CVE is not giving me confidence in their ability to provide a "responsible disclosure" process (for additional context see: libyal/libevt#5).

August 8, 2018 more wild speculations by NIST NVD

More wild speculations by NIST NVD in CVE-2018-12097 and CVE-2018-12098

Access Vector (AV): Network 
Access Complexity (AC): Medium 
Authentication (AU): None 
Confidentiality (C): Partial 
Integrity (I): None 
Availability (A): None 
Additional Information: 
Victim must voluntarily interact with attack mechanism
Allows unauthorized disclosure of information
  1. There is no proof for denial-of-service, no crashes have been presented.
  2. There are no network capabilities in liblnk

Did NIST NVD reach consult the project maintainer? Of course not, why do due-diligence?

Thank you Mitre CVE and Nist NVD for having such a "responsible disclosure" process (quotation intended). It is very nice of you want the software developer to meet your standards, but when are you going to self-impose quality standards to your own work?

August 18, 2018 some rectification by NIST NVD

After reaching to NVD they did a more realistic assessment this time:

CVSS v2.0 Severity and Metrics:
Base Score: 1.9 LOW 
Vector: (AV:L/AC:M/Au:N/C:P/I:N/A:N) (V2 legend) 
Impact Subscore: 2.9 
Exploitability Subscore: 3.4

Access Vector (AV): Local 
Access Complexity (AC): Medium 
Authentication (AU): None 
Confidentiality (C): Partial 
Integrity (I): None 
Availability (A): None 
Additional Information: 
Victim must voluntarily interact with attack mechanism
Allows unauthorized disclosure of information

However no proof has been provided for the claims "Allows unauthorized disclosure of information", seeing this is similar to libyal/libfsntfs#8. I likely have to "thank" the reporter and Mitre CVE to be unable to provide impact assessments that are backed by proof.

Also see

@joachimmetz joachimmetz self-assigned this Jul 5, 2018
@libyal libyal locked and limited conversation to collaborators Jul 5, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant