severity 819634 important
thanks
On Fri, Apr 1, 2016, at 07:01, Georg Herrmann wrote:
> And now amavis stumbles into the trap! Now Amavis adds an "BAD HEADER
> SECTION" alert and does not scan the attachment for illegitimate
> attachments! Since I can't quarantine each "BAD HEADER SECTION" alert,
I don't know what we should do about this (but see below). The fact is
that different MUAs (and even mail spoolers) will tolerate and process
badly-formed headers and messages in very different ways. Letting bad
headers through is always going to be a security risk, one that can be
actively exploited.
The safe (from a security PoV) option is to refuse delivery of the
majority of the subclasses of bad headers and MIME malformed messages.
And while crazy non-canonical utf-8 encondings of something might not be
a big problem in a Subject header, it can be used in a MIME header to
bypass file name checks, etc.
Reading the amavisd-new source seems to be required to understand this
thing.
Look for $defang_bad_headers. And also, at the "CC_BADH" major categoty
for %final_destiny_maps_by_ccat, which is usually delivered through
$final_bad_header_destiny (which defaults to D_PASS upstream).
You can influence which bad header checks are going to be done:
# controls which header section tests are performed in
check_header_validity,
# keys correspond to minor contents categories for CC_BADH
$allowed_header_tests{lc($_)} = 1 for qw(
other mime syntax empty long control 8bit utf8 missing
multiple);
$allowed_header_tests{'utf8'} = 0; # turn this test off by default
Taken from the default contents of %smtp_reason_by_ccat, here are the
possible subcategories for CC_BADH:
CC_BADH.',1', 'id=%n - BAD HEADER: MIME error',
CC_BADH.',2', 'id=%n - BAD HEADER: nonencoded 8-bit character',
CC_BADH.',3', 'id=%n - BAD HEADER: contains invalid control
character',
CC_BADH.',4', 'id=%n - BAD HEADER: line made up entirely of
whitespace',
CC_BADH.',5', 'id=%n - BAD HEADER: line longer than RFC 5322
limit',
CC_BADH.',6', 'id=%n - BAD HEADER: syntax error',
CC_BADH.',7', 'id=%n - BAD HEADER: missing required header field',
CC_BADH.',8', 'id=%n - BAD HEADER: duplicate header field',
CC_BADH, 'id=%n - BAD HEADER',
(I assume the catchall at the end is "other").
amavisd-new will use/report the highest minor category that applies
(more than one might apply).
And the default for %defang_maps_by_ccat gives some helpful hints:
%defang_maps_by_ccat = (
# compatible with legacy %defang_by_ccat: value may be a scalar
CC_VIRUS, sub { c('defang_virus') },
CC_BANNED, sub { c('defang_banned') },
CC_UNCHECKED, sub { c('defang_undecipherable') },
CC_SPAM, sub { c('defang_spam') },
CC_SPAMMY, sub { c('defang_spam') },
# CC_BADH.',3', 1, # NUL or CR character in header section
# CC_BADH.',5', 1, # header line longer than 998 characters
# CC_BADH.',6', 1, # header field syntax error
CC_BADH, sub { c('defang_bad_header') },
);
You can let some CC_BADH through easily enough, while refusing others,
using $final_destiny_by_ccat, here's an example I found:
$final_destiny_by_ccat{ CC_BADH.',7' } = D_REJECT;
Please take a look at those options. You can use log level 2 to log the
result of check_header_validity() when a bad header is found. Using log
level 4, you might be able to check what check_for_banned_names() thinks
of the message that has the bad header.
IME, the only bad header syndrome one *has* to tolerate is 8-bit data
with missing enconding information, and that's how I use amavisd-new,
but YMMV. Please share your experience after you play with the above,
we might want to change the Debian defaults based on your report.
Also, you may want to ensure you changed @keep_decoded_original_maps to
always pass the full original message to your anti-virus. If this helps,
we need to change that default in Debian... the reasons why we left it
disabled by default might not hold true anymore...
> this would block a lot too much legitimate mail, the mail will be delivered to
Check which subtypes of CC_BADH are "too much legitimate mail", it might
be possible to avoid triggering on most of the
legitimate-but-created-or-mangled-by-piece-of-trash-software mail.
> I filed this bug with a minor severity, but I think it should be lifted
> to a higher, to serious severity, because checking of unwanted attachments is
Raised it to severity "important". Let's wait until we know more before
we raise it all the way up to "grave", please.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <[email protected]>
