aegis4j
log4j-affected-db
| aegis4j | log4j-affected-db | |
|---|---|---|
| 8 | 30 | |
| 14 | 1,117 | |
| - | - | |
| 4.5 | 7.1 | |
| over 2 years ago | over 1 year ago | |
| Java | Shell | |
| Apache License 2.0 | Creative Commons Zero v1.0 Universal |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
aegis4j
-
What's new in Java 18 for us, developers ?
The guys at Oracle have made this point on this forum quite often, but it never really hit home for me personally until the recent log4j vulnerability made me more interested in the topic and the available mitigation options (see https://github.com/gredler/aegis4j/).
-
CVE-2021-44832: New Log4j 2 vulnerability
If you've been impacted by these log4j vulnerabilities, have a look at aegis4j, a Java agent that completely disables platform features you don't use, before an attacker uses them against you (including e.g. JNDI and Java serialization).
https://github.com/gredler/aegis4j/
- Aegis4j: Avoid the Next Log4Shell Vulnerability
-
Log4j MEGATHREAD
Yep, this is why strategically patching InitialContext when the class is initially loaded will completely disable JNDI (and mitigate future JNDI-based exploits).
- aegis4j: Avoid the NEXT Log4Shell vulnerability!
-
Log4j 2.15.0 – Previously suggested mitigations may not be enough
The recent log4j vulnerability really piqued my interest, and I've spent the last few evenings working on a proof of concept Java agent that could mitigate similar vulnerabilities in the future, for applications that are able to completely forego platform features like JNDI, serialization or native process execution.
Link to the project: https://github.com/gredler/aegis4j
It's not a lot of code, but it uses parts of the platform that I think are a bit unusual for most devs, so it was quite interesting to implement. Happy to discuss details, ideas, and concerns.
One idea for a possible improvement is to make the feature block list adaptive, i.e. watch what the application uses in the first few minutes of execution, and then shut down all unused "dangerous" features for the remaining lifetime of the VM. Not sure how reliable this would be though, especially for services which have background jobs that might only run once a day.
log4j-affected-db
- Patching log4j
- how to remidiate log4j with PDQ deploy
- looking for app that is vulnerable to log4j for testing
-
AMD slips by as Log4Shell exploit affects other top tech giants, such as Intel, Microsoft, and NVIDIA
Full known list https://github.com/cisagov/log4j-affected-db/blob/develop/SOFTWARE-LIST.md
- AV Log4j Vulnerabilities
-
Log4j vulnerabilities
Affected software is listed here https://github.com/cisagov/log4j-affected-db
- Cómo protegerse de la vulnerabilidad Log4Shell
- Impacto real de Log4j a nivel nacional ¿¿Algún experto que sepa bien qpdo??
- Anyone have a suggestion for something to install for a known VULNERABLE log4j test?
- A community sourced list of log4j-affected software
What are some alternatives?
Apache Log4j 2 - Apache Log4j 2 is a versatile, feature-rich, efficient logging API and backend for Java.
trivy - Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more
logstash-patterns-core
log4shell-vulnerable-app - Spring Boot web application vulnerable to Log4Shell (CVE-2021-44228).