2007-04-09

Throwback

A friend just sent me this link. I recommend you read it immediately and thank me later. Incredible on so many levels, and surprisingly applicable to the modern computer.

http://davidguy.brinkster.net/computer/

How can I argue against IE?

A friend of mine often asks me questions about Information Security that make great blog entries, so thanks again, Mike.

The question was, in essence: I have someone above me in the management chain that wants to switch to IE. How can I convince him this is a bad decision?

My response:
As far as the Microsoft schtick is concerned, there are a number of ways to approach this.

First, the because-experts-said-so approach:
SANS, a group of widely-respected security analysts, recommend using an "alternate" web browser. This can be found in many places on their site, http://www.sans.org (alternately http://isc.sans.org). Securityfocus (http://www.securityfocus.com/), also a respected InfoSec site, probably has a lot of resources / "experts" supporting this notion as well. I'd consider myself an expert in the field, and I emphatically endorse this recommendation.

Second, the hard data approach:
Internet Explorer was vulnerable for 284 of the 365 days in 2006. This study is cited everywhere, but by the sound of it, mainstream news is the way to go with this guy, so here's a pseudo-omnibus article in the Washington Post (which is the original source, I believe):
http://blog.washingtonpost.com/securityfix/2007/01/internet_explorer_unsafe_for_2.html
Firefox's number in this study was 9. I can't say I've seen the data, or that it's been peer reviewed, and it *is* mainstream media we're talking about, but data is data.

Third, the anecdotal approach:
You can find many citations for evidence that attackers are now focusing on applications, rather than operating systems. There is also plenty of data to show that the preponderance of these attacks are against Microsoft products, because of their market penetration and therefore large target space. From a security perspective, by choosing to go with Microsoft applications, you are intentionally putting your computers into the most frequently targeted space of computing assets on the Internet. There's a cost-benefit that needs to be considered here, but the expected benefit had better be pretty high, because the cost in terms of security will be severe.

Fourth, the control approach:
Firefox is extensible, and offers many extensions that improve security. Like the "noscript" plugin, that lets users select which sites can and can't execute javascript. Or the ASN lookup plugin, that looks up the ASN of the site you're visiting to make sure it's actually the company the user thinks he/she is visiting. The list goes on...

Microsoft pundits will refute the data approach with their own FUD, but I can assure you there are no security experts endorsing IE, there is no counter-argument for the anecdotal approach, and IE simply is not extensible like Firefox. The four together should make a compelling argument.

This horse has been long-dead as far as most InfoSec professionals are concerned, but making an argument for the "right decision" isn't always straightforward.

2007-04-02

A bit of help on the MS .ANI exploit...

Recently, I was tasked with looking into this a bit more closely at work, as not many details were readily available on this exploit. Below are the findings, for what they're worth. Some sanitization has occurred, of course, but this is probably good data for the community as a whole so I've decided to share it.
MS Security Advisory 935423: Vulnerability in Windows Animated Cursor Handling
http://www.microsoft.com/technet/security/advisory/935423.mspx

McAfee Links:
http://vil.nai.com/vil/content/v_141860.htm
http://vil.nai.com/vil/content/v_vul28505.htm

A few days old, but ISC is at Yellow:
http://isc.sans.org/diary.html?storyid=2542&rss

Other ISC entries related:
http://isc.sans.org/diary.html?storyid=2555&rss
http://isc.sans.org/diary.html?storyid=2551&rss

MS will be releasing a patch for this vulnerability tomorrow (4/3/2007):
http://blogs.technet.com/msrc/archive/2007/04/01/latest-on-security-update-for-microsoft-security-advisory-935423.aspx

Information on the ANI file format (unofficial):
http://www.wotsit.org/download.asp?f=ani&sc=228832732

Text from that link:
<--------- SNIP --------->
From robertjh@awod.com Fri Aug 30 19:18:26 1996
To: "'paul@wotsit.demon.co.uk'"
Subject: ANI (Windows95 Animated Cursor File Format)
Date: Thu, 29 Aug 1996 21:52:01 -0400

ANI (Windows95 Animated Cursor File Format)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is a paraphrase of the format. It is essetially just a RIFF file
with extensions... (view this monospaced)
This info basically comes from the MMDK (Multimedia DevKit). I don't
have it in front of me, so I'm going backwards from a VB program I wrote
to decode .ANI files.

"RIFF" {Length of File}
"ACON"
"LIST" {Length of List}
"INAM" {Length of Title} {Data}
"IART" {Length of Author} {Data}
"fram"
"icon" {Length of Icon} {Data} ; 1st in list
...
"icon" {Length of Icon} {Data} ; Last in list (1 to cFrames)
"anih" {Length of ANI header (36 bytes)} {Data} ; (see ANI Header TypeDef )
"rate" {Length of rate block} {Data} ; ea. rate is a long (length is
1 to cSteps)
"seq " {Length of sequence block} {Data} ; ea. seq is a long (length is 1
to cSteps)

-END-

- Any of the blocks ("ACON", "anih", "rate", or "seq ") can appear in any
order. I've never seen "rate" or "seq " appear before "anih", though. You
need the cSteps value from "anih" to read "rate" and "seq ". The order I
usually see the frames is: "RIFF", "ACON", "LIST", "INAM", "IART", "anih",
"rate", "seq ", "LIST", "ICON". You can see the "LIST" tag is repeated and
the "ICON" tag is repeated once for every embedded icon. The data pulled
from the "ICON" tag is always in the standard 766-byte .ico file format.

- All {Length of...} are 4byte DWORDs.

- ANI Header TypeDef:

struct tagANIHeader {
DWORD cbSizeOf; // Num bytes in AniHeader (36 bytes)
DWORD cFrames; // Number of unique Icons in this cursor
DWORD cSteps; // Number of Blits before the animation cycles
DWORD cx, cy; // reserved, must be zero.
DWORD cBitCount, cPlanes; // reserved, must be zero.
DWORD JifRate; // Default Jiffies (1/60th of a second) if rate chunk not
present.
DWORD flags; // Animation Flag (see AF_ constants)
} ANIHeader;

#define AF_ICON =3D 0x0001L // Windows format icon/cursor animation


R. James Houghtaling
<--------- SNIP --------->

As I was unable to locate any specifics about this exploit, I was left to
observe known-bad files collected by CIRT and compare them to the
Snort/Sourcefire signature, on the assumption that it is to at least some
degree correct and will catch a subset of bad ANI files.

The Snort signature is as follows (my comments inserted in-line):

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any \
(msg:"WEB-CLIENT Microsoft ANI file parsing overflow"; \
flow:established,from_server; \
content:"RIFF"; nocase:; \ <- Magic # for ANI files, a subset of RIFF files content:"anih"; nocase:; \ <- ANI header indicator byte_test:4,>,36,0,relative,little; \ <- DWORD cbSizeOf reference:cve,2004-1049; classtype:attempted-user; sid:3079; rev:3; ) The primary indicator here is the trigger on cbSizeOf > 36. Other content
matches are to simply identify the data stream as containing an ANI file and
position the pointer accordingly. cbSizeOf is the size of the ANI header
structure. We can infer from this that, if the signature is correct, the size
of the ANI header structure is a trigger for the overflow, and that trigger is
a value greater than 36.

I then analyzed two specimens from :
=== 5597p.jpg ===
As noted in the ticket, this is not a .jpg. It is a compliant ANI file. The
file has a proper RIFF header, followed by two ANI headers:

==== 5597p.jpg ANI Header 1 ====
Beginning at offset 0x0C of the file, we see the following
(Note: all values little-endian)
61 6E 69 68 ["anih" header marker]
24 00 00 00 [cbSizeOf = 0x24 = 36]
24 00 00 00 [cFrames = 0x24 = 36]
FF FF 00 00 [cSteps = 0xFFFF = 65535]
09 00 00 00 [cx must be 0, is 0x09]
00 00 00 00 [cy must be 0, is 0x0]
00 00 00 00 [cBitCount must be 0, is 0x0]
00 00 00 00 [cPlanes must be 0, is 0x0]
00 00 00 00 [JifRate = 0x0]
04 00 00 00 [flags = 0x04 = ?]
Observe one reserved value is 0x09 that should be 0x0, and cbSizeOf is = 36.
The snort signature would not trigger an alert, as cbSizeOf must be > 36 for
an alert to fire. Once the byte comparison is performed here, no additional
processing of the packet will occur.

==== 5597p.jpg ANI Header 2 ====
Beginning at offset 0x50 of the file, we see the following:
(Note: all values little-endian)
61 6E 69 68 ["anih" header marker]
52 00 00 00 [cbSizeOf = 0x52 = 82]
30 31 32 33 [cFrames = 0x33323130 = "0123" text]
30 31 32 33 [cSteps = 0x33323130 = "0123" text]
[...similar bogus data for remaining 66 bytes...]
Here, cbSizeOf is = 82. The Snort signature would fire if this header were
first, but it is not. Thus, no alert fires.

The conclusion here is either:
[1] This file does not execute the exploit correctly and was not responsible
for compromise of the victim; or
[2] The snort signature will only catch the subset of files where the ANI
header triggering the overflow appears before any other ANI headers in the file.

=== 2720p.jpg ===
This file's headers, RIFF and ANI, are identical to those of 5597p.jpg. As a
result the analysis yields the same observations, and the same conclusions:
[1] This file does not execute the exploit correctly and was not responsible
for compromise of the victim; or
[2] The snort signature will only catch the subset of files where the ANI
header triggering the overflow appears before any other ANI headers in the file.

As it is expected that one of the previous two files compromised the victim
machine in , my inclination is to believe that [2] is the correct
take-away from this analysis. This is not directly supported by any analysis
or evidence, however.

This appears to be a good candidate vulnerability for a compiled rule, as each
ANI section header could be iteratively analyzed for offending content. I
will begin to create this as time permits.

Thanks to REDACTED, here is another analysis of the vulnerability that
draws a similar conclusion (limited effect of IDS) but for different,
less-technical reasons that could generally be applied to all IDS rules:
http://erratasec.blogspot.com/2007/04/ani-0day-vs-intrusion-detection.html