Summary: Shockwave overflow

[nealk <nealk () verinet com>]

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