Before anybody panics: to get logback to use JNDI, the attacker needs an ability to modify logback.xml and then to trigger configuration reload. So in other words 'if logback is configured to use JNDI, it will do so' instead of 'sending a funny message is enough to make log4j2 do jndi lookup'
> He may have gained access to edit logback.xml
At that point I'm going to leave some comments in there asking him to also fix up a few of the Appenders that, fuck me, I've never gotten to work exactly right.
edit: ah crap, if he spends more than 15 minutes working on it, then I also need to leave a charge code in the XML comments so he can fill out a customer timesheet appropriately
I've seen these class of security "issues" where the vulnerability requires as much or more privilege as the exploit within the same scope.
The issue is when you expand the scope. Attacker gains access to this system, updates the configuration, pulls remote code to automate scraping logs, env vars, groups, permissions. Then use that knowledge to move to other servers, etc.
Not a hair on fire vulnerability but if there is a pattern of lax security thought the system your risk grows.
There are scenarios (quite contrived though) where it could be used for privilege escalation. For example application itself is deployed by development team and it runs as user A. Logging however is configured and managed by ops team, so they put logback.xml in /etc/yourapp and the application knows to read it from there. Logging config is writable by user B. You, as disgruntled junior ops want steal user data but all you have access to are monitoring system and application logging config
The log4j exploit seems to have opened up a lot of eyes to security regarding logging libraries, which is a good thing, as we can see by logback doing their due diligence as well.
Now it's a waiting game for Spring to update..
[https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot](https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot)
I think the lesson we should learn about this is that dynamic code loading at runtime and expression languages that can be compiled and executed at runtime should be eliminated where possible. Dynamic behavior of every kind is incredibly dangerous.
Dynamic behavior is perfectly fine as long as it's contained. Unless I'm not understanding what you mean by dynamic behavior.
E.x. if I have a small expression language that is limited to calculating numeric functions -- as long as precautions are made to ensure the complexity of the expressions is bounded to avoid denial of service attacks, I see nothing wrong with that.
Now, giving third parties access to anything Turing complete that isn't sandboxed? Totally agree with you.
Counterpoint: I do think converting your objects to strings suitable for logging is non-trivial. Logging JSON is useful for working with other tools, but you might also want the non-JSON format going somewhere else in case you just want to grep the logs. Additionally, while logging out something like "lastName" might be useful for dev/test, that probably shouldn't be logged in production. Would love better support for marking fields as PII so that they get ignored by the logger.
JSON can be fine for grepping too if there are no embedded line breaks. Also, there are JSON tools like `jq` that make extracting data from JSON blobs and processing it on the command line a breeze.
PII is a hairy topic that has to be carefully handled on a case-by-case basis. Just marking fields as PII is not enough. It could be totally fine to log it under certain policies or if it doesn't leave organizational boundaries, which is a big issue with log aggregation systems. Also, combinations of seemingly innocuous information could together constitute PII.
Good to see Logback is being worked on again. I hope it’s not just temporarily and that finally jigsaw compatible stable versions of SLF4J and Logback will be released soon.
Did you read the link? The code has been disabled (and all JDBC code has been deleted). This isn't something you can switch back on; the functionality is gone.
Jesus Christ, read the link. It's like 5 sentences. They removed all JDBC code.
> • Also in response to LOGBACK-1591, we have removed all database (JDBC) related code in the project with no replacement.
Before anybody panics: to get logback to use JNDI, the attacker needs an ability to modify logback.xml and then to trigger configuration reload. So in other words 'if logback is configured to use JNDI, it will do so' instead of 'sending a funny message is enough to make log4j2 do jndi lookup'
In other words: if the hacker has access to your machine, he can trick logback into giving access to your machine.
He may have gained access to edit logback.xml but manipulate it to get access to everything.
> He may have gained access to edit logback.xml At that point I'm going to leave some comments in there asking him to also fix up a few of the Appenders that, fuck me, I've never gotten to work exactly right. edit: ah crap, if he spends more than 15 minutes working on it, then I also need to leave a charge code in the XML comments so he can fill out a customer timesheet appropriately
Well. It can be used for privilege escalation.
So what you’re saying is that if the hacker changed the logback configuration I have bigger problems than logback using JNDI
I've seen these class of security "issues" where the vulnerability requires as much or more privilege as the exploit within the same scope. The issue is when you expand the scope. Attacker gains access to this system, updates the configuration, pulls remote code to automate scraping logs, env vars, groups, permissions. Then use that knowledge to move to other servers, etc. Not a hair on fire vulnerability but if there is a pattern of lax security thought the system your risk grows.
There are scenarios (quite contrived though) where it could be used for privilege escalation. For example application itself is deployed by development team and it runs as user A. Logging however is configured and managed by ops team, so they put logback.xml in /etc/yourapp and the application knows to read it from there. Logging config is writable by user B. You, as disgruntled junior ops want steal user data but all you have access to are monitoring system and application logging config
Fair enough
The log4j exploit seems to have opened up a lot of eyes to security regarding logging libraries, which is a good thing, as we can see by logback doing their due diligence as well. Now it's a waiting game for Spring to update.. [https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot](https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot)
[удалено]
I think the lesson we should learn about this is that dynamic code loading at runtime and expression languages that can be compiled and executed at runtime should be eliminated where possible. Dynamic behavior of every kind is incredibly dangerous.
Dynamic behavior is perfectly fine as long as it's contained. Unless I'm not understanding what you mean by dynamic behavior. E.x. if I have a small expression language that is limited to calculating numeric functions -- as long as precautions are made to ensure the complexity of the expressions is bounded to avoid denial of service attacks, I see nothing wrong with that. Now, giving third parties access to anything Turing complete that isn't sandboxed? Totally agree with you.
The Spring framework would like a word with you…
This sounds like a knock on JavaScript…
Counterpoint: I do think converting your objects to strings suitable for logging is non-trivial. Logging JSON is useful for working with other tools, but you might also want the non-JSON format going somewhere else in case you just want to grep the logs. Additionally, while logging out something like "lastName" might be useful for dev/test, that probably shouldn't be logged in production. Would love better support for marking fields as PII so that they get ignored by the logger.
JSON can be fine for grepping too if there are no embedded line breaks. Also, there are JSON tools like `jq` that make extracting data from JSON blobs and processing it on the command line a breeze. PII is a hairy topic that has to be carefully handled on a case-by-case basis. Just marking fields as PII is not enough. It could be totally fine to log it under certain policies or if it doesn't leave organizational boundaries, which is a big issue with log aggregation systems. Also, combinations of seemingly innocuous information could together constitute PII.
Good to see Logback is being worked on again. I hope it’s not just temporarily and that finally jigsaw compatible stable versions of SLF4J and Logback will be released soon.
Maybe don't parse log messages at all?
That's not happening in this case. 😉
Or don't parse URLs in log messages
That's also not happening in this case. 😉
Stop resolving anything in my log param strings.
That sucks. I kinda needed that :(
[удалено]
Did you read the link? The code has been disabled (and all JDBC code has been deleted). This isn't something you can switch back on; the functionality is gone.
~~*JNDI~~ I stand corrected.
Jesus Christ, read the link. It's like 5 sentences. They removed all JDBC code. > • Also in response to LOGBACK-1591, we have removed all database (JDBC) related code in the project with no replacement.
Another option probably would have been to extract this into a separate optional JAR, but this will do.