> Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc.
They've been doing a poor job of communicating. Considering the attention this issue is getting, they should have a prominent notice on their project page[0] about it like the one Logback[1] has telling people that they are not affected.
Furthermore, even their post about the issue[2] still fails to clarify many details like
* are people using newer JDK versions safe, like one commenter in this very thread assumed[3] ?
* does it only affect the format string and not parameters as many [falsely] claimed when the news started making the rounds ?
* what should people trying to block exploitation on a firewall level look for ?
> for a feature we all dislike yet needed to keep due to backward compatibility concerns.
They have not recognized the security risk posed by what is effectively an expression language interacting with user-submitted data. Java projects used in server-side templating like OGNL, JSP and JSF implementations, Spring keep having security vulnerabilities with this even after 20+ years. It is an effectively impossible task to get this 100% secure.
The ridicule Log4j is getting serves a purpose beyond fun: it lets people know that the project's maintainers are not up to the task and another logging library should be used instead, as there might be more issue still undiscovered or added in the future.
- Newer version of JDK kind of mitigate the issue by disallowing by default the vector used to get the untrusted code.
- Parameters are affected as well as it seems that there is some form of recursive string interpolation going on.
- Packet inspection would lookup for the string interpolation for jndi lookup in the client message "${jndi:" which in most case should have no reason in being in client trafic (if not compressed).
Again the risk is real when the server use un-sanitized client data.
They've been doing a poor job of communicating. Considering the attention this issue is getting, they should have a prominent notice on their project page[0] about it like the one Logback[1] has telling people that they are not affected.
Furthermore, even their post about the issue[2] still fails to clarify many details like
* are people using newer JDK versions safe, like one commenter in this very thread assumed[3] ?
* does it only affect the format string and not parameters as many [falsely] claimed when the news started making the rounds ?
* what should people trying to block exploitation on a firewall level look for ?
> for a feature we all dislike yet needed to keep due to backward compatibility concerns.
They have not recognized the security risk posed by what is effectively an expression language interacting with user-submitted data. Java projects used in server-side templating like OGNL, JSP and JSF implementations, Spring keep having security vulnerabilities with this even after 20+ years. It is an effectively impossible task to get this 100% secure.
The ridicule Log4j is getting serves a purpose beyond fun: it lets people know that the project's maintainers are not up to the task and another logging library should be used instead, as there might be more issue still undiscovered or added in the future.
[0] https://archive.ph/ZhjWO
[1] https://archive.fo/QkzIy
[2] https://archive.fo/NvjKP
[3] https://archive.fo/5cNtw