LockerGnomeTech news and nostalgia for today's technology professionals
Subscribe

Search

Securitystar wars racergogsynacktivmultiplayervulnerability

A Synacktiv researcher got remote code execution in the GOG version of Star Wars Episode I: Racer through its multiplayer

One unchecked player number in a name packet lets a rogue host take over a joining player's game. The report covers the GOG copy on Windows 10 and doesn't say whether a patch exists.

Chris on a desert racing grid bracing his racer as it slides into a starting slot that hangs off the cliff edge
Illustration: LockerGnome

Star Wars Episode I: Racer is a 1999 PC game, and you can still buy it from GOG. The version in question is, in Synacktiv’s words, “version 1.0 distributed by GOG for the Windows platform,” tested on Windows 10 build 10.0.19045.2965. What Thomas Dubier found is the kind of bug that sits in a game for twenty-seven years because nobody was trying to break a podracer.

The multiplayer layer is the interesting part. The game was built for IPX, an old network protocol, and IPX support was, in the writeup’s words, “officially discontinued starting with Windows Vista.” So the GOG copy ships a wrapper in the game folder: dpwsockx.dll, ipxwrapper.dll, mswsock.dll and wsock32.dll. Per the report, it “emulates IPX by encapsulating packets into UDP datagrams,” on UDP port 54792. A 1990s LAN protocol rides inside modern internet packets, which is a clever way to keep a game alive and an unusual way to widen what it listens to.

The bug itself is plain. Dubier writes: “The function processing type 0x21 packets contains an out-of-bounds write vulnerability.” That packet carries a player index, and the game uses it without checking in a wcsncpy call that copies a name into a player-state array whose name field holds 15 characters. An index of 20 or more writes past the end of the array.

An out-of-bounds write is a weak bug until you can aim it, and the report shows how. A rogue DirectPlay host opens a session. The client joins and sends a type 0x22 message. The host answers with a type 0x21 whose index is chosen to land on an entry in the game’s table of network message handlers, and the value written there points at the receive buffer. A message of type 0x33 then carries the attacker’s code, and the game treats the buffer as a handler and runs it. Dubier’s wording: “A second type 0x33 message containing shellcode is sent, causing the program to execute the code received in the packet.” I’m leaving out the addresses and offsets because the writeup already has them and I don’t think a news story needs to.

So what does that mean for you? A person who joins a stranger’s Racer lobby could have their PC run the host’s code. It takes the old game, the wrapper and a malicious host. It does not take a click on a link or an email attachment, and nothing in the writeup suggests it reaches a PC that isn’t playing multiplayer. Reading it as “Racer is dangerous to own” would be wrong. Reading it as “the multiplayer is only safe with people you trust” is fair.

What the writeup doesn’t tell me matters as much. I couldn’t find what payload Synacktiv used for the demo, when they told the maintainers, or whether GOG has shipped a fix. The proof-of-concept repository, SWEP1RCR-exploit, says it is for educational purposes. If you own the game, check GOG’s changelog for a newer build before you assume the one you have is the one tested.

There’s a bigger pattern here, and it’s one I keep running into. Old games, kept alive by wrappers, inherit the wrapper’s attack surface. The game’s author wrote a LAN protocol for a LAN. Somebody else put it on UDP, and now it has to survive whoever is on the other end.

GOG’s patch status isn’t in the writeup.

More Security

Every Security story →