As it is hard to tell what needs to be done regarding the JNDI vulnerability, instead of issuing multiple security patches, removing the tainted component (JNDI calls) immediately and building from there at our own pace seemed like the safer strategy.
Which JNDI vulnerability? The sample doesn't identify one in Logback, as far as I can tell. The sample itself is the RCE vulnerability by accepting arbitrary file uploads into dangerous locations. There is no way that Logback can protect against someone having full access to the JVM anyway. I agree with @michael-o that this is not a Logback issue and therefore, no action is required as of right now. Some more sanity checks and more restrictive defaults in the future are probably a good idea either way, but breaking existing use-cases without a vulnerability even having been demonstrated seems premature. |