|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: Long attachment filename exploits: a procmail filter
John D. Hardin (jhardin
WOLFENET.COM)Wed, 29 Jul 1998 20:05:45 -0700
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: John D. Hardin: "Re: Long attachment filename exploits: a procmail filter"
- Previous message: Brett Glass: "Re: Long attachment filename exploits: a procmail filter"
- In reply to: Brett Glass: "Re: Long attachment filename exploits: a procmail filter"
- Next in thread: John D. Hardin: "Re: Long attachment filename exploits: a procmail filter"
On Wed, 29 Jul 1998, Brett Glass wrote:
> This recipe is a great start! However, there are a few potential improvements.
Fire away!
> First, it doesn't recognize tabs as whitespace or handle optional
> whitespace in a few places where MIME would allow it.
I fixed that - thanks for pointing it out. Please grab the
html-trap.procmail snippet again and take a look.
> Second, it invokes Perl on any message with a MIME attachment, which
> could slow the mail server greatly. It would be preferable to detect the
> exploit in procmail and only invoke Perl to "cleanse" the message if
> that were necessary.
Not so. It uses procmail REs to detect long filenames and executable
filenames, and only calls perl to sanitiza them if they are found.
> Alternatively, it could redirect the mail to the postmaster so he or she
> would know that users were under attack.
Hmm. That would be simple a matter of adding
:0c
! postmaster
to the block that calls perl - before (unsanitized) or after (sanitized)
perl cleans the message would be a judgement call.
Alternatively you could send the entire message as an attachment - that
might be better. Could someone give me an action that will take the
message being processed and mail it as a MIME attachment to postmaster?
I'm not very familiar with formail.
> Finally, there are other possible exploits, like a very long content
> type, that might also lead to buffer oveflows in mail clients. These
> should be checked too.
If you can give me an example, I'll be glad to add a trap for it. I'll
take a shot at it without a sample, but it might not be too good.
> Can people suggest improvements to John's recipes that solve these
> problems? Greg Sutter and Chris Lindsey have both come up with patterns
> that do more of the matching within procmail, but they still need a
> little refinement.
>
> In any event, this is a great start. It's fantastic that someone who had
> most of the needed recipe already written was on the list.... This is
> what's great about the Net!
...and that I also lurk on bugtraq and ntbugtraq... :)
--
John Hardin KA7OHZ jhardin
wolfenet.com
pgpk -a finger://gonzo.wolfenet.com/jhardin PGP key ID: 0x41EA94F5
PGP key fingerprint: A3 0C 5B C2 EF 0D 2C E5 E9 BF C8 33 A7 A9 CE 76
-----------------------------------------------------------------------
Your mouse has moved. Windows NT must be restarted for the change
to take effect. Reboot now? [ OK ]
-----------------------------------------------------------------------
88 days until Daylight Savings Time ends
- Next message: John D. Hardin: "Re: Long attachment filename exploits: a procmail filter"
- Previous message: Brett Glass: "Re: Long attachment filename exploits: a procmail filter"
- In reply to: Brett Glass: "Re: Long attachment filename exploits: a procmail filter"
- Next in thread: John D. Hardin: "Re: Long attachment filename exploits: a procmail filter"