On Wed, May 28, 2003 at 04:03:58AM +0300, Timo Sirainen wrote: > http://cr.yp.to/proto/netstrings.txt > > I didn't find any real code that actually did it like in the example, > but I think it's worth mentioning since that page still gets referenced > once in a while. I just noticed it in some recent oreilly article about > safe string handling. > > It's been there for over 6 years unnoticed, so rather than just telling > you what's wrong, I think it would make a pretty interesting > vulndev-challenge. Much harder than the previous ones anyway :) > > So, here's the code, just assume sane variables etc. (and no, the > problem isn't that you can allocate a gigabyte of memory): > > if (scanf("%9lu",&len) < 1) barf(); /* >999999999 bytes is bad */ > if (getchar() != ':') barf(); > buf = malloc(len + 1); /* malloc(0) is not portable */ > if (!buf) barf(); > if (fread(buf,1,len,stdin) < len) barf(); > if (getchar() != ',') barf(); > > So not all code djb has ever written is secure :) What a surprise. Well, scanf("%9lu") will not accept more than 9 digits, so we can't enter 4294967295 = 0xffffffff to get malloc(len + 1) to become malloc(0), which in glibc's malloc-implementation is equivalent to malloc(8). But we don't have to, even though lu = unsigned long, nothing stops us from feeding a signed integer to scanf(). So, entering "-1:lots-of-bytes" will set len to 4294967295, allocate 8 bytes, and read lots of data from stdin until EOF (or until it tries to write to an unmapped page). As far as I can tell, the exploitability of the code above depends on context, unless fread() allocates something on the heap but I don't see why it would, and depending on what barf() does. > Oh, and djb knows about this now, didn't say if he's going to bother > updating the page. Seems like he didn't bother. -- Joel Eriksson ------------------------------------------------- Cellphone: +46-70-288 64 16 Home: +46-26-10 23 37 Security Research & Systems Development at Bitnux PGP Key Server pgp.mit.edu, PGP Key ID 0x529FDBD1 A615 A1E1 3CA2 D7C2 CFEA 47B4 7EF7 E6B2 529F DBD1 -------------------------------------------------
This archive was generated by hypermail 2b30 : Sun Jun 01 2003 - 12:29:57 PDT