[Mimedefang] On blocking curlies with Windows file extensions

Clayton, Nik [IT] nik.clayton at citigroup.com
Thu Sep 5 09:15:01 EDT 2002


Hi all,

On Mon, 12 Aug 2002, David Skoll wrote:
> On Mon, 12 Aug 2002, Jim McCullars wrote:

[...]

> > Also, what is the danger of curlies in file
> > names?
> 
> There's a Windows-specific attack (not sure how it works; I don't
> run Windows) which uses a CLSID.

see this URL for the full message:

 
http://lists.roaringpenguin.com/pipermail/mimedefang/2002-August/001954.html

Then, on Wed, 28 Aug, Hiroki Mori wrote:

[...]

> Attachment with non-ASCII filename is so common in Japan, and
> occasionally the curlies ("{" and "}") are included in the
> filename. For example, the header would be like this:
> 
> Content-Type: application/msword
> Content-Disposition: attachment;
> 	filename*=shift_jis''%8C%B4%97%9D%90%7D%2Edoc
>
> Actually, the filename consists of three wide characters followed by
> ".doc" but the filter does not know about the charset and simply
> rejects it as it contains %7D, namely, "}".

[...]

see this URL for the full message:

 
http://lists.roaringpenguin.com/pipermail/mimedefang/2002-August/002145.html

The net effect is that, out of the box, MIMEDefang incorrectly filters
attachments with names in other character sets.

I've done some digging on the CLSID attack that David mentions in his
message.  The clearest text I've found is a PDF file, at

    http://www.pandasecurity.com/demo/whitepaper-filtering-strategies.pdf

which includes a long list of recommend extensions to filter (not all of
which are in the default MIMEDefang config), and includes this information
about CLSID attacks.

 *.{*		CLSID code.  These are class identifiers.  These codes,
which
		are stored in the Windows registry, are used to register
		system components, ActiveX controls, etc.  The dangers is
		evident as registering an item without first having checked
it
		represents a serious security risk.  So for example, an 
		attacker could offer, in a HTML e-mail or a web page, the
file
		"testhta.txt.{<nik: clsid ommitted>}", but Windows Explorer
		and Internet Explorer won't show the CLSID so users only see
		the apparently innocuous .txt extension when it is really
.hta
		which can be executed and could contain malicious code.

With this in mind, it looks as though the default filter_bad_filename()
is overly restrictive.

The simplest way to fix this problem is, I think, to add '{' to the list
of bad extensions, either by amending $bad_exts, or altering the 
declation of $re so that instead of being:

    $re = '(\{)|(\})|(\.' . $bad_exts . ')\.*([^-A-Za-z0-9_.,]|$)';

it's

    $re = '\.' . '(\{)|' . $bad_exts . ')\.*([^-A-Za-z0-9_.,]|$)';

(i.e., a literal dot ('.'), then either a literal '{', or the contents
of $bad_exts, and then the usual checks for trailing dots or 
non-alphanumeric characters.

FWIW, the additional extensions that it recommends to filter that MD
doesn't filter out of the box are:

ASD	Advanced Streaming Format Description
ASF	Active Streaming File
ASX	Active Stream Redirector
HTO	Hierarchical Tagged Objects
SH	Shell Script (?)
VCS	vCalendar, could contain malicious code (?)
WMS	Windows Messaging System
WMD	Windows Media Download
WMZ	Windows Media Player Skins -- can contain java

N
-- 
1        1         2         3         4         5         6         7    7
         0         0         0         0         0         0         0    5
  -- The 75 column-ometer
                                             Contributing to the heat death
Global Messaging, 120 Cheapside, x83331      of the universe since 1973.



More information about the MIMEDefang mailing list