Date : mardi 2 janvier 2001 19:09
Objet : 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.)
Lindows harcelé