Hi, Just saw this and I just wanted to say thanks to SmashManiac for informing people of the risks involved with downloading mods. The thing people forget is that mods are created by the community and not always by a legitimate programmer or modder there for some people will inevitably use it to dick you over.

Interesting you say that flarn2006. I actually had a conversation with Brandon a few days ago about a similar idea, except that it would retain the user's security. I'm curious to see if it will get into the game or not...

You know, you might want to make an option to remove the "sandbox" completely for a specific mod, in case a mod developer wants to do something that would otherwise be prohibited for security reasons. Obviously, in this case, the game should give a warning before installing such a mod. Something like "WARNING: The mod <mod name here> is requesting access to your system. This opens up the possibility to be affected by malicious code. Make sure you trust its developer or have previously inspected its source code before activating it! What would you like to do? Activate mod / Leave mod disabled for now / Open mod folder / Unsubscribe"

Thanks! Totally agree with your point about people knowing that security risks are a real considration with mods- I wish that was something Steam was more up-front about as well, and it's one of the reasons I wanted to make it easy to unpack a mod locally.

I look forward to seeing your other 'sploits :D

Hey Brandon, thanks for your concern! I debated for a while with myself between releasing this vulnerability publicly or only to Double Fine, and in the end I decided to do an exception and release it publicly because it was so easy to find and implement and to let players know that they were in danger with evidence. I know this choice is debatable, but I assume it.

I believe the point has been made though, and you can be sure that I'll keep my other exploits hidden from the public until either a fix is deployed or I'm able to release a patch mod in parallel (making such a mod was actually the reason I was holding off publishing my other exploits, but I guess that's no longer necessary). I'll also make sure to send an email to make sure your team is notified - I didn't think it was an issue.

Not much else to say except... thank you. :)

Also, if you want to make the mods public after we addressed them just for the notoriety of having found the issue, that's totally fine by me! :)

And thanks again for looking into these security issues! Sandboxing is a difficult, open-ended problem, especially because we want to keep the modding capabilities as flexible as possible. Once we've got the new build up, it'll be secured a bit better, but I'm sure there will still be holes left unplugged. We'd love it if you hammered on it and let us know if you find any issues.

Posting to the community isn't the greatest way to get in contact with us about something like this; we can get notifications through Steam for community activity, which we pay attention to, but it's quite a flood, and stuff slips by. The best way to get in touch with us is via support@doublefine.com. That email address is not a black hole - it gets checked regularly by a human at Double Fine and they're good at redirecting the emails to the appropriate person in the studio to take care of the issue.

If you want to get in touch with me personally, the two best ways are:
email: brandondillon@doublefine.com
twitter: @Noughtceratops

As for having stuff like this in the workshop, I'm totally cool with you packaging proof-of-concepts like this as a mod and uploading them; it's actually a really convenient way for us to download and evaluate an exploit like this. What we'd really appreciate, though, is if you'd leave them private and notify us directly first. That way, we have time to address the vulnerability before someone else has the opportunity to do something malicious with it.

As the developers of the game, we have the ability to see and download private Hack 'n' Slash mods as part of our moderation toolkit, so uploading it and sending us a link to the private mod is totally sufficient for us to evaluate and address any vulnerabilities.

We've just uploaded a build with a quick fix for this specific vulnerability. It also expands the function environment to include common global functions we inadvertently excluded when we set up the sandboxing - if you want to see how the environment is built, take a look at:
[code]Data/Scripts/ModManager.lua[/code]

We've also got a build with more extensive coverage for a similar class of vulnerabilities in QA - it needs some testing to make sure the changes don't interfere with the regular game, but we'll hopefully be able to push it live early next week.

Hmm... fair enough. But do be careful about releasing code that does not only provide a proof of concept, but also provides a way for other people to cause harm. Now this is not as big as I went through several years ago, but I definitely did go on that road myself before: instead of going to the people that were responsible of a certain system when I found a vulnerability, I went ahead and created a script that abused that vulnerability to its full extend. Let's say those people were not happy that I made and used it, while I thought it provided a good proof of concept. They said I went too far, and looking back, I agree. Note that I didn't even release the script to the public.

I'm not saying this is exactly the same, because it isn't yet. I haven't looked at your code, but I take your word for it that it only shows the basic of the exploit and is actually not abusing it fully (like wiping or infecting the system while you're at it :p). It's a thin line to walk on.

The reason I created a mod instead of a discussion thread is because I found more exploits than this one and I wanted to release them individually with a proof of concept. As for using such an exploit as a workaround for the deficient modding support, I also had the same thought, but considering somebody tried to block access in the first place I don't think that's a good idea. If you want to discuss the matter in more details, feel free to create a discussion thread about this yourself.

Thanks for the wiki link by the way, very interesting!

Also, I have to ask you a question about this: why did you decide to put this on the workshop instead of making a discussion thread? Plus, the stuff I just said, makes this issue more complete for the developers of Hack 'n' Slash. You give one perspective of this issue, and I give the opposite and also address an issue with the sandbox in general.
So it's up to the developers to decide what they want to do with this. But I guess this is what you get when you make a game where you need to hack stuff while it's also moddable (and basically have to hack the game in your mod...), it's hard to get it right.

It's up to you what you want to do with the stuff I said, but if you decide to make a thread, I'm only asking you to include this as well.

Although not all of them are useful, but some things are useful and let you do stuff that you normally can't at the moment. And forgive me, but it's a bit sad that I have to hack my way around it in order to get access to tonumber, tostring or require (although... the game is about hacking... so yeah...).

I don't know whether this is a feature or an oversight on the developers' part, but this "oversight" allows me to do more stuff than that I'm actually allowed to, and I'm not trying to make malicious code, just making things easier for myself. If this gets fixed later on, I do hope that the developers will think about the effects this fix will have and maybe think about providing safe alternatives?

(again... 1000 char limit, I honestly did not know there is a limit :P)

Well... you know, I was experimenting with mods. I actually use loadstring to get the global environment to just call tostring and other arbitrary built-in lua functions (since that is not available in the sandbox...). Plus I admit I also use require, which is considered unsafe, but I don't know how to include custom libraries or other stuff otherwise (I haven't used lua that much, so I can't say I'm an expert).

The built-in stuff that you can use in the sandbox are: pairs, ipairs, next, table, string, math, type, loadstring and pcall. http://lua-users.org/wiki/SandBoxes has a nice list of lua 5.1 functions that are considered safe or unsafe in a sandbox environment.
Stuff that are missing and are considered safe: assert, error, print, select, tonumber, tostring, unpack, _VERSION, xpcall, certain coroutine stuff, certain io stuff, os.clock, os.time.

(urgh... 1000 char limit, continued in next post...)

A rock can be just a good a tool as a hammer.

That's a very good question sher1ock. Indeed, that's one way you can use my mod, but considering that person would be committing a crime while logged in on Steam, he'd be pretty stupid to do so. The low risk associated with this scenario is why I decided to publicly disclose this security flaw. In my opinion, the positives greatly outweights the negatives.

I'll update the description to add this rationale. Thank you for bringing this up!

By the way, I'm not sure if the word "tool" applies here considering my source code is only 2 lines long. Food for thought...

So you just made a tool that allows someone to pack malicious code into a mod?