Summary: | app-office/mdbtools: multiple heap overflows | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Stefan Cornelius (RETIRED) <dercorny> |
Component: | Auditing | Assignee: | Gentoo Security <security> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | stefan.cornelius |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Stefan Cornelius (RETIRED)
2006-02-19 14:30:55 UTC
Auditing any news on this one? 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! |