Store Page
Hack 'n' Slash
All Discussions Screenshots Artwork Broadcasts Videos Workshop News Guides Reviews

Hack 'n' Slash

Store Page
Hack 'n' Slash >  Workshop > SmashManiac's Workshop
65 ratings
Security Exploit 1
Description Discussions0 Comments17 Change Notes
   
Award
Favorite
Favorited
Unfavorite
File Size
Posted
Updated
25.187 KB
15 Sep, 2014 @ 11:21pm
17 Sep, 2014 @ 11:16pm
2 Change Notes ( view )
Created by
SmashManiac
Online
10,707 Unique Visitors
156 Current Subscribers
16 Current Favorites

Subscribe to download
Security Exploit 1

In 1 collection by SmashManiac
Security Exploits
2 items
Description
Status: FIXED
Reported 2014-09-16, fixed 2014-09-19

Hack 'n' Slash creates a special environment for mods by exposing only a subset of the Lua standard libraries and a few special functions designed for creating mods. This mod demonstrates an exploit that was possible on a previous version of the game which bypassed this protection and allowed arbitrary code execution, regardless of the player's operating system. It does not contain viruses, trojan horses, worms, or any other similar software or programs, but could have theorically been used to bootstrap one by a malicious modder.

When enabled, this mod was designed toiprompt for a command to be sent to the operating system, which would then be executed. By default, it would launch Windows Calculator in a separate process. For convenience, the mod automatically terminates the game once the command returns.

The vulnerability used in this particular exploit is the loadstring() function, which was exposed to modders. Code loaded through this function is applied on the global environment and had access to all Lua stardard libraries. Arbitrary code could then be executed through the os library. This was patched on by exposing a custom version of the function which applies the mod envidonment on the compiled chunk before returning it.

This is probably the only exploit that I had/will publicly disclose before being fixed. I had originally decided to do so to warn users of the danger with evidence as soon as possible since this exploit was so easy to find and implement, and considering the low risk of someone actually using it to upload malware despite exposing his identity through Steam. I believe such exceptional measures are no longer warranted however, and from now on I will only publicly disclose my exploits once fixed.

Because of potential vulnerabilities such as this one, I recommend players to inspect the source code of the mods they download through Steam Workshop before enabling them and report those that violate the Steam Online Conduct Rules as soon as possible.

I hope that this mod will serve as an educational piece for all types of programmers about the importance of writing secure code.

If you find any security issues in the game, please contact support@doublefine.com

To see more Hack 'n' Slash vulnerabilities, please check my Security Exploits collection.
17 Comments
< >
Fingini 6 Oct, 2015 @ 9:32am 
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.
SmashManiac  [author] 3 Oct, 2014 @ 11:28pm 
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...
Sparkette 3 Oct, 2014 @ 6:03pm 
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"
Noughtceratops 20 Sep, 2014 @ 10:36am 
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
SmashManiac  [author] 19 Sep, 2014 @ 10:36pm 
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. :)
Noughtceratops 19 Sep, 2014 @ 7:42pm 
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.
Noughtceratops 19 Sep, 2014 @ 7:42pm 
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
Noughtceratops 19 Sep, 2014 @ 7:41pm 
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.
Noughtceratops 19 Sep, 2014 @ 7:40pm 
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.
Archomeda 18 Sep, 2014 @ 12:26am 
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.