July 7th, 2008
C to be the next browser scripting language... wait, what?
First off, I hope that everyone’s fourth of July was as good as mine. There’s nothing quite like spending time with family and friends over the holidays to put your work-life relationship into perspective of what’s important.
In any case, the security news didn’t stop for the holidays, no, if anything it picked up. As if people were trying to fly things under my nose while I was enjoying the fireworks. Well, I’m playing catch up now, and one of the first things that caught my attention was a recent story posted on Slashdot about a talk with Adobe’s Scott Petersen where he demonstrated a “new toolchain… that allows C code to be run by the Tamarin virtual machine.”
The toolchain includes lots of other details, such as a custom POSIX system call API and a C multimedia library that provides access to Flash. And there’s some things that Petersen had to add to Tamarin, such as a native byte array that maps directly to RAM, thereby allowing the VM’s “emulation” of memory to have only a minor overhead over the real thing. The end result is the ability to run a wide variety of existing C code in Flash at acceptable speeds. Petersen demonstrated a version of Quake running in a Flash app, as well as a C-based Nintendo emulator running Zelda; both were eminently playable, and included sound effects and music.
So, the geek in me wants to think that a Flash version of Quake is pretty sweet, but the security expert in me can only think of the following:
- Take Flash, a browser-based technology that is used in a huge percentage of computers out there, and more importantly, has had it’s own fair share of flaws (see Pwn2Own Contest results from this year)
- Add the ability to “run a wide variety of existing C code in Flash”, where C is clearly a language that has had devastating memory corruption flaws
- Add quotes like, “Petersen had to add to Tamarin, such as a native byte array that maps directly to RAM”
- Keep in mind that this will all be running in your browser, i.e. the playground for most of the major attacks of the last couple years
- And you get what?
A major set of flaws waiting to happen.
So we’ve come full circle with dynamic web programming:
- We tried the established: Java, VB
- We moved into the new: .NET, AJAX, XML (Web Services), Ruby on Rails, etc.
- Now we move into the new, which is actually the old: C
I can see what’s coming next. ADA and Prolog for web applications. In any case, I know nothing of any plans that Adobe has to actually do this in real life, it might just be an interesting research project. In fact, I don’t fault Adobe for this idea, it’s actually really cool and I don’t want to be the voice stopping innovation of anything that is cool. I’d just like to stress that if we’re going to use C/C++ or any other older language for our web application programming, let’s think about the ramifications and implement it in a way that helps developers program it securely. So, kudos to Scott Petersen and Adobe for trying something innovative, now let’s do it secure if we do it at all.
Loading ...-Nate
Nathan McFeters is a Senior Security Advisor for Ernst & Young's Advanced Security Center in Chicago. The views and opinions expressed in this article are his own and do not represent the views and opinions of Ernst & Young Advanced Security Center or Ernst & Young, LLP. Nathan has performed web application, deep source code, Internet, Intranet, wireless, dial-up, and social engineering engagements for numerous clients in the Fortune 500 during his career at Ernst & Young and has spoken at a number of prestigious conferences, including Black Hat, DEFCON, ToorCon, and Hack in the Box. He can be found at his Pwn* blog and XS-Sniper, a blog with Billy Rios. See his full profile and disclosure of his industry affiliations.
