Exploitable buffer overflow in struct package

[Duck <duck@...>]

Further to the bug in the 'I' option I reported the other day, the useful 
package here:

http://www.inf.puc-rio.br/~roberto/struct/struct.c

which gives Perl/Python-like pack and unpack functions for managing 
arbitrary binary lumps of external data, needs this change:

--- /tmp/struct-old.c	2008-02-09 00:04:58.000000000 +1100
+++ struct.c	2008-02-09 00:04:18.000000000 +1100
@@ -117,11 +117,14 @@
 
 static void putinteger (lua_State *L, luaL_Buffer *b, int arg, int endian,
                         int size) {
-  unsigned char buff[sizeof(long)];
+  unsigned char buff[16];  /* Hard-limit to 128-bit integers */
   lua_Number n = luaL_checknumber(L, arg);
   unsigned long value;
   unsigned char *s;
   int inc, i;
+
+  if (size > sizeof buff) { size = sizeof buff; }
+
   if (n < 0) {
     value = (unsigned long)(-n);
     value = (~value) + 1;  /* 2's complement */


This code is used when packing Lua data into a string.

(Line numbers may vary slightly from the original as I cleaned up some 
comments in my own build.)


I found this because the test code at:

http://www.inf.puc-rio.br/~roberto/struct/teststruct.lua

started failing on Windows after I had made some other general changes to 
my build tree (e.g. switching to Lua 5.1.3), which shows that all those 
test suites one's builds have passed for years and years, yawn, still 
matter :-)

Without the above fix, a pack like this:

s = struct.pack('i8',0)

or, more dramatically, 

s = struct.pack('i512',yourshellcodehere)

causes a stack overflow.

There are other overrun issues in unpack which I haven't addressed yet, 
but they seem to amount to reading past the end of the string being 
unpacked, not to writing past the end of a buffer.