
Favicon bug - inglor
https://github.com/benjamingr/favicon-bug
======
inglor
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](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).

~~~
0x0
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.

~~~
aw3c2
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"-

It is much more sensible and intuitive.

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

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

~~~
tomphoolery
_always_ use long form flags when writing scripts...have some consideration
for the person who has to fix your code when you move on

------
tomjepp
Even better - this works with compressed favicons.

Take [http://pastie.org/10242118](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/](http://dev.tomjepp.uk/)

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

------
yincrash
What prevents someone from doing this with a 1 px junk image that is many GB
large?

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

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

~~~
stock_toaster

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

favicons can also be inserted dynamically.
[http://stackoverflow.com/questions/260857/changing-
website-f...](http://stackoverflow.com/questions/260857/changing-website-
favicon-dynamically/260876#260876)

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.

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

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

[http://www.netresec.com/?page=Blog&month=2015-03&post=China%...](http://www.netresec.com/?page=Blog&month=2015-03&post=China%27s-Man-
on-the-Side-Attack-on-GitHub)

------
protomyth
So a screwed up favicon can eat a wireless user's whole bandwidth for the
month with them knowing it. Great...

~~~
icefox
Only if you mobile browser actually download them, ios for example from what
it looks like doesn't.

~~~
protomyth
Some folks use cell (direct or tethered) on our laptops.

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

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

------
drivingmenuts
I pray once or twice a month that someone somewhere will just end the favicon.

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

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

~~~
porges
All major browsers support PNG favicons

~~~
Dylan16807
Not only is there support in practice, but PNG files have been technically-
valid .ico files for a decade.

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

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

~~~
vacri
"The most memory anyone needs is 640k"...

~~~
ahoge
Hard limits aren't much of an issue if updates are rolled out ever 6 weeks.

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

 _NB: Not that I condone this._

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

------
TD-Linux
Did you file bugs for either of these two browsers?

~~~
inglor
Good idea
[https://code.google.com/p/chromium/issues/detail?id=500639&t...](https://code.google.com/p/chromium/issues/detail?id=500639&thanks=500639&ts=1434390736)
[https://bugzilla.mozilla.org/show_bug.cgi?id=1174811](https://bugzilla.mozilla.org/show_bug.cgi?id=1174811)

~~~
groby_b
Is this a Mac only bug, or have you only repro-ed it on Mac?

------
fugyk
Why do browser people always forget about favicons? Most browser saved favicon
on private browsing and then this.

~~~
frik
...and used favicons for the bookmarks.

~~~
Nadya
Mind telling me why that is an issue?

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.

~~~
erichurkman
Same here. Sadly Safari does not use fav icons in the bookmark bar, so all of
mine are emoji.

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

------
gtk40
How do other browsers behave?

~~~
inglor
Firefox doesn't behave too well either. Gets to 23169 in the counter
[http://i.imgur.com/3zkPKD7.png](http://i.imgur.com/3zkPKD7.png)

~~~
moskie
So why single out Chrome in this repository and post? Feels like a hit piece
on Chrome this way.

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

------
underwater
You should try and use ServiceWorkers to generate the file -- then you can
have the client DOS itself.

------
tomswartz07
This seems like an active exploit, as pointed out in the OP's inspiration
Twitter post.

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

~~~
desbo
> `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?

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

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

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

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

------
jakeogh
I like Surf's approach:

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

[http://git.suckless.org/surf/tree/surf.c#n237](http://git.suckless.org/surf/tree/surf.c#n237)

------
ubanholzer
it's also working on iOS 8.1.2. As soon as you tap on the share icon, the
download starts: [https://github.com/benjamingr/favicon-
bug/pull/2](https://github.com/benjamingr/favicon-bug/pull/2)

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

Thanks for reminding me to report it ;^)

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

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

~~~
ubanholzer
Safari Version 8.0.6 (10600.6.3) on OS X 10.10.3 is downloading it:
[https://imgur.com/B2LeRy4](https://imgur.com/B2LeRy4)

------
empyrical
Should this have been done as a private disclosure to browser vendors first
before going public, or is that more for security problems?

------
firlefans
Way to ruin the fun for the rest of us ;)

------
voltagex_
Anyone tested Firefox/Chrome/Webview for Android?

------
vezzy-fnord
Interesting to see server-side JavaScript being used as an exploit language.

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

~~~
ghuntley

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

------
nodesocket
Seems like an easy and logical fix for browsers.

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

