Buffer Overrun In Antitrust

Skip this unless you’re really, really geeky.

Still with us? OK. In the movie “Antitrust“, there’s a screenshot of some code that has a possible Denial Of Service vulnerability:

 /* are we doing a GET or just a HEAD */
            boolean doingGet;
            /* beginning of file name */
            int index;
            if (buf[0] == (byte)'G' &&
                buf[1] == (byte)'E' &&
                buf[2] == (byte)'T' &&
                buf[3] == (byte)' ') {
                doingGet = true;
                index = 4;
            } else if (buf[0] == (byte)'H' &&
                       buf[1] == (byte)'E' &&
                       buf[2] == (byte)'A' &&
                       buf[3] == (byte)'D' &&
                       buf[4] == (byte)' ') {
                doingGet = false;
                index = 5;
            } else {
                /* we don't support this method */
                ps.print("HTTP/1.0 " + HTTP_BAD_METHOD +
                           " unsupported method type: ");
                ps.write(buf, 0, 5);

Because I can’t resist such things, I paused the movie to read over the code. Now, I’m assuming this is Java instead of C++ because “boolean” wasn’t spelled “bool”, although I’m not sure why they’d be using Java for performance critical code. Anyway. See the “ps.write(buf, 0, 5);” line near the end? Well, “buf” is presumably the string that the client sent to the server. If the client is broken (or malicious) enough to misspell “GET” and “HEAD”, then the server politely tries to tell the client what it did wrong by sending “buf”‘s value back.

Which brings us to the hack. If “buf” is less than five characters long, then that “ps.write” line will attempt to read past the end of “buf”. If the calling function doesn’t handle index error exceptions, boom! The service crashes: Denial Of Service. Note that this is still better than the C++ equivalent, which would write the contents of memory immediately following the end of “buf” back to the client.

No, I’m not exactly good at sitting back and watching movies.

How Not To Save A Game

I was about halfway through a game called “Final Fantasy XII: Revenant Wings” on my Nintendo DS. I was having a great time and loving it until a stupid bug wiped out all the work I’d put in and made me start over.

When I was in the middle of a particularly involved battle, the red “low battery” warning light came on, so as soon as I finished I tried to save my game. Big mistake. The DS used up its remaining power during that instant and turned itself off. When I plugged it into the charger and turned it back on, I got a message saying that my game file was corrupt and had been deleted.

OK, in retrospect, I should have plugged my DS into the charger before I tried to save my game. Still, it should be impossible to destroy your old information by writing a new version of it. That’s just good design. Unfortunately, FFXII doesn’t have a good design. See, the problem is that FFXII saves its game by writing over the pre-existing save file. Since the power died during that write, the results were half old game and half new game. Hence corrupt. Hence deleted. Here’s how a competent programmer would handle the same situation:

  1. Create a new save file and write the information to it.
  2. Delete the old file.

See the difference? At no point do the two files get mingled together, and the old file stays valid and ready to use until the new one is completely written. In the absolute worst case of a power failure during the saving process, you’d lose the new information but the old data would still be intact and safe.

I don’t know whether the buggy code was written by Square Enix, or if they were using Nintendo’s built-in game saving method. Regardless, it’s dumb and should be fixed ASAP for all new games.