No real time to analyze this, but i think there are several heap overflows in mdbtools. Example: -------------------------------------------- rownum = mdb->pg_buf[fmt->tab_usage_map_offset]; mdb_read_alt_pg(mdb, mdb_get_int24(mdb, fmt->tab_usage_map_offset + 1)); mdb_swap_pgbuf(mdb); row_start = mdb_get_int16(mdb, (fmt->row_count_offset + 2) + (rownum*2)); row_end = mdb_find_end_of_row(mdb, rownum); table->map_sz = row_end - row_start + 1; table->usage_map = malloc(table->map_sz); memcpy(table->usage_map, &mdb->pg_buf[row_start], table->map_sz); -------------------------------------------- Unfortunately, when supplying a malformed file, row_start can be bigger then row_end, resulting in a negative map_sz to be allocated -> segfault when memcpy. There seem to be more issues similar to this one in mdbtools. Version 0.6pre1 seems to catch certain malformed files, but I can still cause segfaults (Didn't investigate any further). What do you think about this?
Auditing any news on this one?
Has anyone looked at this again in the last nearly ten months?
Stefan, I contacted you on #oss-security some months ago, are you (or Secunia) still interested in keeping this confidential?
Hey guys! First of all, I'm really sorry for letting this take so long, my apologies. I think this is a nonissue and the bug can finally be closed :) Well, I probably fell for the fact that after the wrap around to positive (since malloc() wants size_t and table->map_sz is a negative int) the amount of memory to be allocated is _huge_ and most likely going to fail, resulting in table->usage_map being NULL, causing the memcpy to segfault - which I must have mistaken as the result of a heap overflow (... I was a stupid kid back then ...). But even if malloc() does not return 0, table->map_sz is used for both the malloc() and memcpy() and both accept size_t, thus there shouldn't be an overflow. In case you guys want to play around with this yourself, get the mdb file http://www.haneng.com/Lessons/20/Sample.mdb and mess around with the bytes at offsets 0x300A and 0x300B. Have a nice time and take care, Stefan
Stefan, thanks for the clarification. Do you mind if I make the bug public? No need to keep this classified if it's a non issue.
As you said, no reason to keep this secret, except that I'm ashamed of my (soon to be publicly documented) f*ckup ;) Just go ahead with the usual procedure, should be fine. Thanks!
