fake image file will result in DoS
Reported by
zdz...@gmail.com,
Nov 9
|
|||||||
Issue description1. make an evil large file in a web site the evil large file should have a normal image header, if the large file do not have a valid image header, this test will failed. so, the first thing is to get a valid image file, such as normal.png next, we make the large file evil.png with the command in shell : cat /dev/random >>normal.png abort the command untill the normal.png is big enough, such as the file size is 5G. then,put the large file evil.png into a web host, so the url http://evil.com/evil.png is reachable. 2. make an evil html page make an evil html page http://evil.com/evil.html , content like this <html> <body> <img src="http://evil.com/evil.png"></img> </body> </html> 3. open the html page in chrome of android as a DoS attack, we send the url http://evil.com/evil.html to victim user, when the victim open the link, this will kill a lot net flow, especially in 4G mode. in img tag, chrome should have a switch to set the max size of image file to download. And, it will be worse when in CEF based UI, which not only affect android chrome but also all the CEF based production Large file will cause net flow DoS in Android Chrome
,
Nov 9
I doubt there is anything actionable that can be done here. But I'll leave it to the network team to comment.
,
Nov 12
The network stack doesn't decode images, nor should it, as it doesn't know what images are. Up to the blink team if they want to cancel requests once they know they aren't valid images, or images that are too large.
,
Nov 12
What, if anything, can we do to error out on images that are "too big" before we download them, particularly if not invalid? My guess is that the network layer fetches the while thing even before we see it, right? So it would have to be the loader coordinating with the decoder, or special rules in the loader for fetching images.
,
Nov 13
,
Nov 13
Marking as Available. Dealing with it is a fairly large cross cutting project, not something we have the resources for right now.
,
Nov 13
The decoder might know when it has reached the end of an image (for example, it finds the IEND of a PNG or the 3B trailer of a GIF), and it will decode even with partial data. So it would need to have an accessor to report it's parsed to the end, and the loader could know to stop downloading data? This would have to work a little differently if the image starts off looking valid, but then trails off into excess data (e.g. a PNG with extra chunks after the IDAT). Then the decoder won't know until it's actually decoded to the end (as opposed to simply parsing, a separate step that's used for animated images). Taken a step further, you could have an incredibly long APNG with lots and lots of frames; a "valid" APNG could have (2^31)-1 frames. Similar with GIF, where the image doesn't need to declare how many frames it has, it could just keep appending valid frames without ever reaching the 3B trailer. So in the general case, I don't know what we could do here.
,
Nov 14
So, would you gays have the plan to fix it? It make trouble in CEF based application, as this will kill a lots of net flow, especially in mobile app when running on 4G net. The worst case is this can make DDOS to a net site by some IM like clients. I still think it is a DoS vulnerability, as exhaust net flow is exhaust money. :)
,
Nov 14
Is it possible? add an option to chromium, setting the max download image file, stop downloading when exceed the max image file size.
,
Jan 11
Setting defect without priority to default. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by kenrb@chromium.org
, Nov 9