|
| 1 | +# Security: Cache-based SOP-Bypass for Images |
| 2 | + |
| 3 | +> Reported by [email protected], Jun 4 2014 |
| 4 | +
|
| 5 | +> That's an actual report (lol): |
| 6 | +
|
| 7 | +## SUMMARY |
| 8 | + |
| 9 | +I've got a cache-based SOP-bypass for images in the current up-to-date versions of Chrome: |
| 10 | + |
| 11 | +In essence, I can bypass the SOP restrictions to load any protected image the victim has access to (like from private gallery albums etc.) and exfiltrate it to my attacker origin, as long as the image is served without anti-cache headers. So basically it boils down to a SOP-bypass that makes use of image caching to bypass SOP checks. It doesn't matter if the image is served over https or http. |
| 12 | + |
| 13 | + |
| 14 | +## VERSION |
| 15 | + |
| 16 | +Chrome: 35.0.1916.114 Stable |
| 17 | + |
| 18 | +## REPRODUCTION CASE |
| 19 | + |
| 20 | +Here are the steps to reproduce (I've set up a demo on two domains for you to see it in action): |
| 21 | + |
| 22 | +1) Open (in Chrome) the victim's "secret photo album" at http://0xbeef.de/secret/index.html (login using HTTP Auth with user "test" and password "secret"). |
| 23 | + |
| 24 | +* Note that this could also be a cookie based auth: I've tested that also, but here for simplicity it's HTTP auth - either way, the folder http://0xbeef.de/secret/ is protected including the victim's secret image to exfiltrate http://0xbeef.de/secret/secret.jpg |
| 25 | + |
| 26 | +2) Open in another tab/window the page controlled by the attacker at http://christian-schneider.net/exploits/chrome/SOP_Image_Cache.html |
| 27 | + |
| 28 | +* This page uses SVG as well as Canvas to "embed" the secret image cross-origin and strip it as dataURL and echoes it via alert and a textarea. This is just for you to easily verify the exploit by copying the dataURL content from the textarea into some <img src="...."> in order to see that this really is *the* secret image, the attacker has accessed from the victim's login, effectively bypassing the SOP for canvas-images *without* triggering a "tainted canvas" security exception. |
| 29 | + |
| 30 | +* The point is that the exploit uses the <object> tag *before* dynamically fetching the same image referenced from within the SVG and effectively exploits that the image cache does not enforce the SOP when it is embedded into an SVG using xlink. Eventually <img> would also work to "populate" the cache instead of just <object>. |
| 31 | + |
| 32 | +* Using other ways to embed cross-origin images and exfiltrate them using Canvas result in a "tainted canvas" security exception. But this way works ;) |
| 33 | + |
| 34 | +## DESCRIPTION |
| 35 | + |
| 36 | +Real world exploitation scenarios would either know the image URLs or simply brute force (for ascending numbers in image file names in protected galleries for example) to secretly exfiltrate private photo albums or other "secret" document images from the victims (like online banking charts of private portfolios or alike). The only "requirement" for the attacker is that the image is not served with anti-caching headers, which would otherwise effectively prevent the cache-based image SOP-bypass. But this "requirement" holds true for most protected photo albums or alike, which could be leaked that way... At least when a minimal caching period is allowed. |
| 37 | + |
| 38 | +Another exploitation scenario is for the attacker to check wether the victim is logged in with some sites or not in case the sites serve different images or not depending on the logged-in state. |
| 39 | + |
| 40 | +Link: https://bugs.chromium.org/p/chromium/issues/detail?id=380885 |
0 commit comments