LÖVE

AndreyMust19 wrote:I think need close all opened files in that directory before?

Yeah, definitely make sure to do that.

Robin wrote:The thing is, os.execute is like the keys to the kingdom, and when you hand someone those, you can't really say "only come in Mondays and Tuesdays, and don't steal anything while you're in".

In this specific case, one thing I could do is:

Code: Select all

renameFile('oldfile', 'newfile"; format "C:\')

Gone is your hard drive. And I could do anything there: make your computer part of a botnet, upload everything in your POETRY\PERSONAL\DRAFTS\ABOUT_MEGAN\ folder to 4chan. Anything. And this is far from the only way to do something like this, it's just the first thing that I came up with. Stuff like this is called code injection.

renameFile is now an unsafe function. In the vast majority of cases it'll be used in a way that isn't dangerous (hard-coded constants, filenames that already exist in the filesystem, etc), but there will be people who will use your function and not realise they just sold out their players to everyone with bad intentions and an internet connection.

---

This is why I made SELÖVE in the first place. By disallowing access to functionality like os.execute, it prevents things like this from ever being a problem.

I may be showing my ignorance here, and I'm not refuting what you're saying, I just don't fully understand why it's such an issue.

I'm aware of code injection but the only way I can think of it happening in this situation would be if the game supported user generated content and the programmer allowed that content to alter the filename values.

Besides that, if os.execute itself is such an enormous vulnerability and you should never use it ever under any circumstances, then why can it even be called from vanilla LÖVE in the first place? I'm sure people download .love files all the time and run them without checking every line of code. Couldn't a malicious programmer even more easily throw a os.execute call into a .love file?

I'm not really defending its use in this situation as I knew it wasn't an ideal solution. I just don't see why os.execute itself is inherently evil, rather than something that should just be used with caution.

One option could be to iterate all files in the source directory, read each file and write it (in binary mode) out to the destination folder.
Then (optionally) delete the old source folder.
This is probably much slower though although I've used this approach and works pretty well.
Note that file access and modification data will be lost.

Jasoco wrote:Please, tell us more about Megan, Robin.

Megan and I first met at a party at her sister's.
We hit it off, opened up, shared secrets, and talked about everything. Around us, the party waned, but we hid from sleep together, talking through the deepest hours of the night.
The dawn found us curled up on a couch, asleep but still together.
That experience, connecting with a stranger and falling recklessly in love is one of life's greatest joys.
And now that you're married, you'll never experience it again.
It's the price you pay for everlasting love. It's a small one, but I hope it stings a little.
Anyway, I wish you and Megan the best.
...Hey, man, you asked me to do a toast.

Kadoba wrote:I'm aware of code injection but the only way I can think of it happening in this situation would be if the game supported user generated content and the programmer allowed that content to alter the filename values.

Someone allows modding for their game, and is smart enough to make a sandbox and disallow os.execute in those mods, but allows the renameFile (because why shouldn't a game mod be able to rename files?) --- then anyone can make a malicious mod that makes the sandbox absolutely useless.

Kadoba wrote:Besides that, if os.execute itself is such an enormous vulnerability and you should never use it ever under any circumstances, then why can it even be called from vanilla LÖVE in the first place? I'm sure people download .love files all the time and run them without checking every line of code. Couldn't a malicious programmer even more easily throw a os.execute call into a .love file?

That's exactly why I have SELÖVE. Vanilla LÖVE doesn't want to change anything about the Lua standard library, and I respect that. But that does mean you should only play .loves from trusted sources or your box may already be owned.

Robin wrote:

Jasoco wrote:Please, tell us more about Megan, Robin.

Megan and I first met at a party at her sister's.
We hit it off, opened up, shared secrets, and talked about everything. Around us, the party waned, but we hid from sleep together, talking through the deepest hours of the night.
The dawn found us curled up on a couch, asleep but still together.
That experience, connecting with a stranger and falling recklessly in love is one of life's greatest joys.
And now that you're married, you'll never experience it again.
It's the price you pay for everlasting love. It's a small one, but I hope it stings a little.
Anyway, I wish you and Megan the best.
...Hey, man, you asked me to do a toast.

You are the best.

Aww, you too!

Yes, is working. Left check that on Windows.
In any case i have

It would still be nice to have a love.filesystem.rename built on top of os.rename.
Or at least it would be better than not having a rename function at all.

John Carmack wrote:I need to keep reminding myself that practically every write of a file should be to a temp file followed by a rename.

https://twitter.com/ID_AA_Carmack/statu ... 5781043200

Robin, I'm confused.
Anyone who has access to your .love file can mess with the code.
If someone wants to break your system with lua code, they can, if they have access to a lua file which you will run (unless you run it in a sandbox).
What I'm saying is: If someone has so much access to the code that they can change the parameters of the os.execute call, then they can also always _add_ an os.execute call, which they can do anything with.

Germanunkol wrote:Robin, I'm confused.

I'm talking specifically about running code in a sandbox. The thing is, this renameFile function breaks that sandbox, even though there's no reason it should. If they don't have direct access to os.execute, but do have access to renameFile, they can use that to gain access to os.execute indirectly.

In fact, the attacker doesn't even need to be able to execute (sandboxed) code. It only needs to be able to supply a single string that'll be used in a call to renameFile.