Actual CVE-2018-8088 issue?

[ecki]

Hello Ceki and Ralph, or maybe somebody else remembers:

i Wonder about the nature of the old CVE in slf4j-ext. Since the closure of Bugtraq it seems to be a bit hard to find the original report, and I wonder what’s the actual deal with EventData was. The common deserialisation problems are not present:

• does not use java deserialisation
• Does not provide a socket server or file interface to get in touch with untrusted serialized data
• The existing deserializer (constructor) is not called
• Uses javax.beans.XMLDecoder

so it looks to me like it is not vulnerable itself, the only thing I could see is that it allows to be used as a gadget, but if it does, it would be XMLDecoders problem.

I am asking since I try to avoid similar problems (and in fact EventData still looks somewhat useful?)

Reference: 918a055#diff-b6ba7f7ee149419706518dfeb530ee63b55aadb5f964e480699567400faa5a43

[ceki]

EventData was serializable. Moreover, its deserialization offered no safety checks. If I remember correctly, it could this be used to mount deserialization attacks using malicious data.

[ecki]

Hm, no that can’t be it. It does not construct a ObjectInputStream. Many classes are serializeable, that on itself is not a problem. I wondered if it is specific to XMLDecoder but even then the constructor was not used by slf4j to expose it.. strange.