IF you've got a very poorly written "ctcp ping reply" script loaded, sure this might work.
However, plain vanilla eggdrops does not have any bindings to ctcr, and the only "raw" processing of ctcp-replys are in the irc- and server-module, which only identifies a notice to be a ctcp-reply and just logs the whole message.
How to identify a poor script? Here's an example:
Code: Select all
die "Do NOT run this script!!!"
proc do_ping {hand idx text} {
puthelp "PRIVMSG $text :\001PING [unixtime]\001"
}
proc got_ping_reply {nick host hand target what time} {
putlog "Ping reply from $nick: [expr [unixtime] - $time] seconds."
}
bind dcc - buggedping do_ping
bind ctcr - PING got_ping_reply
So what's so terribly wrong with this?
Well, this script trusts that the ping reply is "proper", that is, it returns the same timestamp that I first sent to the other client. However, a client may put whatever they wish as "timestamp", including an arbitrary string that may include nasty stuffs. But being unthoughtful, this script trusts it to be a simple integer that I can subtract from current time (now - timestamp), so I pass it unchecked to "expr". "expr" however will evaluate anything inbetween [] as tcl-code to be interpreted, and voila, the exploit you posted would work as a charm.
Lesson learned?
NEVER EVER use expr with unchecked input from any untrusted source.
edit:
If you are worried wether your system is vulnerable to this, use this little script to check:
Code: Select all
proc check_ping_vulnerability {handle idx text} {
puthelp "NOTICE $::botnick :\001PING \[putlog \"Your bot suffers from a ctcp-pingreply remote exploit. Please check your loaded scripts.\"\]\001"
}
bind dcc n testping check_ping_vulnerability
Note, the following logentry would be recieved on safe bots aswell:
[14:58] CTCP reply PING: [putlog "Your bot suffers from a ctcp-pingreply remote exploit. Please check your loaded scripts."] from botnick (ident@host) to botnick
However, you are in trouble if you find this in your logs as a single logentry:
Your bot suffers from a ctcp-pingreply remote exploit. Please check your loaded scripts.
maybe to be sure? or just a "good" luck thingie 
