Mailing List Archive

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

> 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, ...

maybe therefore you should make this boast ...
ie, so that "hackers" will try to prove you wrong and find these bugs.
otherwise some obscure bugs could be there for a long time before a
legitimate user (or yourself) finds them

although avoiding the word guarantee would be smart :-)

Louis Solomon
www.steelbytes.com

Louis,

> maybe therefore you should make this boast ...
> ie, so that "hackers" will try to prove you wrong and find these bugs.

Trying to make Murphy's law work in your favor is often a guarantee that it'll turn on you :-)

The only trouble I find with a lot of "hackers" is the way in which they behave, often skirting around good
communications in order to oversell their 'find' (one only has to look at Bugtraq *cringe*). Fortunately, I have found
that a lot of people here have managed to produce some very fine examples of environments which induce faults. That
said, it's still always useful to have people trying to break your things; albiet, I'll still stop short of declaring it
unbreakable *laugh*.

Speaking of breaking things - looks like 1.3.1.2 has now been released with yet another couple of extra attachments
being extracted from my 45,000 mailpack torture test.

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