Attacker Value
Very Low
0
CVE-2019-9169
0
Add Reference
Description
URL
Type
CVE-2019-9169
(Last updated July 09, 2020) ▾
MITRE ATT&CK
Login with GitHub to add MITRE ATT&CK tag
Add MITRE ATT&CK tactics and techniques that apply to this CVE.
MITRE ATT&CK
Select the MITRE ATT&CK Tactics that apply to this CVE
Collection
Select any Techniques used:
Command and Control
Select any Techniques used:
Credential Access
Select any Techniques used:
Defense Evasion
Select any Techniques used:
Discovery
Select any Techniques used:
Execution
Select any Techniques used:
Exfiltration
Select any Techniques used:
Impact
Select any Techniques used:
Initial Access
Select any Techniques used:
Lateral Movement
Select any Techniques used:
Persistence
Select any Techniques used:
Privilege Escalation
Select any Techniques used:
Description
In the GNU C Library (aka glibc or libc6) through 2.29, proceed_next_node in posix/regexec.c has a heap-based buffer over-read via an attempted case-insensitive regular-expression match.
Add Assessment
2
Ratings
-
Attacker ValueVery Low
-
ExploitabilityVery Low
Technical Analysis
A buffer overread in a very specific part of the glibc regex engine is something, but nothing really by itself. A read might potentially give an attacker a memory leak, but given the number of vendors who haven’t patched I don’t really believe the ‘network’ vector or the high criticality granted from the NVD CVSS. Red Hat’s assessment is more in line: https://access.redhat.com/security/cve/cve-2019-9169
To fully address this vuln, literally every Linux installation on the planet would have to be patched, which just isn’t going to happen.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportCVSS V3 Severity and Metrics
Data provided by the National Vulnerability Database (NVD)
Base Score:
9.8 Critical
Impact Score:
5.9
Exploitability Score:
3.9
Attack Vector (AV):
Network
Attack Complexity (AC):
Low
Privileges Required (PR):
None
User Interaction (UI):
None
Scope (S):
Unchanged
Confidentiality (C):
High
Integrity (I):
High
Availability (A):
High
General Information
Offensive Application
Unknown
Utility Class
Unknown
Ports
Unknown
OS
Unknown
Vulnerable Versions
n/a
Prerequisites
Unknown
Discovered By
Unknown
PoC Author
Unknown
Metasploit Module
Unknown
Reporter
Unknown
References
Additional Info
Authenticated
Unknown
Exploitable
Unknown
Reliability
Unknown
Stability
Unknown
Available Mitigations
Unknown
Shelf Life
Unknown
Userbase/Installbase
Unknown
Patch Effectiveness
Unknown
Rapid7
Looking at the actual fix, this is even less interesting than I originally thought. It’s a too-large memcmp, which even when the over read is possible, is not guaranteed unless the strings compared are almost identical so that the memcmp gets to the end. And assuming everything aligns, you’re likely to either have nothing happen (because the heap has allocated extra space in the memory page anyway), or at worse you’ll get a crash. See https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=posix/regexec.c;h=084b1222d95b62eb2930166060174ef78cb74b02;hp=91d5a797b82e2679ceab74238416de06693e46ea;hb=583dd860d5b833037175247230a328f0050dbfe9;hpb=2bac7daa58da1a313bd452369b0508b31e146637
This bug was found with ASAN enabled, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34142 and given its longevity, was unlikely to have ever been hit naturally in the wild.