Firefox-based attack wreaks havoc on IRC users Underscoring a little-known web vulnerability, hackers are exploiting a weakness in the Mozilla Firefox browser to wreak havoc on Freenode and other networks that cater to users of internet relay chat. Using a piece of javascript embedded into a web link, the hackers force users of the open-source browser to join IRC networks …
It is simply maddening that there are these kinds of people that will waste their time griefing total strangers on the internet. The Freenode network is a work oriented communication platform, populated by many developers of vastly popular open source projects. To waste these people's valuable time is frankly disgusting. I for one, await these knuckleheads' punishment, they deserve anything they get.
""It's the first time I've actually seen it used in the wild," he said. "We've been theorizing this attack was possible for some time. Browsers absolutely should not be able to connect to ports unrelated to HTTP.""
So let me get this straight, Mr. Hansen ... In your opinion, browsers should only connect to http: related stuff, right? You've already madde a comment about IRC, but what about ftp:, telnet:, gopher:, wais:, finger:, news:, mailto:, pop:, file:, cap: (and many more esoteric bits & bobs)? Shouldn't they all work in your common or garden browser? How about ... well, about:? smb:? ssh:? rsync:? view-source:? data:? dns:? Need I go on?
From my perspective, this so-called "security expert" needs to go back to school ...
I don't think in my years of experience seen a browser open a mailto: link (unless it was Netscape Navigator), let alone the others you mentioned (file: excluded as it is a genuine feature). Not even IE or Safari have the capacity to deal with most of those, Opera might, Konqueror may handle smb: links but as for others, I've never had the need). I have however seen them open other applications, and pass the data included in the address to the application, but the browser itself, unless given the ability to do something with those links through an extension, has no need to communicate with any other port than 80 or 443. Of course, small exceptions can be made for servers running web services on alternative ports such as vSphere, but those should be explicitly entered on to a whitelist (and if neccessary pushed out via a group policy type system to multiple workstations) rather than all out allowed.
Firefox is strange. Some ports it disallows communication on, but others, even though they most certainly aren't standard http ports, it allows.
As a user I want to be able to browse on non-standard ports. Using 631 for CUPS is one example, then there's the VMWare admin port and various others. All not strictly http ports but still capable of serving http traffic with the correct server listening. How does the browser distinguish between valid ports and non-valid ports?
See? _NO_ browser is "safe". Only some are better than others.
"The malicious javascript exploits a feature that allows Firefox to send data over a variety of ports that aren't related to web browsing."
Is this so much a vulnerability? It is only convention that servers tend to use port 8080 as an alternative. There's little to say this has to be followed.
Perhaps a better option would be for the browser's scripting settings to have an option to:
Permit
Query
Deny
any scripted request to http://blah.blah:<some number other than 80>
?
NoScript?
Security researcher is right Jake and Teoh - a web-browser should be used for web-browsing, and FTP client for FTP'ing, etc etc.
The blend of multiple protocols into one unit is the problem. It make it too ripe a target for exploitation.
Obviously their are perks in ease-of-use... - i can click on a link and bam, here i am in an IRC chatroom (on Opera). I didn't have to set anything up or understand how i got here, but here i am getting support in real-time from the site i was just browsing.
But Security is always at odds with ease-of-use, and that's exactly what's going on here.
A script sends all the commands required to log in to an IRC chatroom and then spew URLs of the script again. This wouldn't be possible if a web-browser was a distinct entity to the IRC client.
And patching this isn't so easy Gerhard. The script makes the victim to auth just like a real client - replying to all the pings, etc.
Try joining Freenode using Telnet and you'll see how simple the process is.
This is what IRC clients expect - deviate from it and they won't work either.
"The blend of multiple protocols into one unit is the problem. It make it too ripe a target for exploitation."
But they ARE one unit ... or rather they all run over that one unit. It's called TCP/IP. That is the beauty of how the connectivity of "TheInternet[tm]" (whatever that is!) works ... TCP/IP is cross-platform, and cross-protocol.
"Try joining Freenode using Telnet and you'll see how simple the process is."
Uh ... John, telnet is a different protocol to IRC.
telnet, ostensibly port 23, is a machine connection protocol. See RFC 854, née RFC 15.
IRC, originally port 194, now usually found around port 6667, is a human (ASCII text) communications protocol. See RFC 1459 (and/or RFC 2810 et alia, for you new-agers).
Do you see where you are missing the point, and where the so-called "security expert" is missing the boat? This shit is all interconnected BY DESIGN. It was never designed with security in mind, and indeed, was designed to seamlessly link everything, allowing anyone, anywhere, to share information about everything, WITHOUT blocking information about that information.
The Internet is a research platform gone mad. It is NOT secure, and never will be, at least not in it's current incarnation. Those are the facts. Deal with it.
QUOTE
Uh ... John, telnet is a different protocol to IRC.
telnet, ostensibly port 23, is a machine connection protocol. See RFC 854, née RFC 15.
IRC, originally port 194, now usually found around port 6667, is a human (ASCII text) communications protocol. See RFC 1459 (and/or RFC 2810 et alia, for you new-agers).
/QUOTE
Uh... Jake, have you tried connecting to a non-telnet port using telnet? It's dead easy! You can also reply with expected IRC(X) commands and parameters to an IRC(X) server!
It's all well and good you spouting RFCs at people but if you actually look at what they're typing rather than trying to be clever you might just see the point that they're trying to make and instead of calling them dumb you can ADD to their knowledge and information with your OPINION as that is what all of this is... Opinion.
"Try joining Freenode using Telnet and you'll see how simple the process is."
Uh ... John, telnet is a different protocol to IRC.
telnet, ostensibly port 23, is a machine connection protocol. See RFC 854, née RFC 15."
So? smtp is a "machine connection" (as you call it) protocol too. Still, I can (and occasionally do, for testing purposes) telnet $smtp-server 25 and, typing the correct phrases, get the server to respond, accepting what I'm typing as an outgoing mail message. Similarly with pop3, and probably many other of those "machine protocols".
but the point of fail isn't in the context, it's the fact that instead of assuming that when he said "Telnet" he meant the MS telnet application, called telnet.exe, he meant the protocol.
I do agree with the rest of the post, however you really should just admit you made yourself look like a twat.
While preventing firefox from connecting to IRC servers is one way to solve the problem, the question is "how?".
IRC connections are usually silent until the client sends a username and a nickname, and they have both been processed, making it next to impossible to detect if the server at the other end is an IRC server until everything has already been sent down the tube.
Port filtering is useless, as IRC servers can be run on any port.
This is more a vulnerability/issue in the IRC server implementation used on freenode, as it doesn't reject clients who send junk along when initialising the connection (the HTTP headers), and would be far, far easier to fix in the server.
After all, this isn't a firefox specific issue. Concievably, you could do this with anything that uses a TCP stream, from an IMAP client to, as the article said, SIP.
I stopped using IRC many years ago due to the users rather than anything else. It just seems a happy hunting ground for the type of internet vandal that used to make defacement worms for fun. Other areas of the net seem to have been cleared of many of these losers, why can't IRC be better policed?
OK, the standard port for HTTP is 80. But I've occasionally visited sites running on other ports.
So is Robert "RSnake" Hansen saying that should no longer be allowed? I suggest before making such statements he does a quick Google search for "inurl:8080". It returns 203 million results. And that is just for port 8080, a common non-standard HTTP port.
And what about FTP? All the web browsers I use have built in FTP clients. So would that be disallowed too?
What makes a port "related" to HTTP? Until the browser actually makes a request, it can't know that site it is connecting to is not running HTTP.
This version of the attack may run on FF but its only a tweak away running the same on other browsers. I haven't seen the code but I guess the only reason it doesn't run on IE is IE is non standard and the writers haven't cross referenced with ajax lately.
The basic problem is with the way IRC registration is set up.
And any other system that allows you to register and use instantaneously is open to serious abuse.
"And any other system that allows you to register and use instantaneously is open to serious abuse."
True, which is why some IRC networks do demand you go through a web-based registration process first.
As for the monkey with the "IRC isn't Telnet" comment: duh! We know. You probably know. I think the commenter you replied to was trying to outline that IRC is not a complex protocol. You send an auth string in ASCII, and the server spits out craploads of messages at you prefixed by numbers. So long as you receive the incoming server PING message (not to be confused with a CTCP PING) and reply with your own, your connection will stay up. I've worked with the IRC protocol, I've implemented a reasonable subset of the client-side. I've scratched my head writing a parser for the 005 "BOUNCE" message that seems to have been hijacked and turned into a generic "Server Capabilities" message on most IRC daemons.
Point is, if you can make a bit of software - be it a web browser, email client or whatever - send arbitrary strings to an arbitrary port, you can make an IRC client out of it. Like Tom 7 here says, the basic problem is how IRC (or most IRC networks) is set up. Provide a web-based reg system with a CAPTCHA and require the user to auth themselves with nickserv before any PRIVMSG commands to anywhere _other_ than nickserv get parsed, and you've fixed this little problem.
Also, not clicking on every link that strange people send to you would help.
"Point is, if you can make a bit of software - be it a web browser, email client or whatever - send arbitrary strings to an arbitrary port, you can make an IRC client out of it."
No shit. In the old days, we used shell scripts to make "talk" more manageable on text-only terminals. When IRC came about, a few of us munged those scripts to use IRC ... Even today, I use telnet and/or shell scripts to control the DSL "modem" in the barn, not the HTTP interface. I'm not unaware of how TCP/IP works (including under Windows, BTW, not just un*x ...). Again, please re-read my original in it's entirety and try to parse what I was trying to convey instead of taking a couple lines out of context. Ta.
"Provide a web-based reg system with a CAPTCHA"
CAPTCHA is b0rken. I never did trust (or use) it.
"Also, not clicking on every link that strange people send to you would help."
Knee-jerk is "Duh!" ... but it will never happen, at least not so long as people still have a curiosity bone AND a lack of technical background ...
The ED page actually gives an ipfilter command that disables this attack, and it's not exactly something that should be esoteric to anybody who runs an IRC network. It looks for HTTP POST stuff and drops it. That's pretty much it. For example, EFnet figured this out within an hour.
What excuse does Freenode, or any other network, have for remaining vulnerable to this attack?
I remember running an IRC server, that if the request came from a browser rather than an IRC client used to bounce back a friendly message of "Try again with an IRC program dummy"
mind you this was in 1995 so I suppose asking freenode to have caught onto an idea that has been in use for 15 years might be asking a lot
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
