Very Low
CVE-2019-9169
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below:
Add References:
CVE-2019-9169
MITRE ATT&CK
Collection
Command and Control
Credential Access
Defense Evasion
Discovery
Execution
Exfiltration
Impact
Initial Access
Lateral Movement
Persistence
Privilege Escalation
Topic Tags
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
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
General Information
Vendors
- canonical,
- gnu,
- mcafee,
- netapp
Products
- cloud backup,
- glibc,
- ontap select deploy administration utility -,
- steelstore cloud integrated storage -,
- ubuntu linux 16.04,
- ubuntu linux 18.04,
- ubuntu linux 19.10,
- web gateway
References
Advisory
Miscellaneous
Additional Info
Technical Analysis
Report as Exploited in the Wild
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below:
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.