hey guys,
i'm just going through the latest batch of CVE's and it doesn't look like
there's a fix for CVE-2007-4840 yet:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4840
Description
PHP 5.2.4 and earlier allows context-dependent attackers to cause a denial of
service (application crash) via (1) a long string in the out_charset
parameter to the iconv function; or a long string in the charset parameter to
the (2) iconv_mime_decode_headers, (3) iconv_mime_decode, or (4) iconv_strlen
function. NOTE: this might not be a vulnerability in most web server
environments that support multiple threads, unless these issues can be
demonstrated for code execution.
http://www.securityfocus.com/archive/1/archive/1/478730/100/0/threaded
http://securityreason.com/securityalert/3122
i took a quick look through CVS and i didn't see anything that looked like a
fix. any comments?
thanks,
sean
i'm just going through the latest batch of CVE's and it doesn't look like
there's a fix for CVE-2007-4840 yet:
It's funny that glibc bug gets listed as PHP issue. But I think we may
impose limit on charset length for iconv.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
On Tuesday 18 September 2007 09:54:05 pm Stanislav Malyshev wrote:
i'm just going through the latest batch of CVE's and it doesn't look like
there's a fix for CVE-2007-4840 yet:It's funny that glibc bug gets listed as PHP issue. But I think we may
impose limit on charset length for iconv.
ah, so it's a glibc issue then? istr a similar thing come up with truetype
fonts that ended up being a bug in the tr1 lib, but because the PoC used php
it was classified as a php vulnerabity. if it's the same case here then i
think the onus is on glibc...
/me goes to r some tfm and headers...
sean
ah, so it's a glibc issue then? istr a similar thing come up with truetype
fonts that ended up being a bug in the tr1 lib, but because the PoC used php
it was classified as a php vulnerabity. if it's the same case here then i
think the onus is on glibc...
Well, I think we can still impose limit on iconv parameters, it doesn't
seem to hurt anything. But the problem is reproduceable in pure C...
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
hi stanislav,
(hope you don't mind i'm going to cc this off to a few addresses, no need to
keep them cc'd for further correspondance though)
On Tuesday 18 September 2007 10:56:16 pm Stanislav Malyshev wrote:
ah, so it's a glibc issue then? istr a similar thing come up with
truetype fonts that ended up being a bug in the tr1 lib, but because the
PoC used php it was classified as a php vulnerabity. if it's the same
case here then i think the onus is on glibc...Well, I think we can still impose limit on iconv parameters, it doesn't
seem to hurt anything. But the problem is reproduceable in pure C...
sure, understood. and yes, i can reproduce the problem too. it looks to me
like the underlying charsets passed to iconv_foo in libc are "converted"
using temporary memory allocated on the stack:
===== test program ======
#include <iconv.h>
#include <string.h>
int main(int argc, char **argv){
char tmpbuf[2991371];
char tmpbuf2[2991371];
memset(tmpbuf, '/', 2991370);
memset(tmpbuf2, '/', 2991370);
tmpbuf[2991370] = '\0';
tmpbuf2[2991370] = '\0';
iconv_open(tmpbuf, tmpbuf2);
}
===== iconv/iconv_open.c =====
iconv_t
iconv_open (const char *tocode, const char *fromcode)
{
char *tocode_conv;
char *fromcode_conv;
size_t tocode_len;
size_t fromcode_len;
__gconv_t cd;
int res;
/* Normalize the name. We remove all characters beside alpha-numeric,
'_', '-', '/', '.', and ':'. */
tocode_len = strlen (tocode);
tocode_conv = (char *) alloca (tocode_len + 3);
....
so it's not surprising that big strings could end up being problematic...
sean
tag 442250 + wontfix
thanks
iconv_t
iconv_open (const char *tocode, const char *fromcode)
{
char *tocode_conv;
char *fromcode_conv;
size_t tocode_len;
size_t fromcode_len;
__gconv_t cd;
int res;/* Normalize the name. We remove all characters beside alpha-numeric,
'_', '-', '/', '.', and ':'. */
tocode_len = strlen (tocode);
tocode_conv = (char *) alloca (tocode_len + 3);
....so it's not surprising that big strings could end up being problematic...
OTOH the caller should check those are likely charsets. I mean calling
iconv_open with strhings that are longer than a few octets is completely
silly. The longest charset the libc recognize is 22 chars long, 32 if
you append //TRANSLIT to it.
mallocing for that is completly silly, and the caller should do some
basic sanitizing first.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
ah, so it's a glibc issue then? istr a similar thing come up with truetype
fonts that ended up being a bug in the tr1 lib, but because the PoC used php
it was classified as a php vulnerabity. if it's the same case here then i
think the onus is on glibc...
I've just committed a patch for that.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com