From owner-freebsd-security Wed Jul 29 23:19:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA10354 for freebsd-security-outgoing; Wed, 29 Jul 1998 23:19:00 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from aniwa.sky (aniwa.actrix.gen.nz [203.96.56.186]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA10347 for ; Wed, 29 Jul 1998 23:18:55 -0700 (PDT) (envelope-from andrew@squiz.co.nz) Received: from localhost (andrew@localhost) by aniwa.sky (8.8.7/8.8.7) with SMTP id SAA06800; Thu, 30 Jul 1998 18:17:53 +1200 (NZST) (envelope-from andrew@squiz.co.nz) Date: Thu, 30 Jul 1998 18:17:52 +1200 (NZST) From: Andrew McNaughton X-Sender: andrew@aniwa.sky Reply-To: andrew@squiz.co.nz To: Brett Glass cc: security@FreeBSD.ORG Subject: Re: Any procmail experts here? In-Reply-To: <199807291630.KAA11022@lariat.lariat.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org procmail will run every time. perl will only run if there is a Content-Disposition header. This variant executes perl only if the content-Disposition header is long :0 hfw * ^Content-disposition:................................................................. | /usr/local/bin/perl -pe 's/^(Content-Disposition:.{80}).*/$1/i' I didn't bother to count the dots I typed. Set it to what you think is appropriate. Procmail's regexp has a construct \/ which puts anything matched by the regexp after that point into $MATCH. This could be used to discard or redirect the message without trying to make it safe. If you're not using procmail for anything else, then you're probably better to use perl only, or perhaps even sed. Is it possible to have sendmail keep the filter pipe open somehow? Andrew On Wed, 29 Jul 1998, Brett Glass wrote: > Date: Wed, 29 Jul 1998 10:24:53 -0600 > From: Brett Glass > To: andrew@squiz.co.nz > Cc: security@FreeBSD.ORG > Subject: Re: Any procmail experts here? > > Wow.... That means invoking both procmail AND Perl on every message. > Not such a good idea on a busy mail server. (And, of course, Perl > will recompile the regex each and every time it executes.) How could > one avoid this? > > --Brett > > At 06:50 PM 7/29/98 +1200, Andrew McNaughton wrote: > > > > >:0 hfw > >* ^Content-disposition: > >| /usr/local/bin/perl -pe 's/^(Content-Disposition:.{80}).*/$1/i' > > > >It's a little rough, but should work, Improvement is a perl regex problem > >rather than a procmail one. > > > >Andrew McNaughton > > > > > >On Tue, 28 Jul 1998, Brett Glass wrote: > > > >> Date: Tue, 28 Jul 1998 21:01:06 -0600 > >> From: Brett Glass > >> To: security@FreeBSD.ORG > >> Subject: Re: Any procmail experts here? > >> > >> Whoops.... As many of you have doubtless already noted, the header > >> we need to catch is > >> > >> Content-Disposition: attachment; filename="" > >> > >> --Brett > >> > >> At 07:59 PM 7/28/98 -0600, Brett Glass wrote: > >> > >> >We have dozens of users who might get bit by the MIME filename buffer > >> >overflow bug described at > >> > > >> >http://www.sjmercury.com/business/microsoft/docs/security0728.htm > >> > > >> >and would like to try to use procmail to plug the hole (it seems to be the > >> >best tool for the job). However, I have no experience with procmail. Could > >> >someone help me write a procmail.rc that will eliminate the extra-long > >> >filenames, truncating them back to (say) 64 characters max? All that's > >> >required is to recognize the Content-type: .... filename="" header > >> >and make sure that is chopped if it's too long. > >> > > >> >This would be a fix for which thousands of sysadmins would be exceedinglyy > >> >grateful. > >> > > >> >--Brett > >> > > >> > > >> >To Unsubscribe: send mail to majordomo@FreeBSD.org > >> >with "unsubscribe security" in the body of the message > >> > > >> > >> To Unsubscribe: send mail to majordomo@FreeBSD.org > >> with "unsubscribe security" in the body of the message > >> > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message