Do not allow global tags by default

[Andrey Somov]

To prevent remote code execution when the data comes from untrusted source, the global tags must be explicitly enabled. They should be disabled by default.

The standard tags are always enabled.

The global tags start with !! (the tag directive is respected). The local tags are always allowed.

[Andrey Somov]

Implementation:

https://bitbucket.org/snakeyaml/snakeyaml/pull-requests/44

[Or Peles]

Hi Andrey,
Regarding the currently merged fix (https://bitbucket.org/snakeyaml/snakeyaml/pull-requests/44),,) due to the fact that the security check itself (in isGlobalTagAllowed) relies on the 'startswith' function, in certain circumstances it could allow tags of unintended packages/classes to pass through. For example - the use of allowClassPrefix("java") for allowing java.* classes will also unintentionally allow classes of the javax.* package as they both .startsWith("java"). Such code will be exposed to the ScriptEngineManager gadget chain used in the original exploit.

As such, we suggest adding a "." postfix wherever possible. For example, in the existing tests in TypeSafeMapImplementationsTest.java, use allowClassPrefix("java.") instead of allowClassPrefix("java"), so developers relying on them will not be exposed to the aforementioned exploit.

[Andrey Somov]

Please note that the current code does NOT depend anyhow on the 'startswith' function.

What you see is the implementation for tests. An example implementation is given as reference. Those who explicitly enable it can do whatever they wish.

‌

[Or Peles]

This is exactly my point, since the example implementation is vulnerable, I worry that users may copy this example as-is and become vulnerable as well. Changing the example to "java." won't cause any side-effects and will "show" the users how to use this API more securely.

[Andrey Somov]

Ok. I will remove the example completely

[Jonathan Leitschuh]

That's a good plan. IMHO a vulnerable example is worse than no example at all

[Andrey Somov]

The example is NOT vulnerable. Otherwise this is also vulnerable because a bad developer may misuse it.

[Carlo de Wolf]

Using “java” as opposed to “java.” can only be considered a bad coding practice which may have unintended side-effects such as introducing a vulnerability. I agree with Andrey, the example itself has no vulnerability. But it might get augmented to show good coding practices. Likewise TrustedTagInspector should be used judiciously.

[Andrey Somov]

It will be delivered in version 2.0

https://bitbucket.org/snakeyaml/snakeyaml/wiki/Changes

[Timothy Lyanguzov]

Perfect. When this fix is going to be released?

[Andrey Somov]

as I said - in version 2.0

[Timothy Lyanguzov]

So, the question is still the same “When version 2.0 is going to be released?”. The date. There is no need to wait until other non-security-related issues are resolved. Many people are waiting only for this single fix.