Quoting John Rudd <[EMAIL PROTECTED]>:
>> And ClamAV does not. The milter is. And the milter is designed to
>> work with sendmail. And if leaving this enabled by default produces
>> an exploitable sendmail, then it is wrong.
>
> It does not. What leaves an exploitable sendmail is a poorly
> configured sendmail. The problem is already fixed, and properly
> fixed, in sendmail's own configs. This makes it "the wrong tool for
> the job".
I don't know the history of this expliot, etc. So I can't comment on
whether the fix should stay or not. It would depend on the default
settings for sendmail, how long the fix has been in sendmail, how widely
available the patched sendmail is today, etc.
> Adding this to the milter is adding code to "fix something that
> isn't broken".
I would assume it was added at a time when it was broken (or was broken
in the default install, etc). You might argue that it is no longer needed
and should be removed, but that is a different argument, and as stated above
it depends on knowledge of the history of the problems, history which I don't
know so I can't make an informed decision on the matter.
> Further, it imposes this fix upon mailers that don't have a
> vulnerability (keeping in mind that other MTAs can use milters now).
If the milter is designed for sendmail (this one was, as all older ones
were) then their first duty is to sendmail, not to others who later
decide to use them... Also, there may be other mailers who use milters who
are also vulnerable besides sendmail, etc. So I see this point as moot.
>> I'm not saying it can't be configurable, but whether it is or not, it
>> must be disabled by default, IIF it is known to make sendmail or the
>> milter itself exploitable.
>
> That would be true if and only if the proper fix didn't already
> exist within sendmail itself.
But, is it widely deployed? If not, then the removal now might be
premature (though making it configurable would certainly be within
reason in that case). There is a reason I used "IIF" and it is
because I don't know the history well enough to make absolute statements
the way you do (without anything but your opinions to back them up).
> (and I don't recall if it's the default in sendmail, or not ... but
> that doesn't matter, because the PROPER FIX is to use the sendmail
> config which stops the exploit ... that proper fix might be as
> simple as "do nothing", if it IS the default)
I beg to differ. If it isn't secure by default in sendmail, then it
is reasonable for the milter to enforce it. (It is also reasonable
for the milter to make it conditional, and/or for the milter to simply
document the problem and warn users to fix their sendmail configurations).
What is done it up to the author, not a particular end-user. (Though
the author may find he has more end-users if he listens to their advice...)
>>> At most, it
>>> should offer me policy options, but only _options_.
>>
>> You would rather it allows you to become exploitable? I wouldn't...
>
> Nice strawman.
Why thanks! :)
> No, I wouldn't like to be exploitable. And, without this feature, I
> wouldn't be (not even if I was running sendmail), because the fix
> already exists within its proper location (within sendmail itself).
But only if it is implemented in sendmail, etc... And while you may be
the perfect admin, many admins are not, and might overlook the problem
and be exploitable because it. Or the fix in the milter might even
have pre-dated the fix in sendmail, or the documentation in the sendmail
docs on how to properly secure it, which would leave people vulnerable.
Again, I don't know the history, so...
> At the most, the ClamAV team, and/or the clamav-milter team, should
> provide a STRONG recommendation that the sendmail config should use
> its existing technique for fixing the problem (which may be as
> simple as "do nothing except don't overide the default").
I agree that the above is a suitable thing to do (document the issue).
But that assumes that it was fixed in sendmail before the code was added,
and that if it was fixed later the team knew this and had time to go
back and remove it and fix the docs, etc. Again, I don't know the
history, so...
> Milters in general exist to provide general filtering capability.
> The clamav-milter is not a "general milter". It's a specific
> milter, whose specific purpose is to provide ClamAV capability via
> the milter interface.
"Clamav-milter is a filter for sendmail(1) mail server. It uses a mail
scanning engine built into clamd(8)."
Read into that what you like...
> Again, it is providing a fix in the wrong location, and fixing
> something that isn't broken.
Again, I don't know the history, so I can't comment.
>> It would be irresponsible for a milter to knowingly allow a security hole
>> by default.
>
> Incorrect. It is irresponsible for a milter to allow a security
> hole IN THE AREA THAT THE MILTER ADDRESSES.
I disagree. The keyword of course is "knowingly". Your opinion may vary.
> The clamav-milter isn't a general security tool, it is a _ClamAV_ milter.
Technically it is a _sendmail_ milter.
> By your logic, EVERY milter on the planet should waste its time
> doing EVERY security check known in order to be sure that not only
> is sendmail not mis-configured, but neither is every other milter in
> use. That's wasteful, poorly conceived, and just a plain bad idea.
Who's man is made of straw now?
> Use the right tool for the job. Fix the problem where the problem exists.
But until then, fix them where you can. The only reasonable things for
clamav-milter to have done when this issue was brought to their attention
was:
1) Fix it themselves (the fix being eligible for removal once sendmail was
fixed).
2) If sendmail was already fixed, then document the issue.
3) Stop disrtibuting clamav-milter until sendmail was fixed or the solution
was well documented, etc.
4) Log a loud warning message or something that the end-user couldn't
reasonably miss to alert them of the potential problem, thus annoying
countless people.
5) Do nothing, and have their reputation tarnished, receive lots of bad
press, etc.
Not knowing the history, I can't say if #1 or #2 was the correct method.
But I hate to see the other options done instead.
> The right tool for the job is the existing sendmail fix for the problem.
But was that "existing" fix available at the time, or did it come later.
I don't know, and I'm not going to look it up. If the proper fix was
already available, then I would agree the patch to clamav-milter was not
needed and should not have been implemented. But I can't say that as
I don't know the history, and you haven't provided it.
>> Protecting against such a hole is the only reasonable thing
>> to do. How to best protect that hole is still a subject of debate.
>
> No, it is not. The best protection for that hole already exists
> within sendmail. Fixing it within the clamav-milter is _STUPID_.
You are intitled to your opinion. My opinion is, this thread is dead.
And if you don't like clamav-milter, use one of the many other milters
available for clamav instead. And if the fix is widely available in
sendmail now, then the fix should be removed from clamav-milter, and
the proper warning/instructions put in the clamav-milter docs.
But hey, clamav-milter isn't my project, so unless someone invites me
to work on it, I'll just be happy with things the way they are...
If you really have a problem with it, file a bug report...
--
Eric Rostetter
The Department of Physics
The University of Texas at Austin
Go Longhorns!
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
