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
signature.asc
Description: This is a digitally signed message part.
