Dear BUGTRAQ,
I planed to release this advisory later, but this problem actively
discussed now on Bugtraq. So, I decided to publish it, without any
information on vulnerable products (I have found few). Sorry for bad
English, please feel free to ask me if something is not clear. Of cause,
this advisory doesn't pretend to some kind of fullness, it's invented to
show basic approach and targeted mostly on content filtering software
vendors. I will be grateful for information on actual products
vulnerable.
Original version of this article
http://www.security.nnov.ru/advisories/content.asp
-=-=-
There are common methods allowing to bypass almost any content filtering
software (antiviral products, CVP firewalls, personal firewalls, mail
attachment filters, etc). I believe multiple products are vulnerable.
Contents:
I. Bypassing attachment detection or invalid detection of attachment
type.
1. Encoded filename or boundary in Content-Type/Content-Disposition
2. Multiple filename or boundary fields in Content-Type /
Content-Disposition
3. Exploitation of poisoned NULL byte
4. Exploitation of unsafe fgets() problem
5. MIME part inside MIME part
6. UUENCODE problems
7. Additional space symbol
8. CR without LF
II. Bypassing detection of potentially dangerous content
1. Inability to check Unicode (UCT-2) content
2. Inability to check UTF-7 content
3. Inability to check file marked as UTF-7 Content
III. What should be done?
1. What client software vendor should do.
2. What server software vendors should do.
3. What system administrators should do.
I. Bypassing attachment detection or invalid detection of attachment
type.
Imagine administrator who set his server to strip mail attachments with
dangerous extensions: .exe, .com, .bat, .cmd, .pif, .scr etc. No he
sure, that his user can't get executable file via e-mail. He's wrong.
Because server and client software may use different ways to find
attachments and to discover the type of attachments. Also, some servers
have vulnerabilities preventing them from discovering attachments. There
are few exploitation scenarios:
1. Encoded filename in Content-Type/Content-Disposition
Mail software finds that MIME part is actually attachment by the 'name'
attribute in Content-Type of 'filename' in Content-Disposition. If
neither name nor filename attribute present most software will faild to
find attachment.
name and filename may contain encoded-words. Usually Content-Type looks
like
Content-Type: application/binary; name="eicar.com"
or
Content-Type: application/binary; name="=?us-ascii?Q?eicar=2Ecom?="
But there are different sub-variants server software may fail to check:
Content-Type: text/plain; name==?us-ascii?Q?eicar.com?=
or
name=eicar.com
name=""eicar.com
name=eicar .com
name="eicar.com
name==?us-ascii?Q?eicar.com?=
name==?us-ascii?Q?eicar?=.com
name="eicar.=?us-ascii?Q?com?="
name="eicar.=?us-ascii?Q?com?=
name=eicar.=?us-ascii?Q?com?=
name=eicar.=?us-ascii?Q?co?=m
in case of names like this many programs fail to detect .com extension
or to find attachment at all (please note: base64 may be used instead
of quoted-printable).
Another example is
name="=?us-ascii?B?eica.com
in this case encoded word is incomplete and it's not clear if it should
or shouldn't be decoded from base64. It will depend on client program
realization. Good content filtering software should try both cases.
Some programs also rely on boundary to detect attachments. If
Content-Type contains something like boundary==?koi8-r?Q?aaa?= they may
try to use boundary "aaa" while most clients will use exactly
"=?koi8-r?Q?aaa?=".
Another case is then software tries to decode enocded word, for
example multiple programs miss attachment if it's marked as
Content-Type: text/plain;=?us-ascii?B?;name="eicar.com";?=
2. Multiple filenames/boundaries.
Another one point is how software behaves if there multiple name or
boundary attributes. Example:
Content-Type: text/plain;
name="safe.txt";
name="eicar.com"
Most client programs will use last name or boundary, but good content
filtering software should block that kind of messages or check all
possible situations.
3. Exploitation of "poisoned null byte".
I belive there is not need to explain that ASCII 0 byte may be string
terminator. NULL byte may present in data as is or may be encoded using
base 64 or quoted printable. There is a lot of situation where server
and client software may react to null byte in different way. At least
Outlook Express treats NULL as CRLF.
3.1 Filename and boundary.
There is no need to explain that both name="file.txt\0.exe" and
name="file.exe\0.txt" may be dangerous and boundary="aaa\0bbb" may be
treated as is or as "aaa".
3.2 MIME header and MIME body
Imagine there is a MIME part with
Content-type: text/plain; name=eicar.com
\0Any: text
EICAR-SIGNATURE
Client software may think that EICAR-SIGNATURE is beginning of file
data, while content filtering software will think it's a part of
header. Or vice versa. The only good solution is do not allow NULL
byte in headers.
4. Exploitation of unsafe fgets() problem
I've used "unsafe fgets()" term some time ago regarding to mailbox
parsing problem in few application. This is input validation bug in
programs processing string input then long string are processed
incorrectly in specific situation. It has nothing common with
overflowing some buffer. Let's review small example. Imagine next code
looks for empty string of only '\n' to find the end of MIME headers:
while ( fgets(buffer, BUFFERSIZE, input) ) {
...
if (*buffer == '\n') header = 0;
...
}
There is a bug in this code. Imagine the string of exactly BUFFERSIZE
bytes long (last byte is '\n').
First fgets() call will return BUFFERSIZE-1 characters. Second call
will return the string of only '\n' character. It will be incorrectly
believed to be empty string.
A lot of client and server software has this kind of bugs. It makes it
possible to fool this software to detect headers there they shouldn't
for exampe:
Header:(number of spaces)Content-Type: text/plain; name="eicar.exe"
or like in case of 3.2 to treat some header fields as a part of the
body.
5. MIME part inside MIME part
This bug is very common for software which strips attached files.
Example:
--aaa
Content-Type=text/plain;
--bbb
Content-Type=application/exe; name="eicar.com"
EICAR SIGNATURE
--bbb--
name="eicar.com"
EICAR SIGNATURE
--aaa
then bbb part will be removed aaa part will contain eicar.com
6. UUENCODE problems
UUENCODE is older format for file attachments that doesn't require
MIME part. In classic case uuencoded file begins with
begin XXX filename.ext
(XXX - file permissions in octal encoding).
The problem is if filename contains spaces, for example
begin 666 eicar .com
is valid filename but multiple attachment filter fail to check
everything after space.
7. Additional space symbol
Additional space symbol at the end of filename or boundary may be
treated in different ways by client and mail filtering software. For
example:
boundary=aaa\r\r\n
may be treated by client software as either "aaa" or "aaa\r" and both
cases should be checked.
same thing is with filename in MIME or UUENCODE.
8. CR without LF
At least Outlook Express treats <CR> without <LF> as end of line. It
makes it possible to create Content-Type headers and body invisible
for content filtering software (was reported by Valentijn Sessink).
BTW: older versions of The Bat! crash on <CR> without <LF>, see
http://www.security.nnov.ru/advisories/thebat2.asp
II. Bypassing detection of potentially dangerous content
There is a lost of software that tries to detect and block or remove
dangerous file content (HTML strippers, antiviral products, etc).
Inability of this software to handle specific data makes it useless.
1. Inability to check Unicode content
Multiple products (including Internet Explorer/Outlook Express) support
Unicode encoding for text formats including text/html. Unicode (UCT-2)
text begins with 0xFF 0xFE bytes with wide (WORD) characters in Intel
host byteorder (less significant first). Content filtering software may
fail to strip potentially dangerous information (scripts, ActiveX, etc)
from Unicode format text. For example, "<script>" tag in unicode will
be {'<', 0, 's', 0, 'c', 0, 'r', 0, 'i', 0, 'p', 0, 't', 0, '>', 0}
2. Inability to check UTF-7 content
Almost any MUA/Web client software support UTF-7/UTF-8 encoding for
text. Content filtering software may fail to strip dangerous content
from UTF-7/UTF-8 encoded data. For example <script> tag in UTF-7 may
look like <+AHM-+AGM-+AHI-+AGk-+AHA-+AHQ->.
3. Inability to check content marked as UTF-7/UTF-8
If MUA or Web client retrieves UTF-7/UTF-8 encoded file this file is
decoded for internal processing, but not then saved to disk. That is
text "<+AHM-+AGM-+AHI-+AGk-+AHA-+AHQ->" will be used as "<script>" in
Internet Explorer itself, but if this text is in attached file it will
be saved without changes.
It may be possible to fool software into thinking attached file should
be decoded, while it shouldn't.
For example,
Content-Type: text/html;
charset=utf-7;
name="trojan.exe"
shouldn't be decoded from utf-7 before checking it's content, because
it will be saved by Internet Explorer (or MUA) as is.
I believe for content marked as utf-7/utf-8 both decoded and not
decoded content should be checked.
III. What should be done?
1. What client software vendor should do.
Client software behavior should be as predictive as it possible. Even
small problems (like null bytes and unsafe fgets()) should be
corrected. Configuration options to block dangerous content (for
example files with specified extensions). If content doesn't
correspond to standards it's better ignore content rather then to make
some intuitive decision about it. Behavior should as close to RFC as
it possible. Message with RFC violation shouldn't be processed (or at
least user should be warned).
2. What server software vendors should do.
Check all possible situations with all known client software. Report
all bugs found (even if it doesn't seem to be security related but
looks like RFC violation) to vendors. Block content that doesn't
conform to RFCs. Implement all possible encodings, but do not expect
client software to support them always.
3. What system administrators should do.
Never believe you system is protected against malware. Always
build your network having in mind possibility of intrusion. Protect:
Your users:
Have a written instruction and signed acceptable usage policy
agreements. Instruct your users on how to deal with potentially
dangerous software.
Your applications:
Use application level antiviral products/firewalls. Only
application level antiviral products (for example antivirus for
Outlook or for MS Office) can block malware by it's behavior rather
then signature. It allows to catch almost any malware.
Your workstations:
It's not enough to protect servers. It's very important to also
protect your workstations. Even if your server software will miss a
virus in e-mail it may be caught on workstation than it will try to
launch.
--
http://www.security.nnov.ru
/\_/\
{ , . } |\
+--oQQo->{ ^ }<-----+ \
| ZARAZA U 3APA3A }
+-------------o66o--+ /
|/
You know my name - look up my number (The Beatles)
This archive was generated by hypermail 2.1.3 : Sat Feb 16 2002 - 19:40:40 CET