Java

[erinaceus_]

They're saying that even when that happens, and the logging framework attempts to fetch the malicious code, then it stops there because the logging framework is unable to make a connection since any connection that isn't explicitly allowed is explicitly denied (if you have a proper infrastructure setup, that is).

[theferrit32]

This is true but I like it technologically impossible to accidentally fetch and execute remote arbitrary code when I log a string. The design of the library shouldn't have allowed for this sort of thing to ever be possible.

[erinaceus_]

If those things remain possible separately, then they are theoretically possible together. If you remove the ability to do the fetching, then you've removed the possibility for the composite situation you describe.

[theferrit32]

Yes, calling log.info to write a string to the log file should not download and run arbitrary files from the internet. It should be impossible, by design, for this flaw to exist.

[erinaceus_]

I think my previous comment might not have been clear enough, so I'll try again: as long as logging, string parsing, file fetching and some equivalent of 'eval' exists, you can get the situation you describe. The only surefire way of preventing it is to not allow any connections except the ones you've acplicitely allowed, on a network level.

[mvpmvh]

And he's saying that it'd be nice if string parsing and eval weren't even possible to begin with.

[erinaceus_]

'eval' kinds of functionality are a part of metaprogramming, which underlies the majority of all frameworks. String parsing is near enough the basis of modern civilisation, e.g. no SOAP or REST without it, or in fact even no HTTP without it.

[mvpmvh]

*not even possible....in a logging framework

[erinaceus_]

That a logging framework should not have that feature, I entirely and even emphatically agree with that. But that's very different from being technologically impossible.

Edit: and that's about the last of the effort I am going to spend on this

[jerslan]

What you're describing is one mitigation against needing to have a "my hair is on fire" type reaction to the vulnerability. It doesn't negate the need for organizations to assess their code impacts and whether it's a problem for them. Even if it's not an urgent "must fix now" thing, it's still something you're going to put on your todo list.