CVE-2015-3796

CVE Descriptions

The TRE library in Libc in Apple iOS before 8.4.1 and OS X before 10.10.5 allows context-dependent attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted regular expression, a different vulnerability than CVE-2015-3797 and CVE-2015-3798.

CVE Informations

Related Weaknesses

CWE-ID	Weakness Name	Source
CWE-119	Improper Restriction of Operations within the Bounds of a Memory Buffer The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.

Metrics

Metrics	Score	Severity	CVSS Vector	Source
V2	7.5		AV:N/AC:L/Au:N/C:P/I:P/A:P	nvd@nist.gov

EPSS

EPSS is a scoring model that predicts the likelihood of a vulnerability being exploited.

EPSS Score

The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

Date	EPSS V0	EPSS V1	EPSS V2 (> 2022-02-04)	EPSS V3 (> 2025-03-07)	EPSS V4 (> 2025-03-17)
2022-02-06	–	–	8.47%	–	–
2022-04-03	–	–	8.47%	–	–
2022-06-26	–	–	8.47%	–	–
2023-01-08	–	–	10.98%	–	–
2023-03-12	–	–	–	1.57%	–
2023-06-11	–	–	–	1.25%	–
2024-02-11	–	–	–	1.25%	–
2024-06-02	–	–	–	1.25%	–
2024-12-22	–	–	–	3.18%	–
2025-02-09	–	–	–	2.68%	–
2025-01-19	–	–	–	3.18%	–
2025-02-16	–	–	–	2.68%	–
2025-03-18	–	–	–	–	19.98%
2025-03-18	–	–	–	–	19.98,%

EPSS Percentile

The percentile is used to rank CVE according to their EPSS score. For example, a CVE in the 95th percentile according to its EPSS score is more likely to be exploited than 95% of other CVE. Thus, the percentile is used to compare the EPSS score of a CVE with that of other CVE.

EPSS First.org

Date	Percentile
2022-02-06	83%
2022-04-03	93%
2022-06-26	94%
2023-01-08	95%
2023-03-12	85%
2023-06-11	84%
2024-02-11	85%
2024-06-02	86%
2024-12-22	91%
2025-02-09	9%
2025-01-19	91%
2025-02-16	9%
2025-03-18	95%
2025-03-18	95%

Exploit information

Exploit Database EDB-ID : 38263

Publication date : 2015-09-21 22h00 +00:00
Author : Google Security Research
EDB Verified : Yes

Source: https://code.google.com/p/google-security-research/issues/detail?id=428 OS X Libc uses the slightly obscure TRE regex engine [ http://laurikari.net/tre/ ] If used in enhanced mode (by passing the REG_ENHANCED flag to regcomp) TRE supports arbitrary-width hex literals. Here is the code used to parse them: /* Wide char. */ char tmp[32]; long val; int i = 0; ctx->re++; while (ctx->re_end - ctx->re >= 0) { if (ctx->re[0] == CHAR_RBRACE) break; if (tre_isxdigit_l(ctx->re[0], ctx->loc)) { tmp[i] = (char)ctx->re[0]; i++; ctx->re++; continue; } return REG_EBRACE; } ctx->re points to the regex characters. This code blindly copies hex characters from the regex into the 32 byte stack buffer tmp until it encounters either a non-hex character or a '}'... I'm still not sure exactly what's compiled with REG_ENHANCED but at least grep is; try this PoC on an OS X machine: lldb -- grep "\\\\x{`perl -e 'print "A"x1000;'`}" /bin/bash That should crash trying to read and write pointers near 0x4141414141414141 Severity Medium because I still need to find either a priv-esc or remote context in which you can control the regex when REG_ENHANCED is enabled.