lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 14 Mar 2014 08:43:27 +0100
From: "[CXSEC]" <>
Subject: MacOSX Safari Firefox Kaspersky RegExp
	Remote/Local Denial of Service

MacOSX Safari Firefox Kaspersky RegExp Remote/Local Denial of Service

---- 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
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
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.
The same problem occurs in javascript regexp implementation on Safari and
In Kaspersky CPU Exhaustion has been observed.

- 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

  MacOSX: Memory exhaustion

- Kaspersky
  CPU Exhaustion and can't restart kaspersky again

We don't know full list of affected vendors. Anyway javascript PoC
avaliable here

--- JavaScript PoC ---
<TITLE>Firefox 27.0.1 and Safari 7.0.2 (9537.74.9)</TITLE>
<SCRIPT type="text/javascript">
var patt1=new
--- 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)
            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
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

It shouldn't be fixed in Zabbix. That's something to be addressed by glibc

In January 2014 Juniper has officially patched CVE-2010-4051 and
CVE-2010-4052 in own products.

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

--- 2. References ---

Best regards,

Content of type "text/html" skipped

Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Powered by blists - more mailing lists