This message is a summary of the Flash plugin security risks and current
status.
Included are:
1. Macromedia's response to the security risk since the BugTraq posting on
Dec. 29, 2000.
2. A detailed explanation of the read-overflow.
3. A detailed explanation of a CPU-resource-consumption defect.
4. My final(?) thoughts on this issue.
==================================
Macromedia's response
Prior to the BugTraq posting, I spent 6 months trying to contact them so
that
they could handle this issue in their own way. Failing that, I posted to
BugTraq. The response was startling.
Macromedia initially contacted me via email on Wed, 3 Jan 2001 (less than
24
hours later).
On Thursday evening we had a telephone conference to discuss the current
status and next steps.
The current status of the issues:
- They apologized for the mishandling of the security issue. They
said that there was a breakdown in the reporting process.
- They have validated the read-buffer-overflow. This causes the browser
to
crash, but does not permit arbitrary code to be executed.
- I spent the weekend attempting to duplicate what I thought was a
write-buffer-overflow. (Permits arbitrary code to be executed.)
Currently this has not been verified. We also discussed where they
could
look in their source code to ensure that a write-buffer overflow is not
available.
- We discussed providing a filter for the anti-virus companies. This
would identify corrupt SWF files and block them from crashing the
browsers. Macromedia said they would investigate this.
- We discussed their timeframe for code correction, testing, and
distribution. I'll let them announce the timeframe, but I found it
very acceptable considering the nature of the issue.
On Friday, Jan. 5, they called me and presented both their public
statement and followup for BugTraq (www.securityfocus.com) for my review.
(I had some minor issues with the wording, but I think we have come to an
understanding.) I'm not sure when they will be releasing these.
==================================
The read-overflow
The Flash file format (SWF) uses the form:
tag length data tag length data ....
Where "Tag" defines a task (define image, do action, etc.), "length" is
the
size of the data for the tag, and data contains tag-specific information.
Many of the tags expect the data to contain a null-terminator "0". For
example, strings or complex actions (the "0" means "no more actions for
this
tag").
In most cases, if the terminating "0" is missing, a read-overflow is
created.
The net effect:
The Flash plugin crashes, and crashes the browser with it. We suspect
that MS
Outlook may also crash if the Flash animation runs in the preview pane,
but
this is only in theory and has not been tested.
Impact:
If a corrupt SWF file is placed on a web server, it can cause a
buffer-overflow and crash all visiting browsers. This is a DoS.
==================================
The CPU-resource-consumption defect
While trying to duplicate a write-overflow, I came across another SWF
risk.
The problem seems to be with tag 8 length 1 (action toggle quality, length
should be zero).
When tag 8 has a length of 1 (actual 1 byte of data is ignored), the
browser
hangs.
Under Win98 on a Dell Latitude Cp (laptop):
- CPU pegs at 100%
- Netscape is unresponsive
- If I kill the unresponsive Netscape, my laptop hangs after a
suspend/restore and requires power cycling. (Normally, Win98 on my
laptop is fairly stable.)
Under MacOS 9 on an iMac:
- My CPU load program stops running (appears to hang)
- Netscape hangs. I cannot switch tasks (Command-. and other keyboard
strokes are ignored). The system must be power cycled.
- Only the mouse pointer moves, but it cannot click on anything.
I have not tested this on other platforms (but I'm fairly certain it is
there
too).
===== Working example SWF code =====
46 57 53 05 19 00 00 00 78 00 04 e2 00 00 0c e4 00 00 0a 03 00 01 02 00 00
=====
Impact:
This is a worse DoS than the read-overflow because the browser does not
die
and all CPU cycles are consumed. MacOS requires power-cycling and Win98
should be rebooted (ok, no surprise for Win98...).
==================================
Neal's final thoughts
I'd like to thank BugTraq. I had my concerns about posting in a public
forum,
but I am amazed by the support I have received. BugTraq works, I'm
impressed.
I have recieved a number of emails asked for my impressions and impact of
this
security risk. I believe the worst-case scenario is a new category of
DDoS.
I'll follow this up in a different posting.
-Neal
This archive was generated by hypermail 2b29 : Tue Jan 09 2001 - 19:16:33 CET