Submitted by IBM researcher Mark Dowd has outlined a Flash vulnerability that could allow for a rare cross-platform web-based exploit. Matasano Chargen uses a Super Mario metaphor, an example we can all relate to, to illuminate it.
IBM researcher Mark Dowd has outlined a Flash vulnerability that could allow for a rare cross-platform web-based exploit. Matasano Chargen uses a Super Mario metaphor, an example we can all relate to, to illuminate it.
You people had to learn the hard way…
Next time, avoid such proprietary garbage.
Edited 2008-04-16 17:12 UTC
How are such exploits unique to proprietary software?
>How are such exploits unique to proprietary software?
Well they’re not really, but (I can’t really believe I’m going to quote Eric S. Raymond) –
“given enough eyeballs, all bugs are shallow”
The premise of that claim: “Given enough eyeballs”, is often taken as a given. Everyone who has done a security audit of Gnash, please raise your hand.
I’m a strong advocate of open source. But I would be remiss not to state that eyeballs per line of code can be quite variable.
You just hope that whichever pair of eyeballs discovers the hole first belongs to one of the good guys.
I would say the lesson learned here for anyone who still believes that proprietary software is safer due to the closed-code is: It doesn’t matter – someone with the know-how and determination will still figure out how the software works and find exploits.
Thus, open source has the advantage that *more* people can evaluate the source and find such flaws prior to compilation rather than via low level debugger and disassembly.
Also, if someone wanted to fix this in a mission critical environment before an official patch is available, they would be able to. Something that is not so easy with proprietary closed-source software.
edit: fixed wrong word in my sentence
Edited 2008-04-16 18:12 UTC
The exploits they were talking about seem to have a lot to do with the Flash AVM, which just happens to be open source.
http://www.mozilla.org/projects/tamarin/
Read Touvan’s comment above, then read the article again. You will see that this exploit required detailed knowledge of the internal workings of the VM. If the VM had been closed source developing this exploit would have been more difficult.
Edited 2008-04-16 21:07 UTC
Ah excellent! Then I guess that makes it seemingly less “Inhuman”.
So, certainly this does show that eyeballs *do* review open-source code in the interest of security auditing.
Now, if only the rest of Flash was OSS as well, it could possibly be patched and an update released without waiting for Adobe to fix it themselves.
I have to assume part of Adobe’s decision to open the ActionScript engine was to encourage others to fix the problems and submit patches back so that all can benefit.
Note: I’m not necessarily an open-source zealot – but I can certainly see the benefits.
That exploit is just amazing. At the same time, it is scary to think that a hole similar to step 1 is probably present in many other pieces of software.
On the surface, easy exploits have disappeared from most software or have been disabled by the OS.
Actually, though, hackers are still a step ahead and already planning for their next move.
As long as hackers stay away from open source players, I am safe, I guess.
As I have understood from the article, the exploit relies on a.. excuse me, I hope it doesn’t sound as an insult… on a stupid lazyness. A simple check against NULL in a kind of malloc() operation. Is it that hard? I always thought that programmers who allocate the memory theirselves (instead of using a library that offers protected allocations or at least let the OS check for allocation errors) are responsible enough to check the result of the allocation.
foo = malloc(100 GB);
/* We don’t need to check for NULL because everyone has enough RAM. */
some_operation(foo);
/* We’re sure the operation succeeded */
🙂
And I think it’s unacceptable that “Flash” seems to bypass means of memory protection provided by the OS. “Unimportant” stuff like “Flash”, mostly just used as a video stream player, should not be allowed to break intended system borders in such a way.
I think so, too. But can you really complain about their moves when others make it that easy for them? (Yes, you can, at last I do.)
Woa, I think it was a good idea not to use (install) any “Flash” over the years… 🙂
I don’t think the exploit as basic as you seem to imply.
It does derive from the same programmer stupidity or ignorance as printf(char*) and buffer overflows in string operations, but while those are critical, very known, and rare in production code today, this error is still common.
This is because of wrong assumptions. You will be hard pressed to find a program where a function like fopen isn’t checked for error return values, but malloc is likely to be left unchecked, especially if the code was initially written as a quick hack to get something working.
However, even if the malicious code is able to make an “infallible” function fail, there are many chances that this results at most in simply segfaulting the program. So this adds to the perceived safety of not checking a given function and makes this kind of exploit even more dangerous.
Define “step ahead”. It’s easier to break something than to create something.
Ironically, Amiga, BeOS, Syllable, SkyOS, MacOS classic and other ‘non mainstream’ Operating Systems which never received love from Adobe are safe when browsing a website hosting the vulnerability. Or web browsers which do not have the flash pluggin enabled
Debian is also “flash-safe” if you install software only from the distribution’s main repository.
The reason is that Debian banned the flashplugin-nonfree from Etch (with the R3 release) and from Sarge (with the R8 release):
“Flashplugin-nonfree has been removed, as this is closed source and we don’t get security support for it. For security reasons, we recommend to immediately remove any version of flashplugin-nonfree and any remaining files of the Adobe Flash Player.”
(This flash plugin is still available via backports.org, so that Debian users can still install it if they want to.)
Security problems are a good reason to consider using open source versions of software like Flash. I would like to recommend swfdec, the open source Flash engine, but it it crashes Firefox a lot and doesn’t handle youtube Flash videos. Helping out in swfdec development and testing would make this more of a reality. This would benefit the Linux distros since we wouldn’t have to wait from a binary from Adobe.
http://swfdec.freedesktop.org/wiki/
Edited 2008-04-16 19:57 UTC
“I would like to recommend swfdec, the open source Flash engine, but it it crashes Firefox a lot and doesn’t handle youtube Flash videos. Helping out in swfdec development and testing would make this more of a reality.”
What version of swfdec are you using? swfdec-0.6.4 plays youtube videos fine, provided you have the appropriate gstreamer plugins installed.
You do realize that behind every one of those crashes is probably a bug that’s even more exploitable than this one.
Yes, but the swfdec project fixes bugs as soon as possible:
http://swfdec.freedesktop.org/wiki/
“2008-04-09
Our first security fix release: Swfdec 0.6.4. Please update.”
“Fixes in this release:
– fix a security problem that allowed remote Flash files to read local files.
– fix a rare crash in TextField.replaceText
– fix a rare crash during cleanup.”
Very interesting.
Good thing those crashes arent due to bugs that could possibly be a security risk…
This was fixed in the latest version of Flash Player – released 8 April 2008 so this is olds not news…