pldaniels at pldaniels
May 12, 2004, 4:10 PM
Post #2 of 4
(1436 views)
Permalink
|
Hello Matt,
> if someone were to embed a very large number of attachments, like a mime exploit, in an attempt to run over the
> buffer, could ripmime recover gracefully? also the same question for filename lengths..
> any values that you restrict to for file extraction (number of files or filename length)?
ripMIME uses snprintf() and other size restricted string/buffer manipulation routines, so the possibility is quite a bit
'lower'. Some time back, a University spent some time trying to feed ripMIME malware and did uncover some possible
buffer overflows (you can google for these) and as such have since been rectified. The matter of filename lengths,
ripMIME will crop any filenames over its own internal buffer lengths.
The only real 'exploit' immediately available is to create a very deeply nested MIME package, something such that has
been forwarded say > 20 times. However, ripMIME uses a recursion limit check to ensure that the stack-space isn't
depleted, giving the administrator the option to control this as well.
I would be hesitant to guarantee that ripMIME is utterly flawless, such boasting would no doubt immediately incurr a
wrath of bugs to become immediately apparent, however, I do believe that ripMIME has gone through quite a number of
processess (including valgrind checking) to help it become a highly resiliant OpenSource project.
Paul.
--
Paul L Daniels - PLD Software - Xamime
Unix systems Internet Development A.B.N. 19 500 721 806
ICQ#103642862,AOL:pldsoftware,Yahoo:pldaniels73
PGP Public Key at http://www.pldaniels.com/gpg-keys.pld
|
