Who figured it would be a good idea to allow received chats to be interpreted as code?! That's a pretty big security fail if you ask me.
They didn't allow it on purpose. They have a "RunScript" command that allows you to execute code on your machine. However, the attacker tricks the user into overwriting a function that is called when a message is received to run the "RunScript" function instead.
> That's a pretty big security fail if you ask me.
That's the point of the article.
Lua was never intended to be used for games, UI, etc... It just proved useful to be used like that.
Because of Lua "real" intentions, it was made in a way that you can assign "everything" to "everything", and you don't need () to refer or call functions. (in fact, many of the stuff that make Lua look like a "normal" programming language, like dot syntax, () and whatnot, are "synctatic sugar")
This entire thread mentions fatality of function substitution in Lua, but that is easily prevented (by setting proxy metatable on global table and system libraries, even any lua-noob knows that, blizzard devs are just losers). But even that missing protection is not what breaks security. In dynamic languages like lua or javascript you control the dynamicity via localization of global values at eval-time ('eval' as in repl). 'local trim = path.to.sys.lib.trim'. So, once trim function is localized in console code, you can assign anything to original location and that will not interfere with console logic. Lua is just too hot to handle for wow-devs, and python, perl, javascript have the same issue more or less the same way.
I did read the article, which is why I said that this was big security issue that the chat could be interpreted as code. This should have been tested against.
If I can convince you to paste some random code from this HN comment into a command interpreter, that could do similar things to your system.
I'm not even sure this is a vulnerability at the scripting level. I think it's just a bad idea to include `/run` by default.
:D
My issue is that this exploit was possible AT ALL and that this wasn't tested. As a web developper, this is the kind of exploits I keep in the back of my mind every time I develop something.
Yes, this bug involve some social engineering but the bug itself is big. This is not a bug but a really bad oversight. If someone made it so that the field of a website's form called eval() directly we would all be pointing fingers right now. This bug is the exact same thing.
Yes, the user has to be tricked into writing a piece of code into the console. The problem here is that this piece of code shouldn't have been able to be executed at all. Who in their right mind would allow incoming messages to be parsed? They should have caught that bug in development!
As a web developer, you should also know that there is absolutely nothing you can do to prevent attacks performed through the developer console. This is the moral equivalent.