[Esd-l] List of what Sanitizer "Sanitizes"

[John D. Hardin]

On Fri, 18 Jun 2004, Smart,Dan wrote:

> I was trying to document what exactly your Sanitizer sanitizes as
> part of my Sarbanes-Oxley control documentation.  Here's my
> attempt based on change logs and code review.  Is this close?

Well, let's see...

> HEADERS
> 1. Sanitize bare CR in message headers (Outlook bug). 

yes. That's also in violation of RFC822 so it's a protocol sanitizing
issue.

> 2. Sanitize multiple null addresses (sendmail exploit).
> ^((resent-)?(sender|from|(reply-)?to|cc|bcc)|(errors|disposition-notificatio
> n|apparently)-to|Return-Path): .*<>.*<>.*<>.*<>.*<>.*<>.*

yes.

> 3. Detect and truncate Subject: headers longer then 250 characters, to
> protect Outlook Express users. 

yes.

> 4. Truncate excessively long (>500) standard headers, to address the MS
> Outlook header buffer-overflow bug;
> (Mime-Version|(Resent-)?(Date|Sender|From|Reply-To)|(errors|disposition-noti
> fication|apparently)-to|Message-ID|Return-Path|Status|X-Status|X-Keywords):

yes, and to proactively protect against other BO bugs in other
mailers.

> FIX MIME
> 1. Repair malformed MIME boundary strings (e.g. begin with "A--" instead of
> "--").

Not yet. I've only seen that one time, so I'm treating it as
"corrupted in transmission".

> 2. Filter out odd characters from MIME boundary strings? 

Not yet. Note that most of the entries in the "unreleased" list are
things on the "to do" list.

> 3. Check for a null MIME boundary string and supply one if necessary; this
> is a major DoS attack against Microsoft Exchange 

Yes.

> 4. Sanitize MIME values that have been explicitly set to null (e.g.
> encoding="") - this is a major DoS attack against Microsoft Exchange. 

Yes.

> 5. Sanitize double backquotes in MIME headers to prevent remote attacks
> against Metamail via the UW Pine MUA

Yes.

> ATTACHMENT HEADERS
> 1. Mangle CID (Content-ID:) headers to disable IFRAME and related exploits. 

Not yet. That would also break stationery images (oh woe!) but it
seems that the active-HTML defanging is sufficient and this would be a
suspenders-and-belt measure.

> 2. Sanitize files with Microsoft Class-ID extensions. 

Yes.

> 3. Shorten long file names to less than 120 characters
>    a. Collapse runs of spaces in filenames before length-limiting. 

Yes.

> 4. Fix double backquotes

Duplicate.

> 5. Fix missing closed quote on filename
> 6. Fix unquoted filenames
>    a. Properly enquote unquoted attachment filenames that have embedded
> semicolons.

Yes. Those are both part of just standardizing the filename format.

> 7. Fix trailing periods and spaces in filename.

Yes. Trailing spaces are pointless, and trailing periods are ignored
by Windows so they are pointless too. Unfortunately it does make a
noticable change to filenames on non-Windows platforms, but since
Windows treats "x.exe" and "x.exe." identically, there's little
choice.

> 8. Catch encoded periods in filenames
> 9. Fix encoded plain characters in filename

Both because there's no reason to encode those characters other than
an attempt to bypass filtering.

> 10. Catch quotes-in-extension attack

Outlook/Windows ignores them. (!)

> 11. Remove embedded RFC822 comments

Yes.

> 12. strip attachment-only MIME messages. 

That was a bugfix. What do you do when your policy says "strip" and
the attachment is all that's in the message?

> URLs
> 1. Fix URL Spoofing; a.com%01 at b.com
> 2. Fix URL Obfuscation; a.com at b.com

Yes. Same comments as above. There's no good reason to encode plain
characters other than an attempt to bypass filtering.

> 3. Filter Location with URL; Location: URL:
> 4. Filter Locaton with File; Location: File:

I'm not sure what you're talking about here.

> WEBBUGS
> 1. Sanitize <IMG> tags
> 2. Sanitize webbug images in tables. 
> 3. Sanitize the <BGSOUND> tag for webbugs
> 4. Santize "BACKGROUND" subtag for webbugs

Yes.

> TAGS
> 1. Sanitize the <LINK> tag.
> 2. Sanitize the <LAYER> tag; this is primarily of interest to people running
> webmail programs. 
> 3. Sanitize <STYLE> tags and clauses because they can be used to hide
> scripting code.

Yes.

> 4. Detect obscured HTML tags. 
> 	a. Deal with attempted obscuration of tag options with &# and %
> escapes.

Yes. Same comments as earlier.
 
> 5. Sanitize <TITLE> tags to secure against Netscape's execution of
> javascript in the wrong security context.

That's been superceded by the general defanging of scripting and event
tags.
 
> 6. Sanitize FORM tags (see bugtraq posting
> http://www.securityfocus.com/archive/1/359139). 

Yes.

> ACTIVE SCRIPT
> 1. Sanitize active HTML <SCRIPT> tags
> 	Defang OnCommands such as OnLoad and other OnCommands.
> 	Defang script or mocha:
> (["\047\075]|url\()([a-z]+script|mocha):
> 	Defang &{: 		(["\047\075])&{

Yes.

> ENCRYPTION
> Disable sanitizing of encrypted/signed messages; 

Unfortunately defanging things would break the signature.

Also:

Length-limit MIME boundary strings, to proactively defend against BO
bugs.

Fix attachment headers of the form 'text from file "xxxx"' where
Outlook helpfully looks if the filename can't be determined from the
headers that *should* have the filename.

Truncate long attachment headers (vs. RFC822 message headers as you
noted), again to proactively defend against BO bugs in mailers.

--
 John Hardin KA7OHZ    ICQ#15735746    http://www.impsec.org/~jhardin/
 jhardin at impsec.org    FALaholic #11174    pgpk -a jhardin at impsec.org
 key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
  The [assault weapons] ban is the moral equivalent of banning red
  cars because they look too fast.
                                   -- Steve Chapman, Chicago Tribune
-----------------------------------------------------------------------
   85 days until the "Scary-Looking Guns" ban expires