P16: Practical Progress

Insane tech geekery: inside Mark Dowd's Flash bytecode exploit

Matasano Chargen » This New Vulnerability: Dowd’s Inhuman Flash Exploit

I love this quote:

If you’re not an exploit writer, think of it this way: you know that crazy version of Super Mario Brothers that Japan refused to ship to the US markets because they thought the difficulty would upset and provoke us.

I suppose you would have to have some experience in assembly-language programming to understand anything else in that blog post, but I was laughing at the writing -- Mark Dowd truly is a cyborg! Who else could think of an attack like this?

Also note the screen-shots from "Pitfall", circa Atari 2600, breaking up the otherwise dull technical writing. :)

For non-techies: this is about one specific mechanism by which "bad guys" can make "bad code" run on your computer, despite your best intentions. The fact that it occurs in the Adobe Flash Player means that many people could be vulnerable.

Note that another fellow recently won a MacBook Air by remotely taking control of the MacBook Air -- in this case, also via Flash Player vulnerabilities.

Bad Flash!

Madcap idea #2: "Remote <canvas> Protocol"

Now that I'm writing in public, it feels like I have a backlog of ideas I need to spit out. Here's another of those "noteboook ideas". It pre-dates my "Func-y JS" idea, but stems from the same "trends in hacking" meme.

Say you want to write a client/server GUI application with as little logic as possible on the client. Traditionally, this means: X-Windows, VNC, Windows RDC, or other Remote Desktop Software. Some of these are OS-specific (Windows, Unix). All of these assume that the server authenticates the user before the app is used.

Informally speaking, the server "knows who the user is" before the app can be seen or used.

Contrast this with the web world. Web apps are supposed to be OS-agnostic, and nominally open for "public" usage. Anyone who's built a web storefront, and watched their conversion rates, knows that requiring a user to register prior to checking out means many lost sales. Users don't like to authenticate first for anything, even when their credit card is involved.

So how can we combine the web's "anybody is welcome" ethos with a full client/server GUI. AJAX is one approach. But what if we really want all logic on the server, ala X-Windows? Why might we want this?

• Minimizing client code -> minimizing cross-platform workarounds
• One client -> multiple apps
• Option to insert advertising into the app (free, yet monetized)
• Multi-user experience

Games are sort of an obvious candidate here, but keep client/server latency in mind as a design constraint. A first-person shooter like "Doom" probably won't work with ~70ms latency and all logic on the server. On the other hand, a turn-based game like Scrabulous might work very nicely.

How is Scrabulous implemented today?

• Standalone: Java
• Facebook app: either FBML or external html... only options Facebook provides
• They also have an "email-based" game

I was writing Scrabulous, I'd hate to implement the same game 2, 3, or more times. Can we unify these approaches somehow?

Madcap Idea: "Remote <canvas> Protocol"

<canvas> is an HTML element introduced by Safari, now supported in Firefox and part of HTML5. It's possible to emulate <canvas> in Internet Explorer without plugins – Google does this today on Google Maps.

Per Wikipedia:

Canvas consists of a drawable region defined in HTML code with height and width attributes. JavaScript code may access the area through a full set of drawing functions similar to other common 2D APIs, thus allowing for dynamically generated graphics. Some anticipated uses of the canvas include building graphs, animations, games, and image composition.

Sweet! It's a simple but full-blown 2D API, already cross-platform and standardized. But it's accessible only to client-side JavaScript. How do we move our "application logic" to the server? Write a small bit of client-side JavaScript that:

• Opens one XMLHttpRequest to the server
• Read rendering commands from here and relay to the canvas
• Set event handlers to capture user clicks & keystrokes on the canvas
• Relay user clicks & keystrokes back to the server over a 2nd XMLHttpRequest, or the first one if that's possible

Gee, that sounds pretty simple. Can this possibly work? I may have to throw together a proof-of-concept to find out. :-)

Madcap idea: "Funky (func-y) JavaScript"

I haven't exactly finished setting this blog up yet, but an idea just occurred to me, and rather than jot it in my paper notebook, I thought I'd post it publicly for y'all to see.

This is probably a harebrained idea. I'm sure I'll see some flaws in it tomorrow, and you will see them even sooner.

Madcap idea: "Funky JavaScript" (FunkyJS):

1. Define a strictly functional subset of JavaScript – code which, if translated, could run within the Erlang virtual machine. (Key restriction: no mutable variables. All variables must be write-once, as in Erlang.)
2. Build a JavaScript parser in Erlang
3. Try to generate Erlang bytecodes and run the result!

I'm calling it "Funky" because it's func -> functional. And weird too.

Yeah, I'm demented to even consider this. But it falls right at the intersection of a whole bunch of problem domains that I've been looking at:

1. CouchDb is implemented in Erlang, and uses JavaScript as its query language. It uses Mozilla Spidermonkey as its JS engine, but as you can see on their dev blog, this has its downsides.
2. Erlang holds incredible promise for running distributed server-side programs. But the language is very different from anything else in the standard web-development toolbox (Perl,PHP,C,Java,etc).
3. AJAX is a cross-platform UI juggernaut. If you want to make a web-connected application that "runs everywhere", and can overcome the cross-platform quirks, you build it on AJAX. It works today on iPhone and Maemo and Android. Need I say more?
4. JavaScript is the "J" in "AJAX". It's everywhere.

Erlang is very capable on the server. JavaScript is ubiquitous on the client side. If we could bridge this gap, perhaps some really interesting apps could emerge?

How about a multiplayer game like Scrabble or Battleship that works as a Facebook app, on iPhone, and every desktop web browser? How about massively-multiplayer, with tournaments and ranking and embedded advertising too? (ala Bejeweled or Pogo.com)

I'm talking about taking web technologies far beyond the level of "interaction" that we're accustomed to.

As Douglas Crockford says, "JavaScript is a sloppy language, but inside it there is an elegant, better language." His Little JavaScripter even demonstrates how to rewrite all functions from "The Little Schemer" into JavaScript. Thus, it should be possible to do the inverse (JS->Scheme) given a strict enough subset of JS.

Erlang is a functional language like Scheme, so hopefully JS->Erlang would be similarly possible.

I'm glossing over lots of details of how a "dynamic, run-anywhere, multiuser app" would work, of course. Think of it as an AJAX app with a critical enhancement: write code that runs on the client or on the server, however it suits your problem, with no performance penalty. Make the client as smart or dumb as necessary, and re-balance the client/server workload as you go. Possibly even on-the-fly.

Imagine Google Docs Spreadsheet doing simple calculations on the client, heavy calculations on the server. Maybe you push more calculations to the server when the client has a weak CPU like iPhone.

Ok, this is pretty sci-fi. But tools like Dashcode make AJAX programming awfully accessible. Is the rest so far-fetched?

Last note: Douglas Crockford's JSLint is a JavaScript syntax checker and validator, in JavaScript. His Pratt Parser may be a darn good model to follow.