Preventing SSRF due to external resource refs in SVGs

Until batik 1.13.0-SNAPSHOT it is not possible to prevent SSRF vulnerability exploits due to SVG external resources. TwelveMonkey’s imageio-batik, which relies on batik 1.9 at the moment, suffers from this. See the test file as linked at [0].

Apache Batik fixed it via BATIK-1276, and this issue is to track rolling-up this change in TwelveMonkeys as soon as new batik version is released.

Very trivially, if external-resource processing is to be blocked altogether in SVG processing for TwelveMonkeys’ imageio-batik, a patch like at [1] should be sufficient. While we wait for Batik’s update, I’d like to invite the opinion of project maintainers on sufficiency of changeset at [1] from imageio-batik’s functionality perspective. If I receive guidance on this I’d be happy to work on a patch as soon as a batik release with BATIK-1276 is publically available.

[0] https://issues.apache.org/jira/secure/attachment/12988316/test.svg [1]

diff --git a/imageio/imageio-batik/pom.xml b/imageio/imageio-batik/pom.xml
index 385f666..3dacf15 100644
--- a/imageio/imageio-batik/pom.xml
+++ b/imageio/imageio-batik/pom.xml
@@ -88,6 +88,6 @@
     </dependencies>

     <properties>
-        <batik.version>1.9</batik.version>
+        <batik.version>1.13.0-SNAPSHOT</batik.version>
     </properties>
 </project>
diff --git a/imageio/imageio-batik/src/main/java/com/twelvemonkeys/imageio/plugins/svg/SVGImageReader.java b/imageio/imageio-batik/src/main/java/com/twelvemonkeys/imageio/plugins/svg/SVGImageReader.java
index c55012d..96f2060 100755
--- a/imageio/imageio-batik/src/main/java/com/twelvemonkeys/imageio/plugins/svg/SVGImageReader.java
+++ b/imageio/imageio-batik/src/main/java/com/twelvemonkeys/imageio/plugins/svg/SVGImageReader.java
@@ -594,6 +594,7 @@ public class SVGImageReader extends ImageReaderBase {
                 }

                 initialized = true;
+                addTranscodingHint(KEY_ALLOW_EXTERNAL_RESOURCES, false);

                 super.transcode(transcoderInput, null);
             }

[actinium15]

hi @haraldk, thanks for acknowledging my report!

a PR with the proposed change (preferably with unit tests for both enabled and disabled external resource parsing).

Sure. Here’s the PR…

From what I understand, your suggested patch relies on the yet to be released Batik 1.13 so it’s not possible to avoid the SSRF vulnerability with the current or any other released versions?

I tried to answer your question by looking at the updates this patch makes to SVGAbstractTranscoder. I think I can make it work without a new batik release (though it’d be much easier to accomplish in 1.13). The PR follows aforementioned suggestion.

If same origin requests does not count as “external resources” in this context, we might not need it, but this isn’t clear to me

It’d appear even the same origin requests are considered external resources.

client code might need to allow external resources in certain cases…locally using SVGReadParam

That makes sense. And while I’d agree with blocking external-resources as default behaviour, I fear it sounds backwards-incompatible (esp given your concern around same-origin resources). Hence my PR keeps the existing behaviour (of processing external resources) as default.

I’ve had a bit of a mixed experience when upgrading Batik … due to incompatible changes between versions. Did the build/tests pass using the latest version, without any other modifications?

Yes, they did (except for the ones which were affected by the change in how xlink:href are resolved. In fact, these failures were what made me respond to your question around “same-origin-resource-resolution considered external” as “yes”.

[actinium15]

Thanks @haraldk! Will wait for the new release… Stay safe 🙏