Should automatic downloads be on by default in the `next release`?

[+ OPTIMUS +]

The real security issue is that there shouldn't be risks that most of us already has here at 1.1. isn't that a kind of paradoxon? :-)

[mooseberry]

I think it should be on. I don't think that with Tremulous there is very much a risk, and I have been playing games like COD UO and wolfenstien for a long time and not gotten any problems.

[Amanieu]

Let me clear up a myth: DLLs can not be loaded from a pk3, the dll must be manually installed into your base folder, and only you can do that. Also, most exploits which allow executing arbitrary code on the client from qvms have been fixed.

Now, about enabling auto-downloads: I vote for enabling them, but with risujin's download prompt. This will allow people to control whether they want to download stuff or not, all while allowing trem to be modded and custom maps to be made.

[tuple]

Also, most known exploits which allow executing arbitrary code on the client from qvms have been fixed.

fixed that for you.  Nothing against the present tremulous and/or ioq3 codebase, but bugs happen.  Security decisions shouldn't be made for the user unless its encourages greater security.  Even if the user doesn't fully understand the decision and/or risks, it is still their decision to make.

Downloading code that is run is a security risk.  As it should be the decision of the user, that decision should be offered to them, not foisted upon them.

[tuple]

Also, most known exploits which allow executing arbitrary code on the client from qvms have been fixed.

fixed that for you.  Nothing against the present tremulous and/or ioq3 codebase, but bugs happen.  Security decisions shouldn't be made for the user unless its encourages greater security.  Even if the user doesn't fully understand the decision and/or risks, it is still their decision to make.

Downloading code that is run is a security risk.  As it should be the decision of the user, that decision should be offered to them, not foisted upon them.

edit: personally, I would feel much more comfortable with a one or two time prompt that is short and sweet that informs the user that there are inherent security risks with turning on autodownloads, but that the game may be more fun if they do.

[Amanieu]

Screenshot of risujin's download prompt:
https://bugzilla.icculus.org/attachment.cgi?id=1334&action-view
I'm adding this to tremfusion for our next release.

Broke the link - got tired of Icculus's self-signed cert whining. --Rocinante

[daenyth]

Very nice! Hmm, maybe it's time I updated my client from the 2006 TJW build...

[kevlarman]

Very nice! Hmm, maybe it's time I updated my client from the 2006 TJW build...

the download prompt doesn't work with just an updated client.

[David]

Let me clear up a myth: DLLs can not be loaded from a pk3, the dll must be manually installed into your base folder, and only you can do that. Also, most exploits which allow executing arbitrary code on the client from qvms have been fixed.

Now, about enabling auto-downloads: I vote for enabling them, but with risujin's download prompt. This will allow people to control whether they want to download stuff or not, all while allowing trem to be modded and custom maps to be made.

And the QVM can write that DLL, it can drop code anywhere on your system, and it can then screw you some more.

Its been proven time and time again that there are retards who hate this community and have the time and resources to hurt it.
IMO It should only download to the base folder, and refuse to load anything from that folder other than maps.  Data / vms can go in the install folder, and mods can be installed by hand / some other more user-involved system.

[Posts]

So auto-downloading is by design about more than maps / models / and any other eye candy?

the people who coded it are actually aware that this qvm/scripting-stuff can be downloaded and executed?

has it been confirmed that the developers have actually been informed of the exploits? ioquake3 devs?

btw, this poll is useless as the people who are voting are not fully informed and they might even think that the only way it can be abused is for downloading porn, i read this thread and i still don't feel like i'm qualified to even vote on this, i don't know which opinions are those of experts or trash, there are conflicting opinions. there might be a huge history on patched security problems for this game i don't know about because people are still afraid of talking about it. do things get properly fixed? buried in a changelog or not even included in a change log? does the ioquake3 project get the relevant patches/reports?

On the subject of buffer overflows: there will always be buffer overflows everywhere, the network protocol can be buffer overflowed, on a game with millions of players and autodownloading enabled by default i don't believe there has been a single case of people buffer overflowing through the maps / eye candy. People can buffer overflow you through the forums, with external images, links, flash, internet explorer.

I expect to see a future full of much simpler exploits than buffer overflows, like clients downloading a config with the rcon password, servers downloading files from clients, mods containing back doors, a guid system that never really gets fixed, never ending confusion about mods/qvm/dlls/scripts/security, anti cheat methods backfiring.

On the subject of abusing the download system to ddos people: if the game clients send the game servers IP in the referer variable to the web server, a simple php script or .htaccess file can prevent other servers from using their fast download service.

Multiple security risks? how many? how do we even know which we're talking about? is someone assuming that everyone else knows about an exploit that only that person knows about?

• All executable code off, but with the option to turn it on (QVMs, etc) with a very stern warning of why it's a bad idea
• An in-game "Do you want to do this" kind of option which can ask if you really want to trust that QVM you just downloaded

What is the history of autodownloadable QVMs doing good things? aren't the server side only mods capable enough?

I think popping up a question for this is a bad idea, no matter how stern you are the end user is not qualified to make the decision like this, the end user will either be left confused and uncomfortable or carelessly vulnerable. I see this as a bad way of transferring responsibility.

[Posts]

Lava Croft: fixed

[Lava Croft]

Please refrain from double posting and click the 'Modify' link to modify your post and add anything you forgot earlier.

[Lakitu7]

What is the history of autodownloadable QVMs doing good things? aren't the server side only mods capable enough?

No. One very frequent example is the scoreboard: If any mod has a gametype that isn't humans vs aliens scored on "kills", the scoreboard will not reflect this without a download.

[cactusfrog]

everything has some risk to it.  maybe tomorrow someone will steal your computer or your house will burn down leaving the fact that you had auto downloads disabled completely pointless.  you might get a few virus on your computer from tremulous or from downloading that torrent.  disabling auto downloading is done only by the devs and smarte people because they know what can be done to there computer through 1 second of auto download they can predict the future and know what pk3s to download in advance they know all. 

[Syntac]

Automatic downloads should be off, but when the player has to download something or disconnect, they should be given the option to do so (and a warning that it may be malicious). Risujin's prompt seems best for this.

[Amanieu]

And the QVM can write that DLL, it can drop code anywhere on your system, and it can then screw you some more.

Wrong, wrong, maybe if someone finds another hack in the future, but it will be fixed as soon as possible and someone (if the devs don't) will release a fixed client.

IMO It should only download to the base folder, and refuse to load anything from that folder other than maps.  Data / vms can go in the install folder, and mods can be installed by hand / some other more user-involved system.

That's pretty much killing all the mods that exist. How about you keep your standard qvm, and then have the client download scripts to extend it?

I think popping up a question for this is a bad idea, no matter how stern you are the end user is not qualified to make the decision like this, the end user will either be left confused and uncomfortable or carelessly vulnerable. I see this as a bad way of transferring responsibility.

What solution do you suggest?

[Lakitu7]

Wrong, wrong, maybe if someone finds another hack in the future, but it will be fixed as soon as possible and someone (if the devs don't) will release a fixed client.

Oh great, then the fix will be pushed through the auto-update mechanism and nobody will be able to play until they update their clients, right? Oh wait, actually a really small percent will ever download an updated client, especially if not official. The safety of non-upgraders is still a factor when making decisions like this.

That's pretty much killing all the mods that exist. How about you keep your standard qvm, and then have the client download scripts to extend it?

Client auto-downloads of vms to base produce unpredictable behavior in the current generation of clients because it is assumed that one would never have vms auto-downloads to base. This is because the very concept of having mods to the base game is rather strange. If your mod goes beyond what you can do without changing the vms, it dedidedly shouldn't have fs_game=base. Servers can very happily either force or allow people to use different models/skins/other assets (yes, even within sv_pure), which really is about as far as a mod to base should ever go before it's no longer "base" and shouldn't pretend it is by not changing fs_game.

[seeeker]

*removed as this suggestion was made already =P*

[Amanieu]

Oh great, then the fix will be pushed through the auto-update mechanism and nobody will be able to play until they update their clients, right? Oh wait, actually a really small percent will ever download an updated client, especially if not official. The safety of non-upgraders is still a factor when making decisions like this.

Well then just get an auto-update system. I will.

Client auto-downloads of vms to base produce unpredictable behavior in the current generation of clients because it is assumed that one would never have vms auto-downloads to base. This is because the very concept of having mods to the base game is rather strange. If your mod goes beyond what you can do without changing the vms, it dedidedly shouldn't have fs_game=base. Servers can very happily either force or allow people to use different models/skins/other assets (yes, even within sv_pure), which really is about as far as a mod to base should ever go before it's no longer "base" and shouldn't pretend it is by not changing fs_game.

But you still said you wouldn't allow any vms downloads, even to another fs_game folder.

[Lakitu7]

Well then just get an auto-update system. I will.

But you still said you wouldn't allow any vms downloads, even to another fs_game folder.

I did? Enlighten me where. You seem to have mistaken my calling you out on your false assumptions to mean I hold the opposite position.

No, I think that vms downloads should be seperate from map downloads, as others have said here. Map downloads should default to on. VMS downloads should have a nice large download/warning prompt.

[Amanieu]

IMO vms and game data shouldn't be treated separately. They can both be abused. They can both be exploited if a bug is found in the code which handles them.

[Syntac]

I fail to see how maps can be abused. Sure, you can piggyback a QVM onto one. But if there's code that detects QVMs, the problem is nonexistent.

[cactusfrog]

And the QVM can write that DLL, it can drop code anywhere on your system, and it can then screw you some more.

Its been proven time and time again that there are retards who hate this community and have the time and resources to hurt it.
IMO It should only download to the base folder, and refuse to load anything from that folder other than maps.  Data / vms can go in the install folder, and mods can be installed by hand / some other more user-involved system.

That system would work except for mods for them there should be a pop up message asking if you are willing to except the risk like what was was suggested earlier.   

[Amanieu]

I fail to see how maps can be abused. Sure, you can piggyback a QVM onto one. But if there's code that detects QVMs, the problem is nonexistent.

A buffer overflow in the loading code and you can run arbitrary code.

That system would work except for mods for them there should be a pop up message asking if you are willing to except the risk like what was was suggested earlier.  

And that wouldn't work anyways since any newer revision of trem prevents writing a DLL.

[Lakitu7]

Yes executable exploits in non-executable code are possible and do happen, but the odds are far less than with running VM code. Loading a map in Trem isn't any different from loading a jpeg in your browser. Web browsers don't default-off all images because they could exploit an unknown bug in the jpeg parser, but they do warn users when they are downloading executable files.

Yes, exploits in jpegs and mp3s and such have all happened, but it's still incomparable to the risk taken by running executable code on-purpose, and in current computing paradigms that very low level of risk is an acceptable one.

If such a thing happened, there WOULD be an official update release.

[gimhael]

But QVM code is more like Java code. It runs in a sandbox. There may be bugs that allow to escape from the sandbox, but it doesn't play in the same league as downloading and running native executable files. IMHO, if there is such a bug it isn't different than a exploitable bug in the jpeg or bsp or whatnot loader.

[Amanieu]

But QVM code is more like Java code. It runs in a sandbox. There may be bugs that allow to escape from the sandbox, but it doesn't play in the same league as downloading and running native executable files. IMHO, if there is such a bug it isn't different than a exploitable bug in the jpeg or bsp or whatnot loader.

Exactly my point, thank you.

[David]

A java program can trash your computer, and so can a QVM.
QVM's were *not* designed with security in mind at all, and as such will *never* get an acceptable level of security without a complete redesign.
Like with java, the aim is compatibility across incompatible systems.

Also, allowing 3rd parties to run code without my interaction would probably be enough to get tremulous classed as malware, and without a good EULA, would (I think) be illegal under UK law.

[gimhael]

Im all for user confirmation to *run* any code in the pk3 (with an option to skip the confirmation permanently for selected pk3s), but I think the issue here is the *download* of pk3s. I think it's just as dangerous to run an autodownloaded pk3 as it is to run a map-super-fun.pk3 that I had to manually download from a web server.

As for EULAs, I think all QVM code is GPL'd, so if someone hides a QVM in a map, they have to distribute the source code too, so anyone can quickly check the code for exploits. 

[David]

Why waste time downloading something I'm not going to run?
And there's no database of info about the pk3's, so how's it to remember which ones I like?  Or should it prompt about them all every run?
The GPL covers distribution, EULA's cover usage.  There is a massive difference.
Also, you are not required to agree to the GPL to download or use GPL software, the distributor just has to make reasonable effort to make sure you know it exists.