- ich mach mir sorgen:
Date: Fri, 29 Dec 2000 18:25:57 -0000
From: "Krawetz, Neal"
Subject: [BUGTRAQ] Shockwave Flash buffer overflow
I have identified a buffer overflow condition in the Shockwave Flash plugin
for web browsers.
Although this is "yet another buffer overrun", Macromedia's web page claims
that 90% of all web browsers have the plugins installed. Since this
overflow can be used to run arbitrary code, it impacts 90% of all "web"
enabled systems.
=====
Area of affect:
All SWF plugins on all platforms.
I have validated it with the Shockwave Flash plugins versions 2 through 8.
I have validated it on Windows 95, 98, NT, MacOS 9, Solaris 2.6 and 2.7, and
RedHat Linux 6.0.
I have validated it using Netscape (4.04, 4.7) and Internet Explorer.
The buffer overflows are consistent per platform, but vary between plaforms.
(Or in english: A corrupt SWF may crash Netscape on Windows 95, but only
screw up the graphics under Linux. This SWF will always crash Netscape on
Win95 the same way and it will always screw up the Linux graphics the same
way. A different corrupt SWF file could crash the browser on all
platforms.)
=====
Root cause:
(Keep in mind -- I have not actually seen the source code for the plugins --
I have only determined this from the symptoms.)
Bounds checking is not being performed on the SWF data.
The SWF file is in the format:
tag length data tag length data ...
Where "tag" tells what action to perform and "length" is the size of the
data for the tag. ("data" is the data for the tag.)
For example:
Define_Picture "40 bytes" data_for_the_picture
Some tags have more complex data formats, where data contains:
subtag sublength subdata subtag sublength subdata "0"
The "0" means "end of data".
So, the entire tag looks like:
tag length (subtag1 sublength1 subdata1 subtag2 sublength2 subdata2 "0")
Sample tags with complex data are Define_Sprite (tag 39) and Do_Action (tag
12).
If the "0" is missing, or appears beyond "length" bytes, then a buffer
overflow occurs.
Or in other words: If the lengths or sublengths are wrong, then the
shockwave flash plugin will overflow.
=====
Impact of risk:
The buffer overflow can be used to execute arbitrary code stored in the SWF
file.
"Bad" arbitrary code causes the plugin to crash the browser.
"Good" arbitrary code can execute a program on the browser's computer.
This can be used to propogate a virus, worm, or do other harmful tasks.
It is possible to write a single SWF file that contains platform-specific
overflow/opcodes for multiple systems (Solaris, Linux, Windows, Irix, etc.).
=====
Worst case:
I'll leave this for you to decide.
I believe a multi-platform (Windows/Unix) self-modifying virus is possible.
("Self-modifying" would be hard part.)
=====
What can you do:
1. Hope that Macromedia corrects the problem. Download the corrected
version when/if it becomes available.
2. The anti-virus vendors can write modules to check the bounds on SWF files
from web pages. (If data should be null terminated, validate that there is
a null. For some tags (like tag 83), make sure there are two nulls in the
data. Make sure there are no illegal tags.)
3. Hope the issue is addressed before someone writes something nasty. Until
then, disable (remove) the Shockwave Flash plugin.
=====
Reporting history:
(I am including this in case someone decides to sue me.)
Early July 2000:
- Identified the defect.
July 25, 2000:
- Reported defect to Macromedia (call number TWL2000072500018060)
July 26, 2000:
- Reported the defect to CERT, NIPC, and CIAC.
July 30, 2000:
- Conact from "Chris" at Macromedia asking for more information. I
provided details.
August 2000:
- Taked with "Chris" from CERT at Usenix Security conference. He called it
a "sleeper" and said he would look into it. (I know... There were two guys
named "Chris from CERT" -- this was the dark-haired guy.) [As an aside,
isn't there some risk about everybody being named "Chris"?]
December 15, 2000:
- No advisories or notice from Macromedia, CERT, NIPC, or CIAC.
- Macromeda has, during this time, released updates to Shockwave Flash and
these are still vulnerable. (Evidence that they are not invesitigating or
addressing the issue.)
- Decided to post to BugTraq.
- By dumb luck, met a guy at a party who knew a guy who was the sister of a
"senior manager" at Macromedia. Decided to hold off posting.
December 18, 2000:
- Made contact with the manager's brother. Left phone message for sister
at Macromedia.
December 19, 2000:
- Provided details of exploit to Macromedia. Also provided sample SWF
files that perform buffer overflows on various platforms.
December 20, 2000:
- Received the same reply from Macromedia that I did on July 30. (It has
been forwarded to the engineers for investigation.)
- Decided to give them one week to respond before posting to Bugtraq.
December 29, 2000:
- Post to Bugtraq. (In hindsight, I should have done this back in August.)"
siehe auch
"Sicherheitsloch in Macromedia Flash" http://www.heise.de/newst…
- die sorgen mach ich mir im uebrigen weniger um das sicherheitsloch sondern vielmehr aufgrund der arroganz von macromedia - diese firma ist regelmaessig ein meister darin probleme zu ignorieren, bugs nicht zu loesen und features einzufuehren, nach denen keiner gefragt hat