So..
Does this affect those using Noscript?
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 …
This topic is closed for new posts.
Infuriating
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.
FireColander
I'd give good money if someone'd make the damn thing secure for once.
Mind you, I guess that'd make it commercial software. Oh, the irony.
Web browsers not the problem
What I don't understand is why Freenode won't acknowledge the problem, and even go so far as to blame their users. I see this kind of behaviour all the time in the community; it's no wonder why people don't take OSS projects more seriously.
Not the first!
Consider all the various worms that worked by spreading links to IE6-exploiting trojans via AIM/MSN/etc., and there is another recent one which spreads via Steam messaging.
Last week it was IE...
...this week it's Firefox. If you're on the Internet, you're vulnerable, even if you're sure you aren't.
Eh?
""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 ...
Errr...
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.
Pedantic
You're being pedantic. You're also the only one in the world still using Gopher.
Catch-22
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?
Gopher
Not so! I used it only last month, but it was for a nostalgia trip!
But the real question here is when is an obsoleted protocol/service no longer required. I'm sure a lot of people would like to see ftp deprecated, but it's not going to happen for a while yet.
@Bilgepipe
Not quite the only one ... See:
gopher://gopher.floodgap.com/1/world/last-hit
Franco-German Volta Face?
Will the French and German goverments now be advising their citizens to avoid using Firefox?
All lies!
Firefox doesn't get viruses and exploits! It's perfect because it is open source! This is clearly filthy slander spread by M$!
All Lies!
Firefox had more published security exploits than IE 7 for the last 3 years running.
Because...
...Mozilla hold all such reports in the open, not in down the stairs to the basement, in a filing cabinet in a disused lav with "Beware of the leopard" on the door as MS does.
Beware of the leopard..?
I'm sure it should be "Beware of the Snow Leopard" nowadays...
Security through obscurity
"Browsers absolutely should not be able to connect to ports unrelated to HTTP."
Can you really stop anyone from attempting to connect to a specific port? Merely disabling this feature in web browsers sounds like security through obscurity to me.
Seems to me the problem is with the irc networks
IRC nets could simply demand the user respond to a ping before allowing channel joins or private messages. 15 Minutes to patch at most.
*yawn*
Agreed, I am fairly sure this is not really a FF problem it is just exploiting the fact that IRC is a text protocol and will interpret anything that is sent to it from any program that connects to it .
pings...
Most nets DO require a ping reply (random cookie provided, must give it back)
The script being used must have some interactivity within it to cope with the antispoofing stuff most nets have had for more than a decade.
Midori is unaffected
At least in my quick pidgin tests. I'm no security researcher. Other webkit-based browsers probably don't work either.
only thing
I'd like to leverage is weev's jaw open with a crowbar and insert a stick of dynamite
No better than than someone who spray paints a tag over a newly painted wall or rips all the flowers out of someone's garden
The road to hell…
…is paved with good intentions. I can only see this type of problem getting worse, as browsers are extended piecemeal, in an attempt to remove the need for plug-ins.
Another one for the preference network.security.ports.banned.
Whee! A Firefox vulnerability!
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?
However
While freenode IS getting its act together (it's in the middle of a major transition), if people use NoScript the problem goes away.
"Browsers absolutely should not be able to connect to ports unrelated to HTTP"???
Every port is related to HTTP if you run HTTP services on it. This bit of wisdom is coming from a "web security expert"?
Not so simple
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.
@John 170
"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.
@jake
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.
What 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."
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".
@Chris 35 & Stoneshop
Kindly re-read my complete post for context, instead of cherry-picking a couple lines from said post. Without that context, the lines are drifting in a vast sea of obscurity.
Ta in advance.
The rest of the post makes sense
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.
N/t
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.
Hah
NoScript would leave this dead in the water.
Make NoScript a part of standard Firefox.
RE: Seems to me the problem is with the irc networks
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?
Mandatory title
I've used IRC in the old days and then took a 10 year break. On returning to IRC I found that most of the valdals/trolls had moved on (same with Usenet). Freenode & OFTC have a very high signal to noise ratio. It's a world apart from the IRC of old.
Ports unrelated to HTTP and web browsers
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 is not a firefox problem its the IRC.
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.
Title not required.
"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.
@M Gale, from A. Monkey
"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 ...
Return to sender ?
Why not place the same restriction on Javascript that Sun have on Applets: The script can only make network connections back to the server it was downloaded from ?
lmao, firefox is garbage [ie supremacy]
What a joke. Mozilla owns cause instead of creating exploits that require the user to install a plugin or something, they decided to just let javascript do whatever the website wants.
open sores software ftl
Thank you for flying Freenode.
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?
freenode behind the times
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
This topic is closed for new posts.
Sign up, sign up for The Register's weekly IT security newsletter - click here
Popular Whitepapers
- The BI Inflexion Point
Information is a right, not a privilege - VPN security - if you want it, come and get it
Attention WiFi hotspotters: You want it - The Register Guide to iSCSI
A primer on Internet SCSI, a protocol to transport SCSI commands over IP - Secure Mobile Working
Beyond the Technology - The Impact of IT Security Attitudes
Putting the pieces in place for effective security delivery - The Register guide to unified communications
A primer on the implications of unified communications for enterprise IT
