Exactly. As tentus said, a malicious hacker could get around sandboxing techniques.nevon wrote:Isn't the best solution to have the user not be an idiot and only run applications they trust? I really see it as a hindrance to throw in a bunch of artificial limitations that may prevent some "attacks" (though the attacker can just use another method), while definitely preventing lovers from doing legitimate, cool stuff.Taehl wrote:... That makes no sense. How is it any safer to politely ask an attacker to disable it?miko wrote:So if you need to block it, just do it in your game, but please do not do it for the whole platform.
Love security flaw
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
- BlackBulletIV
- Inner party member
- Posts: 1261
- Joined: Wed Dec 29, 2010 8:19 pm
- Location: Queensland, Australia
- Contact:
Re: Love security flaw
- slime
- Solid Snayke
- Posts: 3160
- Joined: Mon Aug 23, 2010 6:45 am
- Location: Nova Scotia, Canada
- Contact:
Re: Love security flaw
+1nevon wrote:Isn't the best solution to have the user not be an idiot and only run applications they trust? I really see it as a hindrance to throw in a bunch of artificial limitations that may prevent some "attacks" (though the attacker can just use another method), while definitely preventing lovers from doing legitimate, cool stuff.Taehl wrote:... That makes no sense. How is it any safer to politely ask an attacker to disable it?miko wrote:So if you need to block it, just do it in your game, but please do not do it for the whole platform.
It's not like löve is the only program in the world to have this ability. Restricting a feature simply because it has a remote chance of being abused is not the right way to go about things. If someone had malicious intent, löve probably would not be very high on their list of tools to use, anyway.
- Robin
- The Omniscient
- Posts: 6506
- Joined: Fri Feb 20, 2009 4:29 pm
- Location: The Netherlands
- Contact:
Re: Love security flaw
This changes for browser plug-ins. It has been shown that such a plug-in is very possible, and then it becomes a very real security risk. I for one would love LÖVE in the browser, thus my efforts *ahem* for SELÖVE.slime wrote:It's not like löve is the only program in the world to have this ability. Restricting a feature simply because it has a remote chance of being abused is not the right way to go about things. If someone had malicious intent, löve probably would not be very high on their list of tools to use, anyway.
And while perfect safety doesn't exist, that doesn't mean that we should make things very easy for attackers. In fact, malware has knowingly been distributed on this very forum in the past. Almost no-one knows about this.
Help us help you: attach a .love.
- slime
- Solid Snayke
- Posts: 3160
- Joined: Mon Aug 23, 2010 6:45 am
- Location: Nova Scotia, Canada
- Contact:
Re: Love security flaw
I don't think anyone is debating whether it's a good idea to make things hard for malicious attackers. What isn't a good idea is restricting legitimate features for all of us based on that fear. If someone feels the need to use SELÖVE, that's fine, but don't make the rest of us suffer.
- nevon
- Commander of the Circuloids
- Posts: 938
- Joined: Thu Feb 14, 2008 8:25 pm
- Location: Stockholm, Sweden
- Contact:
Re: Love security flaw
And that "malware" was made completely without the use of io.popen, iirc.Robin wrote:In fact, malware has knowingly been distributed on this very forum in the past. Almost no-one knows about this.
Also, I noticed.
- Taehl
- Dreaming in associative arrays
- Posts: 1025
- Joined: Mon Jan 11, 2010 5:07 am
- Location: CA, USA
- Contact:
Re: Love security flaw
What about a compromise, then: If a Love game tries to use io.popen or other potentially-malicious functions (which aren't often used in games), Love pops up a message warning the user about what the function does, and asking if it should be executed or not.
Until someone makes a .love file malware scanner, I don't want to have to manually look at the potentially obfuscated code of every game I try, just to make sure that someone isn't making use of such blatantly easy attack vectors.
Until someone makes a .love file malware scanner, I don't want to have to manually look at the potentially obfuscated code of every game I try, just to make sure that someone isn't making use of such blatantly easy attack vectors.
Earliest Love2D supporter who can't Love anymore. Let me disable pixel shaders if I don't use them, dammit!
Lenovo Thinkpad X60 Tablet, built like a tank. But not fancy enough for Love2D 0.10.0+.
Lenovo Thinkpad X60 Tablet, built like a tank. But not fancy enough for Love2D 0.10.0+.
Re: Love security flaw
If we use the above technique, could we also allow saving and loading OUTSIDE of the appdata directory as I have suggested before?
Request Programs
If Linux were a beer, it would be shipped in open barrels so that anybody could piss in it before delivery
If Linux were a beer, it would be shipped in open barrels so that anybody could piss in it before delivery
- kikito
- Inner party member
- Posts: 3153
- Joined: Sat Oct 03, 2009 5:22 pm
- Location: Madrid, Spain
- Contact:
Re: Love security flaw
How about this: make a sandboxed config option.Taehl wrote:What about a compromise, then: If a Love game tries to use io.popen or other potentially-malicious functions (which aren't often used in games), Love pops up a message warning the user about what the function does, and asking if it should be executed or not.
Until someone makes a .love file malware scanner, I don't want to have to manually look at the potentially obfuscated code of every game I try, just to make sure that someone isn't making use of such blatantly easy attack vectors.
- Sandboxed = true (default) => io functions are not available, and love.filesystem only works on the usual places. Just like it works now.
- Sandboxed = false => io functions are available, but LÖVE displays a dialog ("This love program is requesting access to your filesystem. Do you authorize it? (yes/no)") at the beginning. If the user presses no, the program ends.
When I write def I mean function.
- tentus
- Inner party member
- Posts: 1060
- Joined: Sun Oct 31, 2010 7:56 pm
- Location: Appalachia
- Contact:
Re: Love security flaw
I like this, but could I make three suggestions?kikito wrote:How about this: make a sandboxed config option.Taehl wrote:What about a compromise, then: If a Love game tries to use io.popen or other potentially-malicious functions (which aren't often used in games), Love pops up a message warning the user about what the function does, and asking if it should be executed or not.
Until someone makes a .love file malware scanner, I don't want to have to manually look at the potentially obfuscated code of every game I try, just to make sure that someone isn't making use of such blatantly easy attack vectors.
- Sandboxed = true (default) => io functions are not available, and love.filesystem only works on the usual places. Just like it works now.
- Sandboxed = false => io functions are available, but LÖVE displays a dialog ("This love program is requesting access to your filesystem. Do you authorize it? (yes/no)") at the beginning. If the user presses no, the program ends.
* First, make it so this only needs to be asked once per game. Getting a popup every time you want to run something would be a serious turn off.
* Second, let the game author justify themselves in the dialog. A 100-character string that could be set by the programmer to say why they want these abilities, shown right after the default Love "This program is requesting access to ...".
* Three, don't auto-close the program. Let it try to run anyhow: maybe users don't care if they can save screenshots or pull up the help website. A smart programmer could probably keep everything dependent on these functions relatively optional.
Kurosuke needs beta testers
- Robin
- The Omniscient
- Posts: 6506
- Joined: Fri Feb 20, 2009 4:29 pm
- Location: The Netherlands
- Contact:
Re: Love security flaw
Yeah, that just shows how leaky LÖVE is.nevon wrote:And that "malware" was made completely without the use of io.popen, iirc.
I know you did.nevon wrote:Also, I noticed.
I don't see that happening, at least not with the current dev team (or any dev team). Also: this would probably be really annoying to use, both for the gamer and the lover, and we'll need proper sandboxing if we want it to work. (So the debug library is right out, among others.)Taehl wrote:What about a compromise, then: If a Love game tries to use io.popen or other potentially-malicious functions (which aren't often used in games), Love pops up a message warning the user about what the function does, and asking if it should be executed or not.
I think the only way to find that out (thanks to Turing-completeness), is to run it in a sandboxed environment.Taehl wrote:Until someone makes a .love file malware scanner,
Good point.Taehl wrote:I don't want to have to manually look at the potentially obfuscated code of every game I try, just to make sure that someone isn't making use of such blatantly easy attack vectors.
Also, there is another argument for sandboxing which has been neglected: portability. All this fuzzing with the system outside of LÖVE makes it harder to port. Wouldn't it be great if a .love ran on one platform, it would run on every platform without a doubt? (With the exception of obviously handicapped targets, see nlove).
Help us help you: attach a .love.
Who is online
Users browsing this forum: Bing [Bot] and 5 guests