4 ms·

Java is unique as the culture encourages doing magic convention over configuration by reflection AND it-just-works serialization, which leads to a new bug class

by rfoo 4y ago

Java is unique as the culture encourages doing magic convention over configuration by reflection AND it-just-works serialization, which leads to a new bug class: unsafe deserialization except that the deserialization happens in the library by default (e.g. fastjson, jackson, tons of struts2 bugs, etc) and propagates along the supply chain. Libraries refuse to shift away from this culture thing, and decided to just blacklist the known exploit path while keeping the vulnerability intact. It's not that they do this for backward-compatibility, it's new libraries still being designed this way. The log4j 2 bug is slightly different, but IMO as a design issue it has root in the same culture thing described above.

josefx 4y ago
> Libraries refuse to shift away from this culture thing, and decided to just blacklist the known exploit path while keeping the vulnerability intact. Log4j 2 refused to shift away from it since they are paid to add that kind of bloat, yes this wasn't an accident caused by a bad culture, this was a feature someone requested. As far as I understood they are completely separate from the original log4j and it is just another, mostly compatible logging implementation. > Java is unique as the culture encourages doing magic convention over configuration by reflection AND it-just-works serialization As opposed to what? Python? The language that culturally refuses to fix the GIL and as workaround provides multiprocessing, which requires that everything is serialized? Also I may not have seen many Python code bases, but from what I have seen ClassLoader/Import abuse is alive in both languages.
- peteradio 4y ago
  Python developers aren't smart enough to develop threaded code. Making threading work in python would be like giving crack to an infant. Python maintainers made the right choice to coddle their user base, you see if you have to be smart to use python then you wouldn't be using python to begin with and user base goes to zero. I kid I kid. Happy New Years - a python developer
- rfoo 4y ago
  I agree that the GIL situation is unfortunate. Python at least does not pretend their it-just-works serialization is secure. The documentation [1] actively discourages deserializing untrusted data and suggests to use pure data format (e.g. JSON) as possible. In contrast, the documentation on ObjectInputStream before Java 11 does not warn about this at all. Even then [2], it suggests to implement blacklist/whitelist filters, and it is pretty hard to get right. The same filtering can also be done for pickle, but the usual consensus in Python developers seems to be "don't do this even if it's possible". > but from what I have seen ClassLoader/Import abuse is alive in both languages. Yeah, should have said that my rant is mainly against endless deserialization/OGNL injection/whatever-popular-expression-language injection bugs in frameworks, not abusing ClassLoader. These features, just like log4j2's code-execution-disguised-as-string-interpolation feature [3], shouldn't exist. [1] https://docs.python.org/3/library/pickle.html https://docs.python.org/3/library/pickle.html [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/ObjectInputStream.html https://docs.oracle.com/en/java/javase/11/docs/api/java.base... [3] I'd argue that's the real bug, instead of the obvious JNDI class loader blah blah stuff. Luckily log4j didn't refuse to fix it and completely removed "message lookup".

by rfoo 4y ago

josefx 4y ago

> Libraries refuse to shift away from this culture thing, and decided to just blacklist the known exploit path while keeping the vulnerability intact. Log4j 2 refused to shift away from it since they are paid to add that kind of bloat, yes this wasn't an accident caused by a bad culture, this was a feature someone requested. As far as I understood they are completely separate from the original log4j and it is just another, mostly compatible logging implementation. > Java is unique as the culture encourages doing magic convention over configuration by reflection AND it-just-works serialization As opposed to what? Python? The language that culturally refuses to fix the GIL and as workaround provides multiprocessing, which requires that everything is serialized? Also I may not have seen many Python code bases, but from what I have seen ClassLoader/Import abuse is alive in both languages.

peteradio 4y ago
Python developers aren't smart enough to develop threaded code. Making threading work in python would be like giving crack to an infant. Python maintainers made the right choice to coddle their user base, you see if you have to be smart to use python then you wouldn't be using python to begin with and user base goes to zero. I kid I kid. Happy New Years - a python developer
rfoo 4y ago
I agree that the GIL situation is unfortunate. Python at least does not pretend their it-just-works serialization is secure. The documentation [1] actively discourages deserializing untrusted data and suggests to use pure data format (e.g. JSON) as possible. In contrast, the documentation on ObjectInputStream before Java 11 does not warn about this at all. Even then [2], it suggests to implement blacklist/whitelist filters, and it is pretty hard to get right. The same filtering can also be done for pickle, but the usual consensus in Python developers seems to be "don't do this even if it's possible". > but from what I have seen ClassLoader/Import abuse is alive in both languages. Yeah, should have said that my rant is mainly against endless deserialization/OGNL injection/whatever-popular-expression-language injection bugs in frameworks, not abusing ClassLoader. These features, just like log4j2's code-execution-disguised-as-string-interpolation feature [3], shouldn't exist. [1] https://docs.python.org/3/library/pickle.html https://docs.python.org/3/library/pickle.html [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/ObjectInputStream.html https://docs.oracle.com/en/java/javase/11/docs/api/java.base... [3] I'd argue that's the real bug, instead of the obvious JNDI class loader blah blah stuff. Luckily log4j didn't refuse to fix it and completely removed "message lookup".