[exim-dev] [Bug 1004] New: demime bug in uuencode detection …

Pàgina inicial
Delete this message
Reply to this message
Autor: Tamas Tevesz
Data:  
A: exim-dev
Assumptes nous: [exim-dev] [Bug 1004] demime bug in uuencode detection heuristics, [exim-dev] [Bug 1004] demime bug in uuencode detection heuristics
Assumpte: [exim-dev] [Bug 1004] New: demime bug in uuencode detection heuristics
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1004
           Summary: demime bug in uuencode detection heuristics
           Product: Exim
           Version: N/A
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: bug
          Priority: high
         Component: Content Scanning
        AssignedTo: tom@???
        ReportedBy: ice@???
                CC: exim-dev@???



there's a bug in the heuristics in demime.c that is supposed to detect inline
uuencoded content.

i have such an acl entry:

deny    message = Malformed MIME container ($demime_reason) (ID:
$message_exim_id)
        demime = *
        condition = ${if >{$demime_errorlevel}{0}{1}{0}}
        control = no_mbox_unspool


this has been working fine for ages, but recently i've been getting reports
that it started rejecting legitimate messages (hence the no_mbox_unspool for
debugging). upon lots of head scratching it turned out that in the
not-too-distant-past some user agents started to mark forwarded messages with a
"Begin forwarded message:" line.

demime.c:mime_check_uu_start() falsely identifies this as the beginning of an
inlined uuencoded part, puts the parser into MIME_UU_MODE_UNCONFIRMED state,
and things then go downhill, as (obviously) whatever follows is rather unlikely
to be actual uuencoded content.

i believe the mime_check_uu_start() should be a bit more strict when deciding
whether a line is really a uu begin block; probably only lines that match
"(?i)^begin\s+[0-7]+\s+\S+$" should be considered one (this is based on what
gnu sharutils seems to consider a valid `begin' line), and perhaps,
circumstances permitting, drawing a final conclusion should be deferred until
the complete message is read (thus a matching "`\nend\n" marker can be
located).

considering that this is also a sort of a security feature to protect less
fortunate clients from parsing not completely good content, there might be
other implications i'm not aware of, but in it's current form the only choice
there is not to reject messages with level 1 errors, because it really is
rejecting perfectly legitimate and real-life messages.

so far i believe this to be triggered by messages that at one point have passed
through a (relatively recent version of) apple mail (desktop or mobile).

i am setting priority to `high' because i'm expecting this to be more and more
of a problem, as updates are applied to apple products and new apple products
are sold (and seems they are sold at a fast pace).


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email