31–40 of 158 posts
Except the vulnerability was a stack up. The logger wasn't making network calls per se, but passing requests to a component (JNDI) that would obviously need network access. You'd have the same root issue, it'd just manifest more as sort of a confused deputy with a capability based model.
Personally I wonder whether anyone actually used log4j willingly or just because its generally used by all the apache projects and they wont start without it. With a healthy dose of "use the latest versions" mentality. I checked back and all my java code was still running log4j 1.1, and removing it has been on the todo list ever since it needed linking. You should be checking all your 3rd party source code, "capabili…
Any project written in Java that has ANY dependencies will also use Log4j. Not even your choice anymore unless you are willing to write your entire stack from scratch.
The moment you start thinking about how to solve logging you will land at a log4j-like framework anyway.
> You should be checking all your 3rd party source code
How is that a usable advice? There are dozens of dependencies in a simplest application. A non-trivial may easily have above hundred dependencies.
Personally I wonder whether anyone actually used log4j willingly or just because its generally used by all the apache projects and they wont start without it. With a healthy dose of "use the latest versions" mentality. I checked back and all my java code was still running log4j 1.1, and removing it has been on the todo list ever since it needed linking. You should be checking all your 3rd party source code, "capabili…
You can still have all outgoing traffic be sent through a proxy that denies any target that is not explicitly on the allowlist.
Does this interact with or preclude operating system level capabilities?
OS-level ones call the shots, but maintaining the same discipline within a process is a good way to write better code, (especially better libraries).
Earlier quoted context omitted.
It still passes. Because JNDI would require network access, so log4j would also have to require network access or "disable" the network capability.
Practically (and like is being suggested here in other comments), JNDI would probably be a separate component (maybe a separate process) with network access, and log4j would just send those user provided strings over an IPC channel, and you'd be in exactly the same place at the end of the day.
1) It's pretty dang explicit to the programmer that they're granting the logger network access, because they're the ones writing that logic.
2) Even if you've granted the logger network access, you probably haven't granted it complete access to your filesystem. Network access isn't the only sensitive thing on your system, and a logging library needs very little authority to operate (specific files/directories and its own config?). Getting code execution in the logger shouldn't be game over security-wise, because it shouldn't have that much authority to begin with.
Why should a programming language be limiting network access? Why wouldn't we do this via the operating system?
It might be useful that some code in a single process have access while other parts do not. How would you propose an OS handle those cases?
You can imagine doing something like adding some bytecode instructions that if encountered by the JVM block the network access to every other request done in the call stack after that instruction. Something that reduces efficiency drastically and still can easily be circumvented if you don't implement different address spaces for different parts of the code (something that only the OS can do).
Personally I wonder whether anyone actually used log4j willingly or just because its generally used by all the apache projects and they wont start without it. With a healthy dose of "use the latest versions" mentality. I checked back and all my java code was still running log4j 1.1, and removing it has been on the todo list ever since it needed linking. You should be checking all your 3rd party source code, "capabili…
> Personally I wonder whether anyone actually used log4j willingly Any project written in Java that has ANY dependencies will also use Log4j. Not even your choice anymore unless you are willing to write your entire stack from scratch. The moment you start thinking about how to solve logging you will land at a log4j-like framework anyway. > You should be checking all your 3rd party source code How is that a usable adv…
Why should a programming language be limiting network access? Why wouldn't we do this via the operating system?
If your language is capable of expressing "this part of the code can't access the network", in a general way such that networking is not some special snowflake that's baked in, then you've created an effects system which is likely to be useful in many, many other contexts for other things you want to assert without having them supported in the OS. (For example, "is this code async", or "does this code print anything"…
This is a big deal, because many security practices are neutral or bad for programmer productivity.
We need a big project to get CloudABI implemented in all the major kernels to make the theory reality. Whereas before it was unclear what was a good candidate to get this stuff in prod, now it is very clear that socket-activated services are an idea use-case, with very little migration pain.
Even if you think we should be going to Fuschia or SEl4 or whatever, I think this is a good stepping stone. Those projects are a big jump alone, and funding is uncertain. (Plus there are issues of single-company dominance with Fuchsia.) I think CloudABI is the sort of "non-reformist reform" not "worse is better" stepping stone that would help those projects not hurt them.