[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

UNIRAS ALERT - 33/04 - NISCC Vulnerability Advisory 380375/MIME



 
-----BEGIN PGP SIGNED MESSAGE-----

- ----------------------------------------------------------------------------------
      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@xxxxxxxxxxxx 
		(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@xxxxxxxxxxxxx

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@xxxxxxxxxxxx

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>

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQCVAwUBQUV8jYpao72zK539AQFcbgQAm4m9gWU8lHGpb76TmKoEEU+J3cQ9ahbe
Lf9ehwsbCSQOrjoYKtab/ULOVfGY04Uz/Lrew1mjrOvXsDbD0sqyuFOUT2RvsNLg
oAuFMIrcxRACFpOeZrhmovDcOL09GE9sY3QHdwX/scV95X9DSPWzpXdWWHLtOQSj
gudUtzJ2bN4=
=uDaG
-----END PGP SIGNATURE-----