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).

It is much more sensible and intuitive.

Take http://pastie.org/10242118 and create yourself a favicon file:

dd if=/dev/zero of=favicon.png bs=1M count=4096

gzip -9 favicon.png

you can now crash lots of browsers with minimal bandwidth usage :)

demo: http://dev.tomjepp.uk/

edit: to clarify, i'm talking about in the page itself rather than the favicon.

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.

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...

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.

http://www.netresec.com/?page=Blog&month=2015-03&post=China%...

also, interesting discussion from wayback:

https://bugzilla.mozilla.org/show_bug.cgi?id=260500

http://www.troyhunt.com/2014/10/find-crazy-stuff-in-mobile-a...

"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!!!"

There is nothing with Ajax that does that automatically or even by default.

With the favicon issue these things don't happen.

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.

Or at least make it's absence a non-logworthy event.

Or replace it with something sane, like a .png.

Edit: Actually on further investigation they might be omitting a header, but they're still 99% valid.

But it's not really that bad. Well under 200 bytes of overhead for 1000 pixels. PNG has under 50 bytes of overhead.

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).

I don't think we're ready for 60 FPS .gifv favicons just yet. :)

NB: Not that I condone this.

[1]: https://twitter.com/a_de_pasquale/status/608997818913665024

My bookmark bar is entirely favicons. I remove the name and this allows me to fit more in quick-access without having to delve into folders.

Unfortunately, you run out of sensible emoji very quickly, so my brokerage ends up 🎲, Github ends up 🐱, and Hacker News ends up ⌛️.

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.

This would be a good idea to get fixed very soon, I would assume.

EDIT: I stand corrected in terms of exploit-ability, but I still assert that crashing a browser and chewing tons of bandwidth are pretty big issues.

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?

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.

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.

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.

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).

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.

  if(g_str_has_suffix(uri, "/favicon.ico"))
      webkit_network_request_set_uri(req, "about:blank");

Thanks for reminding me to report it ;^)

    ln -s /dev/urandom /srv/wwwroot/favicon.ico

   function fetchFavIcon() {
       if (favicon.fileSize > 1MB) { return false; }

       ...
   }