Security, Lua, and You

[lurker]

Did you know that lua can write a dll and then immediately load it, executing anything inside? We could use some kind of blocking for writing out executable files. Windows demo attached.

[Neddie]

Uh. Yeeeah.

[danuker]

I'm on Linux. Linux rules.
[Though it might also be vulnerable.]

[lurker]

Will spring refuse to load a .so without the executable bit?

[aegis]

it'll refuse to load a .so not compiled right

[Argh]

Oh, so you can do it for Ubuntu users, but maybe not another kernel?

Still... yuck, lol. I figured that was possible, and I'm glad somebody's tested it before it became an issue, since Widgets could be very easily built to... eh... deliver stuff.

[aegis]

applications aren't run as administrator by default on linux, and memory is protected better

[lurker]

What do memory protections have to do with it? This call is doing what it's designed to do, loading a library and running a function in it. And who cares if it's not admin when it can still delete all your files. I don't run spring as admin here either.

[el_matarife]

Oh great considering Spring practically requires administrator level privileges on Windows. Is this the incentive we need to move all the Spring mods and maps to All Users and the configuration settings to the current user's application data?

[AF]

If spring downloader didn't ask for admin rights it didn't need then tasclient wouldn't run as an admin and spring wouldn't inherit its privilledges as a result. Spring itself doesn't need admin privilledges to run.

[yuritch]

Now that tasclient is (seemingly) abandoned, admin rights on Windows should no longer be a problem.

[==Troy==]

*Cut*

[lurker]

Edit 2 : Actually, the stealthiest way to use this exploit is to put the hex representation of the dll into the LUA code, and then tell LUA to create such file once it is loaded, in the spring folder, with further execution of it.

Way to not look at the demo.

[zwzsg]

Shouldn't that have been posted and discussed in a more private area, until fix is made and released? Because now that everybody knows, I'll be afraid to use any new map or mod, as I know that the Spring community has enough fucktard that sooner or later one will release a map that format my hard drive "just for lulz" (and the worst thing is that then, dev will blame myself for not being careful).

I'm on Linux. Linux rules.

Irrelevant, since a sizeable part of Spring user base use windows, often with admin right.

I'd say that lua should only be able to read inside Spring folders (the main spring folder, and also those other folders where setting and such are stored). Reading anything else is dangerous, as I don't want any Spring map to suck up my passwords and game keys then upload them for instance.

As for writing, ideally it should only be able to write new files, with a system to keep track of which lua / which mod wrote which file, so that they can rewrite their own files. If that can't be done, I guess either a black list of dangerous file extension (exe,dll) or a white list of safer file extension (.txt, .ini, .png) would be better than nothing, but not a perfect solution : the whitelist will always lack some useful extension only one lua widget writer found the need of (like that .ppm for height map exporter), and safe files can be unsafe (like buffer overflow in windows's thumbnail exploitable by a mere image or sound file).

[lurker]

I really wouldn't worry about exploiting normal files.

[Argh]

1. Please, don't entirely curtail IO, it'd make World Builder moot, which would be a major bummer.

2. If you're going to make changes to IO, please enable it for Gadgets. It's pretty silly that we cannot read or write files with Gadgets at all.

[Pxtl]

It sounds like each little widget, mod-package, or map needs a little seperate sandbox where it can write files, and that's the only place it can write. It can read any file within the Spring file tree, but it's stuck to writing in that little sandbox.

And a separate folder is needed for "this folder is the one place you can store DLLs/EXEs that Lua script can execute". Obviously, Lua cannot write to that folder. That way an intrepid modder can create dll/exe-extended mods, but those mods will require the dll/exe to be deployed separately from the mod package, thus requiring active user involvement in the process of deploying such potentially unsafe content.

[lurker]

Okay, because windows likes to run all kinds of things when you click on them, let's make a list of executable / system-changing file extensions. Speak up if you have anything not on the list that would run on a standard windows install.
Binary: exe, com, scr, pif, bat (you can rename to spring.bat and it works!?)
Script: cmd, jar, jnlp, js, jse, reg, rgs, sct, vbe, vbs, wsf
Unknown: msc? cpl?

Even a whitelist might work better than that mess.

There is the option is to block only binary-executable files and trust people to not click the BIG RED BUTTON of other files.

And tobi had the idea to mark the files as unsafe / from an untrusted zone so you get a warning before doing something like executing.

[==Troy==]

WinVista has an annoying feature of detection bat/exe files if needed. Not sure what are the exact criteria for it to find them.

[ZellSF]

Okay, because windows likes to run all kinds of things when you click on them, let's make a list of executable / system-changing file extensions. Speak up if you have anything not on the list that would run on a standard windows install.
Binary: exe, com, scr, pif, bat (you can rename to spring.bat and it works!?)
Script: cmd, jar, jnlp, js, jse, reg, rgs, sct, vbe, vbs, wsf
Unknown: msc? cpl?

Don't think jar would run on a standard Windows install.