search

eclipse-emf / org.eclipse.emf

Eclipse Public License 2.0
10 stars 13 forks source link

EMF model namespace URI possible exploit? #8

Closed Phillipus closed 1 year ago

Phillipus commented 1 year ago

We've had a report that indicates that loading an EMF model XML file with a changed Namespace URI can lead to a possible exploit:

https://github.com/archimatetool/archi/issues/946

Our EMF model simply declares the namespace URI, and I can't see how we can change anything in this regard. Should EMF or any of its dependencies be accessing a namespace URI in this way? Is there any way to stop that happening?

merks commented 1 year ago

There is this option that you can use to turn off that behavior.

https://github.com/eclipse-emf/org.eclipse.emf/blob/53bef72fc4ef043ccc28487c3c48275a4e4b1722/plugins/org.eclipse.emf.ecore.xmi/src/org/eclipse/emf/ecore/xmi/XMLResource.java#L540-L545

Phillipus commented 1 year ago

There is this option that you can use to turn off that behavior.

@merks Thanks for the fast response! And I just found that option at the same time as you posted. :-)

I will set that option to false, but do you think that report amounts to something that is exploitable in EMF generally?

merks commented 1 year ago

If I think of the 10,000 different ways that EMF loads resources from URIs then I think it's a bottomless pit. As for exploits, I think it's really up to the downstream consumer to determine if there is a risk. I.e., where do the resources come from? From some random stranger who drops by in the middling of the night? Or from the developer writing the resource.

Note that in all cases, the traffic is funneled through the org.eclipse.emf.ecore.resource.URIConverter.createInputStream(URI, Map<?, ?>), so anyone can place whatever controls they want or need to control which URIs are permitted.

Phillipus commented 1 year ago

If I think of the 10,000 different ways that EMF loads resources from URIs then I think it's a bottomless pit...

Yep, I agree.

For our usage, we only need the NS URI to be a unique identifier, so the actual URI is arbitrary and doesn't host any packages or artifacts. Therefore OPTION_USE_PACKAGE_NS_URI_AS_LOCATION set to false is perfect.

I'll close this one and thank-you for your time. :-)

merks commented 1 year ago

You're welcome. 😁 Note that Discussions are enabled for this repository for asking questions.

Phillipus commented 1 year ago

Note that Discussions are enabled for this repository for asking questions.

Yes, sorry. Next time. :-)