The code is exploitable, and not just by an evil oper but by users as well. All one needs to do is get you to join #$q (which is a valid channel name) to be able to make you quit IRC (/q is a /quit default alias, or at least something a lot of users have installed).
Not true. $q doesn't execute quit anymore. A regular user could exploit this to reveal information about variables, for example: #$+(%password) and if your nickserv password is in the variable %password, then it becomes visible. A regular user could exploit this issue if $decode or some other decoding mechanism (that doesn't return any comma or whitespace) is present: #$($decode(...))
Furthermore, a regular user could exploit this to find out $version, if CTCP is blocked, as displayed many times before. For earlier versions of mIRC, it may be possible to trigger an $asctime buffer overflow exploit on some networks if their CHANLEN is large enough (though I don't know enough about this to be sure). Under very rare occasions it may be possible to use $read to trigger a recursive situation where an exploit may eventually be triggered. Due to lack of interest, I haven't explored this situation.
It may not be possible to cram $findfile in there (main issue being that commas are treated as channel delimiters) but apart from the fact that a less serious exploit is still an exploit, you don't want to make assumptions about the attacker's creativity.
It's possible to cram a $findfile in there, but the IRCd wouldn't be standard. Nonetheless, it's possible and the network admin are the people who decide what IRCd they run. An IRC network administrator could exploit it to the point where they don't need $decode (because they can be creative and manipulate an IRCd so they can use commas in channel names) and there is no limit on channel name length. This is possible:
; a space, escaped for ease of writing the following string
var %s = $!chr(32)
; remove the spacing from "write C:\file.mrc on 1:TEXT:eval *:*: $2-"
var %command = $!+(write,%s,C:\file.mrc,%s,on,%s,1:TEXT:eval,%s,%*:*:,%s,$2-)
The client would then be forced to join #$findfile($mircdir,*.*,1,1,
%command) where
%command has been expanded to the evaluation provided above. The system would then be successfully compromised, with less than 100 lines of mIRC code to simulate a server that forces every user to join the channel. Social engineering could be used to convince people to join the exploit server:
Your server was spammed by irc.pwnt.you.org
edit: perhaps Khaled could add to his todo list: block script execution for #$findfile -- no sane scripter would use #$findfile(...) and this would provide just that little bit more security.
edit #2: It may also be possible for a user to exploit this issue if they're very desperate and they know how to cause DNS cache pollution. They'd have to have a specific target, and know their IP address at the very least.
edit #3: In order to "refrain from any comments if you think people did stupid or non logical things", as suggested by one of the forum moderators, I won't be pointing out any vulnerable or "stupid" code in the future. I hope that makes whoever was upset by my constructive criticism happy.
