4 ms·

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.

keketi 10y ago
Read the article. Received chats are executed only after the victim has run the script provided by the attacker. The real question is "why does the scripting system allow overriding functions like that?".
- dmoy 10y ago
  Don't most scripting languages allow overriding functions like that? My only experience hacking on Lua has been in game UIs.
- speeder 10y ago
  Lua was created to be a configuration file system that was turing complete, to be used by a oil mining company. 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")
  - wruza 10y ago
    Please do not spread false misbeliefs. Wow's Lua is 5.1-flavoured afaik, and that's completely different language from 5.0, 4.x or what you describe. 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.
- Raphmedia 10y ago
  > Read the article. Received chats are executed only after the victim has run the script provided by the attacker. 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.
  - slrz 10y ago
    It is evaluated as code only after the (legitimate) player modified the environment to do exactly that. 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.
Twisol 10y ago
The attacker figured. WoW doesn't do this normally - the attack involves the victim explicitly replacing an innocuous "RemoveExtraSpaces" function - which ostensibly is used as a scripting hook to trim spaces from incoming chat messages - with an eval-equivalent "RunScript". They basically just tied the ends of the right wires together. 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.
- onetwotree 10y ago
  The `/run` command is pretty essential for debugging mods. I think that it'd be a wise idea to disable it by default, and allow an advanced user to change a setting in a file to turn it back on.
  - nkrisc 10y ago
    To add to this, any barriers Blizzard introduces will just become an extra step in the social engineering portion of the attack, getting the victim to enable the feature.
    - scrollaway 10y ago
      Facebook has had the same problem with the browser devtools. Fun seeing a repeat of it in a different sector.
      - elliottcarlson 10y ago
        It is reminiscent of "Press Alt-F4 for ops", used to troll Mirc users on IRC back in the 90's; or having people enter "+++ATH0,ATDT,911" from the BBS days.
        roghummal 10y ago
        To tie the two together (IRC/++ATH0)... /ctcp #channel PING ++ATH0 :D http://everything2.com/title/%252B%252B%252BATH0 http://everything2.com/title/%252B%252B%252BATH0
choward 10y ago
> Who figured it would be a good idea to allow received chats to be interpreted as code?! 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.

keketi 10y ago

Read the article. Received chats are executed only after the victim has run the script provided by the attacker. The real question is "why does the scripting system allow overriding functions like that?".

dmoy 10y ago
Don't most scripting languages allow overriding functions like that? My only experience hacking on Lua has been in game UIs.
speeder 10y ago
Lua was created to be a configuration file system that was turing complete, to be used by a oil mining company. 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")
- wruza 10y ago
  Please do not spread false misbeliefs. Wow's Lua is 5.1-flavoured afaik, and that's completely different language from 5.0, 4.x or what you describe. 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.
Raphmedia 10y ago
> Read the article. Received chats are executed only after the victim has run the script provided by the attacker. 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.
- slrz 10y ago
  It is evaluated as code only after the (legitimate) player modified the environment to do exactly that. 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.

Twisol 10y ago

The attacker figured. WoW doesn't do this normally - the attack involves the victim explicitly replacing an innocuous "RemoveExtraSpaces" function - which ostensibly is used as a scripting hook to trim spaces from incoming chat messages - with an eval-equivalent "RunScript". They basically just tied the ends of the right wires together. 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.

onetwotree 10y ago
The `/run` command is pretty essential for debugging mods. I think that it'd be a wise idea to disable it by default, and allow an advanced user to change a setting in a file to turn it back on.
- nkrisc 10y ago
  To add to this, any barriers Blizzard introduces will just become an extra step in the social engineering portion of the attack, getting the victim to enable the feature.
  - scrollaway 10y ago
    Facebook has had the same problem with the browser devtools. Fun seeing a repeat of it in a different sector.
    - elliottcarlson 10y ago
      It is reminiscent of "Press Alt-F4 for ops", used to troll Mirc users on IRC back in the 90's; or having people enter "+++ATH0,ATDT,911" from the BBS days.
      - roghummal 10y ago
        To tie the two together (IRC/++ATH0)... /ctcp #channel PING ++ATH0 :D http://everything2.com/title/%252B%252B%252BATH0 http://everything2.com/title/%252B%252B%252BATH0

choward 10y ago

> Who figured it would be a good idea to allow received chats to be interpreted as code?! 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.