[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