Security, Lua, and You

[lurker]

flash, java, acrobat, etc. count as part of a normal install; won't a jar run then?

[ZellSF]

Probably. Shouldn't you have listed pdf then? (I heard about some recent security issue with that) and swf maybe, don't know if that can do much even when run locally.

Microsoft Office files can execute stuff too I think? but that requires the user to say yes first...

[lurker]

I don't care about application exploits, I'm talking about something where double clicking it gives it 100% control over your user account.

[ZellSF]

msi then? Not sure if that can do things silently by default.

[Pxtl]

Do the opposite then - force the lua to only write files with a ".luadata" extension.

[el_matarife]

Yeah, I think building a whitelist of files Spring should be able to access is better than building a blacklist of files Spring shouldn't touch.

[SpliFF]

We're talking about DLLs here. Whitelists/blacklists are moot when a DLL can do practically anything it wants. On the flip side denying access to dlls and io features restricts the ability of authors to create powerful widgets and gadgets.

The only solution that meets both requirements is to allow users to opt-in to unsafe scripts by blocking said widgets/gadgets/maps from using the package facility until the user acknowledges the risk.

I would recommend the following approach, to minimise hassles:

* When a script requires dll access the dll is md5sumed and cross-checked against an official list of approved dlls. Approval would require the dll code is open-source and has been checked by 2 or more devs. Any modification to the dll would require it be re-approved.

* If a dll is approved Spring silently loads the dll. If a dll is registered, but marked as bad, Spring rejects it outright. If it is unknown the user receives the message:

"This script is attempting to load a custom low-level library. Libraries add additional speed or functionality to a widget, map or mod but can also perform unsafe actions on your system or make Spring crash. Click 'yes' if you trust the author and accept the risk. Otherwise click 'no' to permanently disable the script."

[lurker]

Actually this isn't about dlls. This is about the other issues of free i/o. Blocking widgets from writing dlls is trivial, or we could try this system of yours.

[AF]

Its very possible that there's no need for those kinds of lua widgets because the lobby did it for them ;p

[zwzsg]

I'd rather have my own .dll instead of being forced to rely on highly unreliable lobbies, kthxbye.

Well, technically all I really need is a Spring.Rehost(script); working with script both inside the mod and dynamically written by the lua.

So I need Lua to be able to write files, too.

Right now I am also enjoying the ability to call any .exe and run my own C algorithm, but won't press too hard on that as I guess that is unsecurisable.

[Pxtl]

Spring should be able to _call_ an exe or dll within the Spring directory heirarchy. It just shouldn't be able to create one. After all, lots of mods will need features outside of the Spring engine, and that's the best way to provide them.

The real trick is that none of the deployers/packagers/whatever should support those dlls/exes, so that users can't _accidentally_ get the dangerous files. It's one thing to go download my crazy mod with joystick-support or whatever from FilePlanet... quite another to get that dll automagically through SpringDownloader.

[Argh]

Spring should be able to _call_ an exe or dll within the Spring directory heirarchy. It just shouldn't be able to create one.

+1, but I don't think Widgets should be able to do this at all.

Gadgets should be able to do full I/O. Widgets should be able to do IO only to a specific filetype (.txt,.lua) that doesn't have executable privileges in any OS.

It's terribly unlikely that somebody's going to write an entire video game just to run something spurious as a joke. More serious intrusions, sure I guess it's worth worrying about... not. The amount of anonymity a game developer has is just about zero, it's not like we wouldn't be promptly caught and sent to prison if we pulled a fast one, and it's not like people wouldn't notice ("hey, everybody who downloaded P.U.R.E. came down with virii... hmm") so I don't really think it's even worth bothering worrying about.

TBH, I just don't understand what the thinking was about making it work the opposite way. Gadgets can't do any I/O in out-of-the-box Lua currently.

[lurker]

Luasocket. Ingame lobby, separated minimap window, widget territory.

[zwzsg]

I don't think Widgets should be able to do this at all.

Gadgets should be able to

Entirely agree.

[Pxtl]

I don't think the worry is a full installer-package that bundles an extra exe or dll, just the problem of the way mod and map files are auto-fetched by the lobbies. That stuff should be secured, since that's a place a guy could easily do a little work to make some SpeedMetal-esque map that he could use to backdoor players.

So yeah, no creating exe/dll files, but gadgets should be able to access them.

[zwzsg]

It appears that sploit was half fixed in Linux already. After eventually managing to port my .dll into a .so, when I tested it, the widget managed to copy the file, but not to loadlib it as instead it returned:
nil,
dynamic libraries not enabled; check your Lua installation,
absent

[YokoZar]

Would an AppArmor profile for Linux do the trick? http://en.wikipedia.org/wiki/AppArmor

I'm not sure if Windows has anything remotely equivalent, but the general idea is we prevent Spring from seeing anything outside its own datadir. That way, at worst, a malicious lua script forces you to redownload your maps and mods.

I suppose, in theory, the lobby client could protect against even this by storing maps in its data folder and then providing symlinks in the spring data folder.

[YokoZar]

It's terribly unlikely that somebody's going to write an entire video game just to run something spurious as a joke. More serious intrusions, sure I guess it's worth worrying about... not. The amount of anonymity a game developer has is just about zero, it's not like we wouldn't be promptly caught and sent to prison if we pulled a fast one, and it's not like people wouldn't notice ("hey, everybody who downloaded P.U.R.E. came down with virii... hmm") so I don't really think it's even worth bothering worrying about.

The worry is more that a map/mod can be auto-downloaded by the lobby client without the user doing much more than clicking on a game to play. The mod may even have a wrong name, as has already happened with fake Balanced Annihilation versions - all it takes is some idiot to stuff malicious lua in there instead of an actual mod.

[clericvash]

Could the new lobby server not have a mechanism for checking like validated mods and warn if the mod they are about to use has not been validated, which would be done by an admin or mod?

[daan 79]

"official release" tag could be put with it?

I not sure how many ppl will take to cetificate certain spring files. But if we could tag soem kind of "been tested" mark to it ppl be maybe more aware.

I smell some springzine news!