I'm the author of the GH repo and I just want to give full credit for figuring out Chrome does this to this guy: https://twitter.com/a_de_pasquale
All I did was think "if it works for 65mb why not more?" and write a quick proof of concept. Gets to 10gb on my 4gig laptop and then crashes. (MBA, OSX 10.10).
Wow, the twitter replies suggesting this was an accidental "tar cvf * backup.tar" sound right on the mark. Especially considering favicon.ico is probably the first file in a wp install, alphabetically.
For everyone struggling with tar, please be aware that you can use long-form arguments. So instead of "tar cvf filename files" you use "tar --create --verbose --file file.tar files" or maybe another order like ""tar --create --file file.tar --verbose files"-
Once you've used it more than once or twice, however, you will find that writing cfv is much more convenient than typing --create --verbose --file every time you want to tar something.
But if it's code you're only writing once - like in a script - you might consider using the longer ones to avoid screw ups and improve maintainability.
This makes a 4GB file when decompressed and is plenty large enough to crash a 32-bit browser. You may need a larger file to reliably crash 64-bit browsers.
Haven't tried it, but does it crash the browser or the tab? Under Chrome's architecture, a page should potentially be able to crash the tab, but not the browser. (or that's my understanding of it, anyway)
Just a couple of off the cuff thoughts on that. Nothing out of the box prevents what you describe as far as I know but one of the points made in the article is that favicon is downloaded without any update to or indication from the status bar. An image on the page will at least throw up a "waiting for evil.com" in the status bar giving a user some indication that something being downloaded is causing a major slow down.
Typically an ad-blocker or script blocker can be used to prevent the image from downloading. But I don't know of a blocker add-on that worries about favicon.
Overall while annoying and a bit strange that this wasn't anticipated and fixed long ago I'd say this is probably a non-issue. As another poster said I don't see a payoff here so I doubt it will be actively exploited in some "internet screeching to a halt" kind of way.
> Overall while annoying and a bit strange that this wasn't anticipated and fixed long ago I'd say this is probably a non-issue. As another poster said I don't see a payoff here so I doubt it will be actively exploited in some "internet screeching to a halt" kind of way.
If some site has a js injection bug, or there is someone doing MiTM like the Great Firewall, I suppose they could inject a favicon link that referenced some location on another site, with the intent towards DoS.
Well I don't disagree but on the other hand the article is focused on what it does to a client so I wasn't thinking it through the way you are.
It also occurs to me that given the ability to insert yourself between the client and the server has to open up a number of possible attack vectors that are more worth while than crashing the client. I get (I think) the point about if censorship is the goal this is a way to make clients stay away from a particular server but if you're in a position to MITM them why not just return 404's and be done with it?
Not trying to argue, :-) Just want to make sure I'm understanding your point correctly...
I assume you can (untested) reference https endpoints with a favicon?
If you can inject html though, a hidden image would probably would just as well. Although the behavior of chrome apparently still requesting the favicon file after the tab has closed, and possibly storing it in the history or bookmark file, may make this more or less appealing. Unsure.
my guess is if no favicon is specified browsers request for the default favicon path after page load (possibly) in a non render thread. that's definitely an issue, right?
Not to minimise this issue but there are other ways for websites to silently waste user bandwidth. I think the real issue here is that it crashes Chrome and can render the computer unresponsive.
"Here’s a pop quiz for you: how much data do you reckon this iPad app downloads when it first runs? I don’t mean how big it is to download from the App Store (it’s 25MB), I mean after you download it then simply tap the icon to fire it up, how much data does it pull down if you don’t touch it again? ... Try 1.8 gigabytes. You heard me, that’s not a typo. You open up this 25MB app and it’ll pull down dozens of files of dozens of meg each when you run it. Won’t someone please think of the bandwidth!!!"
True but the amount of webpages I visit where the spinning icon never stops spinning, I don't really pay it a 2nd thought. An enormous image set to hidden would have a similar effect.
Mind you I'm sat at home with a 300Mbps fibre connection, so I don't give as much thought to bandwidth as a roaming 4G/3G user might.
Web workers will not show a loader indicator however. You could probably do a nice DDoS attack like this even. But it requires users to be on your site anyway. Might as well just stick 0day du jour on it.
This reminds me of a bug I found in an internal tool. We only had about 200 users, but somehow Apache would run out of workers because they were all busy serving some kind of request. Turns out our Apache configuration was wrong specifically in the case of serving the favicon. If you requested the favicon, it would get in a redirect loop, increasing the length of the url a little more each time until it hit the maximum url length and gave up. A new job like this would get kicked off every time any user visited a page, and it'd take several minutes before it finally gave up. So every user was unwittingly opening tons of long-running requests, with no indication that they were doing anything.
Yeah, I hit something sort of similar but on the client side: While clicking around a single-page webapp, Chrome would manage to use up all its outbound connections (10 or so) trying to download non-existent favicons, leaving none for real use. And those favicon requests somehow never timed out. Chrome's favicon handling is pretty bad.
Just doing some quick back of napkin maths, even assuming Apple's 128x128 app icons, and 48 bit colors (32 is more typical), we're still talking about a sub-100 kb max for a favicon.
So if Chrome set it even at 20 Mb that would still be orders of magnitude more than any favicon should be for at least the next five or so years (even assuming 256x256 became common for app icons).
That was said with a wide open scope. Bill was wrong because he hadn't imagined all the things people might do with PCs. In this discussion, the scope is very limited; favicons.
In reply to both this and the original discovery[1], I wonder if this is a valid (albeit morally dubious) method of backing up (or at least ensuring the survival of) information that is at risk from government/<insert 'bad person' here> censorship/removal/other.
Well, I didn't really consider Firefox and I didn't want to publish anything unsubstantiated about it. No intent to single out or attack Chrome - I've changed the title to clarify that now that I have evidence this works in FF.
Investigating and reporting a bug should never be considered "singling out" of a piece of software. Personally, I'd be grateful if someone pointed out a critical issue like this in my code. It means I have the opportunity to fix it!
Well, Chrome is a very commonly used browser, and I would guess that other browsers look to it for guidance on features.
Also, it seems to me that the post is only a proof of concept. "Hey, look at what happens here in this browser. I've extensively proven that it's possible. Maybe people should check it out under other circumstances."
> `tar` up an entire WordPress install, save it as `favicon.ico` and then easily pull the files from the server.
assuming I have access to the server to create the tar and save it, what's the difference between downloading the archive as favicon.ico or any other name?
If you don't have control over the logging (for a number of reasons) you can disguise your xf in the access logs. I'd be willing to bet that a lot of logging config files for access logs even ignore favicon.ico.
You could also hide it as any kind of regular static resource. I still don't understand how it's any worse than, say, hiding a massive image in a webpage. Bogus websites are going to be bogus no matter what, I can understand browser devs not wanting to guess arbitrary limitations for some resources when an hostile attacker will have plenty of other opportunities to achieve the same thing.
What would be the point of adding a limitation to the favicon size really? Protecting users from websites where the webmaster is silly enough to put a 1GB favicon by mistake? Doesn't seem common enough to warrant the extra code IMHO.
>What would be the point of adding a limitation to the favicon size really?
Uh, yea, the browser shouldn't become unresponsive, break, or behave in such unexpected ways. Not having a limit is just sloppy. Understandable how it'd be overlooked, but sloppy none-the-less.
That's reasonable, but won't you get the same result in a million other ways?
I agree that preventing the browser to become unresponsive when loading bogus/malicious pages is a worthy objective but I don't see why the favicon needs to be singled out as a "bug".
These kinds of deny of service attacks against browsers have been known since, like, forever and they're basically impossible to completely prevent given the surface of attack and the complexity of modern web pages.
Whatever that website is, has an issue, since that backup.tar may contain their database credentials.
The favicon thing is just an annoying browser crashing bug. You could call that an "exploit" but up until fairly recently you were able to crash many browsers by generating too many message boxes (e.g. alert()) asynchronously.
So while, yes, it would be nice to fix it I don't really see it as being a high priority or one which will be actively exploited (since there is no "payoff" to either prankers or bad guys to this exploit).
Eating users' bandwidth has its uses as well as filling up a network with communication. This works with JavaScript disabled too but yeah I agree it's not a huge priority.
I know for a fact that eating mobile bandwidth would be a huge priority for some (as far as getting it fixed). For example; I live in Canada and my mobile plan is only for 8gb. If I go over I have to pay a premium, and it is not a cheap premium. I don't think unlimited bandwidth on mobile is popular (at least here, I suspect other places cough India cough) as well.
Even if you cap favicon size you don't solve the issue you're discussing at all.
A bad actor web-site can just move from favicon to an image, script file, or just return an indefinite series of HTML characters with no end.
The only way for the issue you want solved to be solved is for mobile browsers to add a "max page size" option, that will stop downloading content after it hits the cap.
In general this favicon bug is neither here nor there with the issue you're concerned about. Nobody needs this to waste your bandwidth.
The only reason this is noteworthy is that it is a little embarrassing for the browser vendors and it causes the browsers (Firefox and Chrome) to crash.
I've noticed it several months ago by going through my server logs - hadn't included 'favicon.ico' in the HTML and yet, the browser - Chrom(e|ium) - tried downloading it every time.
Most browsers have been doing that since favicons have existed. Older versions of IE used to check for /favicon.ico no matter what, even if you specify a different URL with a <link> tag. You really have no choice but to make the file available at the URL even today.
Just tested on Safari 8.0.6, doesn't seem to download the favicon at all. Weird, even after closing the tab, Chrome still keep downloading the favicon.
This is about as easy to do with every other language - I could have done it in C, or Python or PHP or Java or C# or whatever - node was just the lowest friction one for the PoC - all you ned is an HTTP server that lets you write dynamic requests - could have been bash even.
All I did was think "if it works for 65mb why not more?" and write a quick proof of concept. Gets to 10gb on my 4gig laptop and then crashes. (MBA, OSX 10.10).