-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

===========================================================================
A  U  S  C  E  R  T                                           A  L  E  R  T

                       AL-2004.028 -- AUSCERT ALERT
                           UNIRAS ALERT - 33/04
                 NISCC Vulnerability Advisory 380375/MIME
                             14 September 2004

===========================================================================

                           AusCERT Alert Summary
                           ---------------------

Product:                Applications able to parse MIME
Publisher:              UNIRAS
Impact:                 Execute Arbitrary Code/Commands
                        Denial of Service
                        Reduced Security
Access:                 Remote/Unauthenticated
CVE Names:              CAN-2004-0162 CAN-2004-0161 CAN-2004-0053
                        CAN-2004-0052 CAN-2004-0051 CAN-2003-1016
                        CAN-2003-1015 CAN-2003-1014

Comment: Additional information on product vulnerability status is available
         at http://www.uniras.gov.uk/vuls/2004/380375/mime.htm

- --------------------------BEGIN INCLUDED TEXT--------------------

- ----------------------------------------------------------------------------------
      UNIRAS (UK Govt CERT) ALERT - 33/04 dated 13.09.04  Time: 12:00
 UNIRAS is part of NISCC (National Infrastructure Security Co-ordination Centre)
- ----------------------------------------------------------------------------------
  UNIRAS material is also available from its website at www.uniras.gov.uk and
         Information about NISCC is available from www.niscc.gov.uk
- ----------------------------------------------------------------------------------

Title
=====

NISCC Vulnerability Advisory 380375/MIME

Detail
======

There are several types of software product that need to be able to parse MIME,
and all of these are potentially affected by the vulnerabilities identified.
These are:

* Email clients
* Web browsers
* Anti-virus products
* Mail content checkers
* Web content checkers




NISCC Vulnerability Advisory 380375/MIME

Vulnerability Issues in MIME

Version Information
- -------------------
Advisory Reference	380375/MIME
Release Date		13 Sep 2004
Last Revision		13 Sep 2004
Version Number		0.1

What is Affected?
- -----------------
The vulnerabilities described in this advisory potentially affect Multipurpose
Internet Mail Extensions (MIME) implementations complying with the Internet
Engineering Task Force's (IETF's) Requests For Comments (RFCs) 2045 to 2049
inclusive. MIME is a standard for encoding attachments to emails that has been
extended as new attachments types have become available. MIME is also used as
an encoding method for transfer of files in the World Wide Web content transfer
protocol HTTP. The standards define a range of fields that control how data is
encoded within the transport, and how it should be interpreted by the receiving
agent. RFC 2047 defines "techniques to allow the encoding of non-ASCII text in
various portions of a RFC 822 message header, in a manner which is unlikely to
confuse existing message handling software".

There are several types of software product that need to be able to parse MIME,
and all of these are potentially affected by the vulnerabilities identified.
These are:

* Email clients
* Web browsers
* Anti-virus products
* Mail content checkers
* Web content checkers

Please see http://www.uniras.gov.uk/vuls/2004/380375/mime.htm for further
information. Severity

* Content checking bypass (content checkers)
* Remote code execution
* Denial of service

Summary
- -------
Corsaire Ltd has produced a test suite that exercises ambiguities in the MIME
standard in order to identify security vulnerabilities in software products
that parse MIME. These ambiguities fall into two distinct categories:

* Anomalous parameter values (including multiple parameter values) in the MIME
  header
* MIME encodings that do not parse correctly

The test suite exercises the first of these categories. When a receiving agent
is presented with an ambiguous MIME message it tends to respond in one of two
ways:

* It identifies the MIME message as malformed and blocks it.
* It parses the MIME field (or message) incorrectly or not at all.

The first response would be the correct behaviour for a security product, but
based on Corsaire's empirical research this is not a common result. If a
content checker were to parse a MIME message incorrectly and to allow the
content to pass through the checker based on an incorrect assessment of its
MIME type, the security of the content checker could be bypassed. If this
happened or a content checker was not used, the receiving client could crash
or execute arbitrary code if it also parsed the MIME incorrectly.

Details
- -------

NISCC/380375/MIME/1
CVE number: CAN-2003-1014

By using malformed MIME encapsulation techniques centred on the presence of
multiple occurrences of fields, content checking functionality can be evaded.
RFC 822 states "This specification permits multiple occurrences of most fields.
Except as noted, their interpretation is not specified here, and their use is
discouraged." This lack of clarity within an RFC has been interpreted in
various ways by the assorted vendors. For many products, such as email clients
and browsers, this scope for interpretation might only result in some
unreliable behaviour. However, for a collection of security products, being
unaware of the various ways that the standard has been interpreted can lead to
more serious results, as the products may fail to detect a threat within the
data stream.

NISCC/380375/MIME/2
CVE number: CAN-2003-1015

By using malformed MIME encapsulation techniques centred on the non-standard
presence of whitespace, content checking functionality can be evaded.
RFC 2822 states "White space and comments can appear between many more elements
than in the current syntax. Also, folding lines that are made up entirely of
white space are legal." This has been interpreted in various ways by the
assorted vendors. For many products, such as email clients and browsers, this
scope for interpretation might only result in some unreliable behaviour.
However, for a collection of security products, being unaware of the various
ways that the standard has been interpreted can lead to more serious results,
as the products may fail to detect a threat within the data stream.

NISCC/380375/MIME/3
CVE number: CAN-2003-1016

By using malformed MIME encapsulation techniques centred on the presence of
non-standard quoting, content checking functionality can be evaded. RFC 2822
states "Strings of characters that include characters other than those allowed
in atoms may be represented in a quoted string format, where the characters are
surrounded by quote (DQUOTE, ASCII value 34) characters." However, the use of
quoting may be malformed in a number of ways, such as quoting fields that
should not be quoted, duplicating quotes, or omitting the leading or trailing
quote character from a string. As usual, this has been interpreted in various
ways by the assorted vendors. For many products, such as email clients and
browsers, this scope for interpretation might only result in some unreliable
behaviour. However, for a collection of security products, being unaware of
the various ways that the standard has been interpreted can lead to more
serious results, as the products may fail to detect a threat within the data
stream.

NISCC/380375/MIME/4
CVE number: CAN-2004-0051

By using MIME encapsulation techniques centred on both standard and
non-standard Content-Transfer-Encoding mechanisms, content checking
functionality can be evaded. RFC 2045 provides the Content-Transfer-Encoding
field, which allows the specification of an encoding type to allow 8bit data to
travel successfully through 7bit transport mechanisms. Although the standard
itself only provides for a limited set of encoding mechanisms (7bit, 8bit,
binary, quoted-printable and base64), there are also a number of de facto
mechanisms that are in use (uuencode, mac-binhex40 and yenc). The implementation
of these encoding standards has not been universal by all of the vendors, and
additionally there has also been a degree of variation in the actual mechanism
value used within the Content-Transfer-Encoding header field. For example the
uuencode mechanism may be specified interchangeably as "uue", "x-uue" or
"x-uuencode" (plus others).

NISCC/380375/MIME/5
CVE number: CAN-2004-0052

By using malformed MIME encapsulation techniques centred on the presence of
non-standard separators, this functionality can be evaded. RFC 2822 states
"Header fields are lines composed of a field name, followed by a colon (":"),
followed by a field body, and terminated by CRLF". No advice is given for
situations in which the colon separator (or any of the other separators used
within the MIME standard) is used incorrectly, such as when it is doubled or
omitted entirely. This lack of clarity within an RFC has been interpreted in
various ways by the assorted vendors. For many products, such as email clients
and browsers, this scope for interpretation might only result in some
unreliable behaviour. However, for a collection of security products, being
unaware of the various ways that the standard has been interpreted can lead to
more serious results, as the products may fail to detect a threat within the
data stream.

NISCC/380375/MIME/6
CVE number: CAN-2004-0053

By using malformed MIME encapsulation techniques centred on the presence of
fields encoded using the RFC 2047 parameter value character set and language
information, content checking functionality can be evaded. The implementation
of MIME encoding standards has not been universal by all of the vendors. For
many products, such as email clients and browsers, this scope for variation
might only result in some unreliable behaviour. However, for a collection of
security products, being unaware of the various ways that the standard has
been implemented can lead to more serious results, as the products may fail
to detect a threat within the data stream.

NISCC/380375/MIME/7
CVE number: CAN-2004-0161

By using malformed MIME encapsulation techniques centred on the presence of
fields encoded using the RFC 2231 continuations or parameter value character
set and language information, content checking functionality can be evaded.
RFC 2231 extends RFC 2047 which defines "techniques to allow the encoding of
non-ASCII text in various portions of a RFC 822 message header, in a manner
which is unlikely to confuse existing message handling software". The
implementation of these encoding standards has not been universal by all of
the vendors. For many products, such as email clients and browsers, this scope
for variation might only result in some unreliable behaviour. However, for a
collection of security products, being unaware of the various ways that the
standard has been implemented can lead to more serious results, as the
products may fail to detect a threat within the data stream.

NISCC/380375/MIME/8
CVE number: CAN-2004-0162

By using malformed MIME encapsulation techniques centred on the presence of
fields containing an RFC 822 comment, content checking functionality can be
evaded. RFC 822 states "A comment is a set of ASCII characters, which is
enclosed in matching parentheses and which is not within a quoted-string. The
comment construct permits message originators to add text which will be useful
for human readers, but which will be ignored by the formal semantics. Comments
should be retained while the message is subject to interpretation according to
this standard. However, comments must NOT be included in other cases, such as
during protocol exchanges with mail servers". The implementation of the
commenting standard has not been universal by all of the vendors. For many
products, such as email clients and web browsers, this scope for variation
might only result in some unreliable behaviour. However, for a collection of
security products, being unaware of the various ways that the standard has
been implemented can lead to more serious results, as the products may fail to
detect a threat within the data stream.

Solution
- --------
Please refer to the Vendor Information section of this advisory for
implementation specific remediation.

Vendor Information
- ------------------

See the link below for vendor information.

http://www.uniras.gov.uk/vuls/2004/380375/mime.htm

Contact Information
- -------------------
The NISCC Vulnerability Management Team can be contacted as follows:

Email		vulteam@niscc.gov.uk
		(Please quote the advisory reference in the subject line.)
Telephone
+44 	(0)20 7821 1330 Extension 4511
		(Monday to Friday 08:30 - 17:00)
Fax		+44 (0)20 7821 1686
Post		Vulnerability Management Team
		NISCC
		PO Box 832
		London
		SW1P 1BG

We encourage those who wish to communicate via email to make use of our PGP
key. This is available from http://www.uniras.gov.uk/UNIRAS.asc.

Please note that UK government protectively marked material should not be sent
to the email address above.

If you wish to be added to our email distribution list, please email your
request to uniras@niscc.gov.uk.

What is NISCC?
- --------------
For further information regarding the UK National Infrastructure Security
Co-Ordination Centre, please visit the NISCC web site at:
http://www.niscc.gov.uk/aboutniscc/index.htm

Reference to any specific commercial product, process or service by trade name,
trademark manufacturer or otherwise, does not constitute or imply its
endorsement, recommendation, or favouring by NISCC. The views and opinions of
authors expressed within this notice shall not be used for advertising or
product endorsement purposes.

Neither shall NISCC accept responsibility for any errors or omissions contained
within this advisory. In particular, they shall not be liable for any loss or
damage whatsoever, arising from or in connection with the usage of information
contained within this notice.

C 2004 Crown Copyright
<End of NISCC Vulnerability Advisory>

- ----------------------------------------------------------------------------------

For additional information or assistance, please contact the HELP Desk by
telephone or Not Protectively Marked information may be sent via
EMail to: uniras@niscc.gov.uk

Office Hours:

Mon - Fri: 08:30 - 17:00 Hrs
Tel: +44 (0) 870 487 0748 Ext 4511
Fax: +44 (0) 870 487 0749

Outside of Office Hours:
On Call Duty Officer:
Tel: +44 (0) 870 487 0748 and follow the prompts

- ----------------------------------------------------------------------------------
UNIRAS wishes to acknowledge the contributions of Corsaire & NISCC for the
information contained in this Briefing.
- ----------------------------------------------------------------------------------
This Briefing contains the information released by the original author. Some
of the information may have changed since it was released. If the vulnerability
affects you, it may be prudent to retrieve the advisory from the canonical site
to ensure that you receive the most current information concerning that problem.

Reference to any specific commercial product, process, or service by trade
name, trademark manufacturer, or otherwise, does not constitute or imply
its endorsement, recommendation, or favouring by UNIRAS or NISCC.  The views
and opinions of authors expressed within this notice shall not be used for
advertising or product endorsement purposes.

Neither UNIRAS or NISCC shall also accept responsibility for any errors
or omissions contained within this briefing notice. In particular, they shall
not be liable for any loss or damage whatsoever, arising from or in connection
with the usage of information contained within this notice.

UNIRAS is a member of the Forum of Incident Response and Security Teams (FIRST)
and has contacts with other international Incident Response Teams (IRTs) in
order to foster cooperation and coordination in incident prevention, to prompt
rapid reaction to incidents, and to promote information sharing amongst its
members and the community at large.
- ----------------------------------------------------------------------------------
<End of UNIRAS Briefing>

- --------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members.  As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin.  It may
not be updated when updates to the original are made.  If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above.  If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:

        http://www.auscert.org.au/render.html?cid=1980

If you believe that your computer system has been compromised or attacked in 
any way, we encourage you to let us know by completing the secure National IT 
Incident Reporting Form at:

        http://www.auscert.org.au/render.html?it=3192

===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072

Internet Email: auscert@auscert.org.au
Facsimile:      (07) 3365 7031
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
                AusCERT personnel answer during Queensland business hours
                which are GMT+10:00 (AEST).
                On call after hours for member emergencies only.
===========================================================================

-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967

iQCVAwUBQUXMBSh9+71yA2DNAQLu3wP/fb7E26rfH6Off3BupHjcylIYEbWahKim
zFOAa0PuJhVxNswJSF8q5BJKJhIIlhLAf//4RJkf6L6Zsxmdb+OH9cspOsSc+U4O
FoSAUptYJOsFkJ9hoTwm3knhTorJVOxQqxAJOsHaL9QFGY25rsZx0+zXHlaqiQ+J
ATAIWC4qUXE=
=KzL9
-----END PGP SIGNATURE-----