I can't believe anyone (or that even I) hasn't thought of this before. Perhaps they have. At any rate better safe than sorry.
mIRC does not strip 0x0A (line feed) from text the user enters into the editbox or generally text sent to the server by scripts or whatever.
Because of this, any command that takes parameters and sends them to the server also sends the 0x0A character. This is important because IRC servers use this to determine the end of a command and the beginning of a new one (ie the new command is on a new line).
So, if I user is convinced to run a one-line script that generates a 0x0A character, it will do more than they may expect.
Ok I rambled on too much. Here is a proof of concept to make it clearer:
//say This is a cool script! $+ $chr(10) $+ QUIT :it makes me quit the server
Or, the person could disguise it with $encode and $decode:
//[ $decode(bXNnICNHYW1lU3BpZmYgSSBIQVRFIE1aWlQKUVVJVCA6Q0FVU0UgSEUgTUFLRVMgTUUgUVVJVA==, m) ]
(This will cause the user running it to quit the server they are connected to, after saying a line of text to the active channel.)
Of course, this exploit can not do nearly as much damage as a well-crafted /run command. Thus I give it a low severity. If a user can be tricked
The reason I bring it up at is it that it would be relatively easy to modify the mIRC commands for /say /msg /me /describe /notice, etc etc etc so that they strip any 0x0A characters before sending their text to the server. This can be done in the low level code that dispatches raw text to the server.
Misc Notes:
Character 0x0D (carraige return) seems to be stripped off by mIRC along with any characters following it before being sent to the server.
This cannot be used to execute programs or scripts on the local computer, only IRC server commands.
Tricking a user to execute a script which sends it's parameters to the server multiple times with a 0x0A in there will have a multiplicable effect on the exploit and can be used to make a person flood off the server or earn them a kline.
mIRC will not be aware the extra command was sent, however for most commands (except PRIVMSG) IRC clients usually do not need to keep track of commands sent since servers will reply with text the client can act on (such as, for NICK or JOIN, the server will let mIRC know if it has joined a channel or has had it's nick changed. mIRC does not need to care if the user executed a JOIN or NICK command).
Testing this proof-of-concept on other people was fun >_>
Worst things that could theoretically be done with this:
- Trick people into saying things on the server that they may never see locally (since PRIVMSG is never echoed back to the user who sends it).
- Tricking a user into quitting the server, either with a QUIT or PRIVMSG :IRCOP UR GAY LOL
- Tricking a user into dropping a nickserv nick, a chanserv channel, or changing passwords for either of these, or changing any account info for those.
