Xonotic developers are censoring servers via client-side hac

[Lyberta]

Xonotic is a free software game which was forked from Nexuiz in 2010. The game uses DarkPlaces engine and the game code is written in QuakeC which is compiled into the bytecode. This makes it possible to make client-side mods and upload the bytecode to the client during connection.

Over the years, a lot of mods has been produced. However, in 2016 an interesting mod was made. Someone has made the old Nexuiz code compatible with Xonotic and people started hosting servers with Nexuiz-like gameplay on the Xonotic master server list.

These servers can be thought of as substantially modded but the QuakeC nature makes them compatible with Xonotic client. Over time, these servers gained players and became very popular. This, however, had an interesting effect on the Xonotic developers.

If you open the checkupdate.txt file in /misc/infrastructure directory, you will see that there are some less-known features of the game. In particular, there is a list of banned servers. Xonotic master server is not hosted by Xonotic devs so they have added a client-side ban list. What's worse, it looks like this banlist doesn't care which master server you actually use.

So, in the end, Xonotics devs have added Nexuiz-like servers to the client-side ban list. They say that say these servers have compatibility problems and "people shouldn't play 6 years old games". The forum topic that mentioned this issue got closed and moved to a subforum which is not accessible to nonregistered users.

This really shows that Xonotic developers are insecure and possessive. We value free software because we want to play games the way we want. Banning legitimate servers is a censorship that is not tolerable in free society.

Thankfully, the fix is simple. After you've downloaded the game, open /misc/infrastructure/checkupdate.txt and remove all lines starting with "B". Unfortunatelly, most of the players won't know this and would continue to see censored server list.

UPDATE: I have found that those servers do break client. If you connect to vanilla server after connecting to those servers, some maps will be overwritten with Nexuiz ones. But banning those servers is not a proper fix. Xonotic should just unload all custom content when connecting to vanilla server. Also I found that this ban doesn't work in the git version.

[Duion]

Why you always want to make drama?

[charlie]

This really shows that Xonotic developers are insecure and possessive. We value free software because we want to play games the way we want. Banning legitimate servers is a censorship that is not tolerable in free society.

So, I agree, on the face of it (presuming your description is accurate) it is wrong.

However isn't the advantage of open source the ability to do something about it? You, or people who care - such as those running the mods - can fork Xonotic. You can keep it in sync, so you don't have to do anything other than maintain the reversion of the ban.

Or do you desire to control their development, because they do something you do not like?

[leilei]

This is not "censorship", it's a filter workaround to maintain the Xonotic experience. Banning the servers from the master end would mean excluding Nexuiz from using the same master at all and that would be a bit closer to this so-called "censorship".

Considering one of Xonotic's forks turned into....it may be a blessing in disguise.

[andrewj]

While I don't like the idea of servers being completely hidden from the user (and no way of knowing they exist or to turn off the hiding), I bet the Xonotic developers have good reasons to ban those servers.

A "free society" does not mean people can do absolutely anything they want. For example, many online games will ban people who cheat or who are only griefers, which helps everyone else who are playing the game. The banned people may feel their rights are infringed, but everyone else are very glad they cannot come in and ruin the game.

[c_xong]

Usually games have a "modded server" filter that the user can choose, so they can play on modded servers or vanilla ones as they please. Is this what the Nexuiz servers essentially are, or is there more to the story? FaTony is not giving us the full story here.

[Lyberta]

However isn't the advantage of open source the ability to do something about it? You, or people who care - such as those running the mods - can fork Xonotic. You can keep it in sync, so you don't have to do anything other than maintain the reversion of the ban.

Or do you desire to control their development, because they do something you do not like?

Of course I can fork. It just requires consistent effort. The only problem I have is them banning modded servers that that are not abusing the game.

This is not "censorship", it's a filter workaround to maintain the Xonotic experience.

I couldn't care less about "Xonotic experience" or "Red Eclipse experience" or any other vanilla game experience. I have chosen free software to play the game the way I want, not what devs want.

While I don't like the idea of servers being completely hidden from the user (and no way of knowing they exist or to turn off the hiding), I bet the Xonotic developers have good reasons to ban those servers.

The reason stated by the devs is "if you want to play Nexuiz, download Nexuiz client and don't use our master server". My point is that whatever code is running on those servers is compatible with Xonotic client and doesn't abuse/crash/whatever.

Usually games have a "modded server" filter that the user can choose, so they can play on modded servers or vanilla ones as they please. Is this what the Nexuiz servers essentially are, or is there more to the story?

Yes, those servers are shown in "Modded servers" section. They are clearly marked as such and don't pretend to be vanilla.

FaTony is not giving us the full story here.

Here's the full story. I use 0.8.1 client which doesn't have any bans in the client. Usually, when I open server list, I see people playing on those Nexuiz servers. I've played on those servers too and found them OK. Then, a few days back I was searching Xonotic forum for some unrelated config option and stumbled upon this thread. The bans were added to the git and are not in the stable version yet. I'm attaching the saved copy so you guys can see the full text of that thread.

[charlie]

This is not "censorship", it's a filter workaround to maintain the Xonotic experience.

I couldn't care less about "Xonotic experience" or "Red Eclipse experience" or any other vanilla game experience. I have chosen free software to play the game the way I want, not what devs want.

The problem you have is the development model, Free software, gives the developers their own freedom to do what they want. You choose Free software so you have the freedom to do what you want with that software, but what they want and what you want are 2 distinct things and you have no right to try to control their goals. You DO have a right to fork. That is why Free software is good for you, not because it allows you to analyse the code then complain about it.

[Lyberta]

I come from Valve games circa 2005 which allowed modded servers and didn't censor them. I am now surprised that free games don't have that freedom.

[Sauer2]

which is compiled into the bytecode. This makes it possible to make client-side mods and upload the bytecode to the client during connection.

That reminds me to ask OT stuff: Has anybody (or do you know someone security related that) tried to create a server that uploads handcrafted bytecode to break out of the VM?

To clarify: Have QuakeC vms some kind of bytecode verifier or do Quake-like players rely on servers that are assumed to be trustworthy?

[Lyberta]

That reminds me to ask OT stuff: Has anybody (or do you know someone security related that) tried to create a server that uploads handcrafted bytecode to break out of the VM?

To clarify: Have QuakeC vms some kind of bytecode verifier or do Quake-like players rely on servers that are assumed to be trustworthy?

I would guess that each function that is possible to call from VM has been audited for security. Otherwise, there would be tons of viruses from the Quake days.

[Sauer2]

That reminds me to ask OT stuff: Has anybody (or do you know someone security related that) tried to create a server that uploads handcrafted bytecode to break out of the VM?

To clarify: Have QuakeC vms some kind of bytecode verifier or do Quake-like players rely on servers that are assumed to be trustworthy?

I would guess that each function that is possible to call from VM has been audited for security. Otherwise, there would be tons of viruses from the Quake days.

This is not so much about functions the VM calls but the VM itself, as explained here: https://www.dartlang.org/articles/dart- ... e-of-trust
For example, imagine, one would do a jump to an adress that doesn't exist as part of the bytecode.

[andrewj]

That reminds me to ask OT stuff: Has anybody (or do you know someone security related that) tried to create a server that uploads handcrafted bytecode to break out of the VM?

To clarify: Have QuakeC vms some kind of bytecode verifier or do Quake-like players rely on servers that are assumed to be trustworthy?

In Darkplaces (which Xonotic uses), the VM with all the game code runs on the server, and the client does not need a copy of it. So each server can have completely different QuakeC game code.

There is also two other VMs which run client-side, which are mainly UI stuff. These can be downloaded from the server (i.e. the server can supply modded client-side QuakeC code). There is a CRC check to guarantee that the client has the VM code which the server expects -- that check may be optional though (I'm not sure).

[Sauer2]

@andrewj: Interesting, thanks.

[Lyberta]

There is also two other VMs which run client-side, which are mainly UI stuff. These can be downloaded from the server (i.e. the server can supply modded client-side QuakeC code). There is a CRC check to guarantee that the client has the VM code which the server expects -- that check may be optional though (I'm not sure).

The question is can malicious code escape from those VMs.

[andrewj]

The question is can malicious code escape from those VMs.

File creation and writing are strictly "sandboxed" to a particular folder, something like $HOME/.darkplaces/name_of_mod/data on Linux, and it cannot overwrite any normal files of the game or any other parts of the filesystem.

File reading is a slightly more relaxed but still sandboxed, limited to files of the game or mod (including stuff in pk3 files) and also the write directory mentioned above, but cannot read any other part of the filesystem.

So no, downloaded client-side VMs cannot do anything malicious.

[Sauer2]

So no, downloaded client-side VMs cannot do anything malicious.

Assuming, the client verifies the bytecode sufficiently. Which may harder than it sounds at first, given that JVM, Silverlight CLR and NaCL had their share of holes in their verifiers and Python and Lua gave up. Apparently, the original QuakeC VM has some kind of bytecode verification - whatever good that was - but I wasn't able to find it in the Darkplaces implementation, so I assume they either didn't reimplement it or removed it...

[onpon4]

I think the more interesting question is: does Xonotic download these programs by default without consulting the user? If yes, then that would mean that Xonotic and other games that have this feature need to be added to this list:

https://onpon4.github.io/other/gaming-trap/

Because if the source of the code is whatever server you happen to be playing on, then it could easily be proprietary software that you're downloading and executing without knowing it. I would suggest to the Xonotic developers that this feature should be removed, or possibly replaced with an official, audited source of libre UI modification scripts.

Also, it is my firm opinion that sandboxing is a losing battle. There is always something you're overlooking, so any time you depend on sandboxing to protect users (in this case from malicious server operators), you make it necessary to be constantly on the lookout for these things and deliver prompt security updates. No feature is ever worth that stress or risk. Just make sure that any new script added to the program is installed because of the explicit action of a user, and maybe include a notice that the user should check the integrity of these scripts before installing them, or only install them from trusted sources. Leave any security beyond that to the OS.

[Lyberta]

I think the more interesting question is: does Xonotic download these programs by default without consulting the user?

Yes, and there is no license attached. That's why in my Libre Gaming Manifesto I outlined the following:

If possible, every content that is uploaded to the client should have a license which can be checked before downloading the content

As with JavaScript that makes most people run proprietary software automatically without their acknowledgement, proprietary content that is automatically uploaded to client is a threat to freedom. A good game will at least display a warning message before downloading proprietary content.

If possible, there should be a way to easily download the source code of all custom content that is used by the server

If you are playing it, you should have access to the source. If you don't have it, you are playing a proprietary game even if it is on a specific server.

[andrewj]

Assuming, the client verifies the bytecode sufficiently.

There is no need to verify anything. The bytecode is interpreted and has limited functionality, for example it can only access memory set aside for the VM, not any arbitrary memory, and can only call built-in functions, which again are limited in what they can do (I already described how the file functions cannot access anything outside of game folders).

The examples you give (JVM, CLR) are designed for running full applications and hence are naturally difficult to sandbox. QuakeC has a much much smaller scope and is perfectly sandboxed (barring bugs in the engine).

[Lyberta]

QuakeC has a much much smaller scope and is perfectly sandboxed (barring bugs in the engine).

Perfectly? Was there a security audit?

[onpon4]

Security is a side issue. The main issue is whether or not software is silently installed and executed on the client's machine without the consultation of the user of the client. It's bad for the same reason that JavaScript is bad.

Could anyone link to some examples of these programs, or a document explaining what they do in better detail? I don't know what to look for in the Xonotic source code.

[Lyberta]

Could anyone link to some examples of these programs, or a document explaining what they do in better detail? I don't know what to look for in the Xonotic source code.

If you download the Xonotic release from the site, a QuakeC code is in source/qcsrc.

[Wuzzy]

Thank you for this Public Service Announcment.
I literally had not known that some servers are hidden. OMG.

I would have changed that immediately, but I can't find the file, however. No “misc” folder anywhere. Can you please give me a hint where I have to look? I'm on Arch Linux.

But I don't really think this is so “evil”. Maybe a “lesser sin”. If they had banned a Xonotic-modded server, that would be a different beast.

But the easiest fix for this is obvious:
If you want to play Nexuiz, just download Nexuiz.

[Lyberta]

I don't know where it can be if you installed it via package manager. If you download a zip or cloned git repo from official website, it's in its root.

Since the first post I have found that those servers do break client. If you connect to vanilla server after connecting to those servers, some maps will be overwritten with Nexuiz ones. But banning those servers is not a proper fix. Xonotic should just unload all custom content when connecting to vanilla server. Also I found that this ban doesn't work in the git version.