Problem with CheckContentType
Sciurus
KChConType1 regex -a@CATCHED
name=.+[.](com|exe|bat|bas|vba|vbe|vbs|reg|inf|cmd|pif|sct|wsh|cpl|js|jse|lnk|chm|hlp|hta|mdb|scr|shs|vb|vbg|wsf)
HContent-Type: $>CheckContentType
SCheckContentType
R$* $: $(ChConType1 $1 $)
R@CATCHED $#error $@ 5.7.1 $: "553 VIRUS"
While test this with sendmail -bt -d21.12 :
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
CheckContentType name="DFGHJ.exe"
> CheckContentType input: name= "DFGHJ.exe"
-----trying rule: $+
-----rule matches: $: $( ChConType1 $1 $)
rewritten as: @ CATCHED
-----trying rule: @ CATCHED
-----rule matches: $# error $@ 5 . 7 . 1 $: "553 VIRUS"
rewritten as: $# error $@ 5 . 7 . 1 $: "553 VIRUS"
CheckContentType returns: $# error $@ 5 . 7 . 1 $: "553 VIRUS"
But the test mail with the attachment DFGHJ.exe comes for my user:
from=<postm...@mydomain.ru>, size=2884, class=0, nrcpts=1,
msgid=<3EAD1D84...@mydomain.ru>, proto=ESMTP, daemon=MTA,
relay=step.mydomain.ru
ruleset=CheckContentType, arg1=application/octet-stream;\n
name=DFGHJ.exe", relay=step.mydomain.ru, reject=553 5.0.0
<myu...@mydomain.ru>... VIRUS
to=<myu...@mydomain.ru>, ctladdr=<postm...@mydomain.ru> (737/45),
delay=00:00:01, xdelay=00:00:01, mailer=local, pri=32896, dsn=2.0.0,
stat=Sent
What am i doing wrong?
Thanks in advance,
Sciurus.
Andrzej Filip
Could you post FULL log entries ?
BTW sendmail.cf checks only "top level headers".
If the message in a multipart mime than "internal headers" of attachents are
not checked by the sendmail.cf. Milter is a better choice detecting malicious
attachemnts (e.g. mimedefang).
--
Andrzej [pl>en: Andrew] Adam Filip http://www.polbox.com/a/anfi/
*Random epigram* :
If every fool wore a crown, we should all be kings.
-- Welsh Proverb
D. Stussy
> I have the following in my sendmail.mc:
> KChConType1 regex -a@CATCHED
> name=.+[.](com|exe|bat|bas|vba|vbe|vbs|reg|inf|cmd|pif|sct|wsh|cpl|js|jse|lnk|chm|hlp|hta|mdb|scr|shs|vb|vbg|wsf)
Wouldn't it be easier to check for the MIME TYPE instead of every possible file
extension?
Try this REGEX: .*name=.+[.](com|...|wsf).*
^^ ^^
There may be other things on the line, and you need a wildcard to match them.
Per Hedeland
"D. Stussy" <kd6...@bde-arc.ampr.org> writes:
>
>Try this REGEX: .*name=.+[.](com|...|wsf).*
> ^^ ^^
>There may be other things on the line, and you need a wildcard to match them.
No you don't - regexps in general are not "anchored", and the ones in
sendmail's regex map are no exception.
--Per Hedeland
p...@hedeland.org
David F. Skoll
> Wouldn't it be easier to check for the MIME TYPE instead of every possible
> file extension?
Yes, but it won't protect your Windoze boxes.
Try sending a message with a part of type image/jpeg and a filename of
"foo.exe" and see what Windoze does.
--
David.
Sciurus
Apr 30 14:25:58 ns1 sendmail[30444]: h3U8PwYa030444:
from=<postm...@anrb.ru>, size=2887, class=0, nrcpts=1,
msgid=<3EAF8851...@anrb.ru>, proto=ESMTP, daemon=MTA,
relay=step.anrb.ru [62.76.11.152]
Apr 30 14:25:58 ns1 sendmail[30445]: h3U8PwYa030444:
ruleset=CheckContentType, arg1=application/octet-stream;\n
name="regex.exe", relay=step.anrb.ru [62.76.11.152], reject=553 5.0.0
<di...@anrb.ru>... This message may contain a VIRUS postm...@anrb.ru
Apr 30 14:25:58 ns1 sendmail[30445]: h3U8PwYa030444:
ruleset=CheckContentDisposition, arg1=attachment;\n
filename="regex.exe", relay=step.anrb.ru [62.76.11.152], reject=553
5.0.0 <di...@anrb.ru>... This message may contain VIRUS
Apr 30 14:25:58 ns1 sendmail[30445]: h3U8PwYa030444:
to=<di...@anrb.ru>, ctladdr=<postm...@anrb.ru> (737/45),
delay=00:00:00, xdelay=00:00:00, mailer=local, pri=32899, dsn=2.0.0,
stat=Sent
I added the check for the field Content-Disposition.
The CheckContentType was also changed.
But the test mail is not rejected.
HContent-Type: $>CheckContentType
SCheckContentType
#R$* $: $(ChConType1 $1 $)
#R@CATCHED $#error $: 553 This message may
contain VIRUS
R$+ $: $(ChConType1 $1 $: <OK> $)
R<OK> $@ OK
R$* $#error $: 553 This message may
contain a VIRUS $&f
HContent-Disposition: $>CheckContentDisposition
SCheckContentDisposition
R$+ $: $(ChConType1 $1 $)
R@CATCHED $#error $: 553 This message may
contain VIRUS
I try $#discard $: discard instead of
$#error $: 553 This message may contain a VIRUS
without result.
Also
R$* $: $(ChConType1 $&{currHeader} $)
instead of
R$* $: $(ChConType1 $1 $)
> BTW sendmail.cf checks only "top level headers".
> If the message in a multipart mime than "internal headers" of attachents are
> not checked by the sendmail.cf.
Apparently so it is.
I attempted KchConType regex -aCATCHED text/plain and my test letter
with "external header" Content-Type: text/plain; charset=koi8-r was
rejected and test mail with attachment was not rejected ("external
header" is Content-Type: multipart/mixed;).
>Milter is a better choice detecting malicious attachemnts (e.g.
mimedefang).
Thank you, I shall try to do it.
Sciurus.
Jorey Bump
> I added the check for the field Content-Disposition.
> The CheckContentType was also changed.
> But the test mail is not rejected.
>
> HContent-Type: $>CheckContentType
> SCheckContentType
> #R$* $: $(ChConType1 $1 $)
> #R@CATCHED $#error $: 553 This message may
> contain VIRUS
> R$+ $: $(ChConType1 $1 $: <OK> $)
> R<OK> $@ OK
> R$* $#error $: 553 This message may
> contain a VIRUS $&f
I had similar problems when I tried to set up rulesets based on examples
that used "OK". I think that once you mark it as "OK", subsequent checks
are ignored. I now set all of my header checks up like the following,
and they work fine:
LOCAL_CONFIG
dnl regex map for Content-Type headers that may carry virus payload
define(`RxCTvirus', `application\/x-msdownload |\.(com|exe|bat|vba)')dnl
KChConType1 regex -a@CATCHED RxCTvirus
LOCAL_RULESETS
dnl Reject based on Content-Type header
HContent-Type: $>CheckContentType
D{VMsg}This message may contain a virus.
SCheckContentType
R$* $: $(ChConType1 $&{currHeader} $)
R@CATCHED $#error $: 550 5.7.0 ${VMsg}
Per Hedeland
<dev...@joreybump.com> writes:
>Sciurus wrote:
>> I added the check for the field Content-Disposition.
>> The CheckContentType was also changed.
>> But the test mail is not rejected.
>>
>> HContent-Type: $>CheckContentType
>> SCheckContentType
>> #R$* $: $(ChConType1 $1 $)
>> #R@CATCHED $#error $: 553 This message may
>> contain VIRUS
>> R$+ $: $(ChConType1 $1 $: <OK> $)
>> R<OK> $@ OK
>> R$* $#error $: 553 This message may
>> contain a VIRUS $&f
>
>I had similar problems when I tried to set up rulesets based on examples
>that used "OK". I think that once you mark it as "OK", subsequent checks
>are ignored.
What do you mean by ``mark it as "OK"''? Having the RHS start with $@
(as in the above case) means "return from the ruleset with the rest of
the RHS as result", so of course no subsequent checks in that ruleset
will be done (and of course this is the intent with the above rules).
--Per Hedeland
p...@hedeland.org
D. Stussy
OK. Wasn't certain. I usually only send the PART of the string I want to
match against to the regex map. I also forgot that this one wasn't an
explicitly "anchored" expression.
D. Stussy
Micro$oft's shortcoming with respect to MIME typing vs. filename extension are
not my problem! :-)
David F. Skoll
> Micro$oft's shortcoming with respect to MIME typing vs. filename
> extension are not my problem! :-)
Hey, I agree. But presumably the original poster wasn't blocking
.exe, .bat and .com to protect his OpenBSD, Solaris and Linux machines. :-)
--
David.
Jorey Bump
That's the behaviour one would expect, but how does this affect the LHS
of the following ruleset?
When I began writing custom header checking rulesets, I ran into the
same problem that Sciurus is experiencing. It seemed that if there was
no match in the first ruleset, matches weren't caught by subsequent
rulesets. My problem went away simply by removing the "OK" versions, and
rewriting the rules as I indicated.
Unfortunately, I didn't keep copies of the broken rules, and I don't
have access to the older version of sendmail I was using at the time
(Red Hat, sendmail 8.11.x). Because my fix worked, I never investigated
the problem further. It's quite reasonable to suggest that the rules
were doing exactly what they were supposed to do, but it's not what I
intended them to do. :)
Per Hedeland
What is "the following ruleset" for a header check ruleset? In any case,
any result from a header check ruleset other than $#error or $#discard
is simply ignored - see the source, parseaddr.c/rscheck():
if (pvp[0] == NULL || (pvp[0][0] & 0377) != CANONNET ||
pvp[1] == NULL || (strcmp(pvp[1], "error") != 0 &&
strcmp(pvp[1], "discard") != 0))
{
goto finis;
}
--Per Hedeland
p...@hedeland.org
Jorey Bump
> What is "the following ruleset" for a header check ruleset?
HContent-Type: $>CheckContentType
SCheckContentType
[rules]
HContent-Disposition: $>CheckContentDisposition
SCheckContentDisposition
[rules]
CheckContentDisposition follows CheckContentType.
> In any case,
> any result from a header check ruleset other than $#error or $#discard
> is simply ignored - see the source, parseaddr.c/rscheck():
>
> if (pvp[0] == NULL || (pvp[0][0] & 0377) != CANONNET ||
> pvp[1] == NULL || (strcmp(pvp[1], "error") != 0 &&
> strcmp(pvp[1], "discard") != 0))
> {
> goto finis;
> }
So a RHS "$@ OK" from CheckContentType isn't passed on to
CheckContentDisposition (or any other ruleset, for that matter)?
Bear with me, I'm still coming to grips with sendmail's metasymbols in
rulesets. Some of the patterns begin to suggest emoticons for how I feel
when reading sendmail.cf.
D. Stussy
In the absence of a rule in CheckContentType explicitly calling the other rule,
no. Falling of the end of a ruleset returns to the calling ruleset or to
sendmail itself (for the rules it directly called).
Per Hedeland
<dev...@joreybump.com> writes:
>Per Hedeland wrote:
>> What is "the following ruleset" for a header check ruleset?
>
>HContent-Type: $>CheckContentType
>SCheckContentType
>[rules]
>
>HContent-Disposition: $>CheckContentDisposition
>SCheckContentDisposition
>[rules]
>
>CheckContentDisposition follows CheckContentType.
The order of the rulesets in sendmail.cf is quite irrelevant. Rulesets
are called from the sendmail binary or from other rulesets, in an order
defined by an assortment of conditions - header check rules are only
called from the binary (unless you put in explicit calls from other
rulesets yourself, which would seem to be a very strange thing to do),
presumably in the order the respective headers occurs in the message.
Reaching the end of such a ruleset, or having a matching rule with an
RHS that starts with $@ or $#, will return the "result" to the binary,
which will act upon $#error and/or $#discard, and ignore anything else.
>> In any case,
>> any result from a header check ruleset other than $#error or $#discard
>> is simply ignored - see the source, parseaddr.c/rscheck():
>>
>> if (pvp[0] == NULL || (pvp[0][0] & 0377) != CANONNET ||
>> pvp[1] == NULL || (strcmp(pvp[1], "error") != 0 &&
>> strcmp(pvp[1], "discard") != 0))
>> {
>> goto finis;
>> }
>
>So a RHS "$@ OK" from CheckContentType isn't passed on to
>CheckContentDisposition (or any other ruleset, for that matter)?
Correct.
--Per Hedeland
p...@hedeland.org