What is so bad about the Debug library?

This may seem like a bit of an odd question, but what can actually be exploited by the debug library? It seems obvious that the debug library isn't available but I've looking at it I can't see a way to abuse it and escape the sandbox. To clarify I'm not asking for code to abuse the debug library (so I don't feel this can be classed as malicious code) but I'm just curious…

The methods in the Debug API are listed here and the source for LuaJ 2's debug library is here.

.debug: This is simply a REPL loop to allow the ability to get/set/evaluate expressions inside a function. The only issue I can see is that it reads from stdin instead, though I know that you can change that in LuaJ (at least you can in LuaJ 3 which I think Dan is upgrading to).

.getfenv/.setfenv: These are the same as getfenv/setfenv. I guess these would have to be sandboxed the same as getfenv is - though this would probably have to be moved to the Java side.

.gethook/.sethook: CC does add a debug hook to yield inside coroutines which the debug library could technically remove. However as far as I am aware this wouldn't stop 'too long without yielding errors', it just means the computer would crash be more likely to crash on 'too long without yielding' than yield the coroutine.

.getmetatable/.setmetatable: Allows bypassing 'metatable protection' (setmetatable(obj, {__meta = false})). This would need sandboxing the same as normal getfenv.

.getinfo: Gets information about a function such as its name and the line it is defined on. Very useful and I can't see an issue.

.getlocal/.setlocal: Allows getting and setting variables inside functions. This and setupvalue are the most 'unsafe' and wouldn't work with LuaJC.

.getregistry: Only returns a blank table in LuaJ.

.getupvalue: Same as .getlocal but for upvalues. Would work with LuaJC.

.traceback: Provides a stack traceback - though can be currently emulated with pcall.

So the 'exploitable' functions are the local/upvalue/hook functions - but seeing as the sandbox is Java side you can't escape the sandbox with this. There must be something I'm missing.

Extra reading:
OpenComputer's issue on debug.getinfo and source code

Maybe it really is only what you stated. We have been getting along very well without the debug library, havent we?

Creator, on 23 May 2015 - 06:21 PM said:

We have been getting along very well without the debug library, havent we?

Yes and no. Like the issue that we don't have require - 99% of people it doesn't matter but it is a nuisance for those who would like it.

Sometimes you have to go to massive work arounds when porting code because of the lack of some debug functions (mostly debug.getinfo). I've always wanted to write a proper debugger for Lua but we can't without the debug library - it would be nice to have I just don't get why.

Oh yeah, require. I miss it too. It is from the debug lib?

No, that is a whole different kettle of fish. It was an example of things that are useful but most people don't need.

Though I don't see why we can't have require either :P/>. But that is another issue…

Require wouldn't be terribly difficult to create, so it's not like "we can't have [it]".

Escaping the sandbox isn't the only way to wreak havoc on a server using the debug library. Bear in mind that all of the computers in the world are just coroutines running alongside each other. Debug functions could potentially affect all computers, unless the library was heavily modified. From what I can tell, there isn't anything that we really need it for, and the amount of work it would take to make it "safe" in that regard just isn't justifiable. Just a guess.

Require was just an example - you can implement the entire package library in 200 lines of Lua, but having it as a built in standard is always nice.

I always forget about other computers running and interfering with each other. I'm not sure that debug functions can access coroutines that it doesn't hold a concrete reference to but that makes sense. Thanks!

I vaguely remember something big and bad years ago with getlocal that actually did allow breaking the Java sandbox.