Our great sponsors
-
mariadb-connector-j
MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. MariaDB Connector/J is LGPL licensed.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
syft
CLI tool and library for generating a Software Bill of Materials from container images and filesystems
-
Apache Log4j 2
Apache Log4j 2 is a versatile, feature-rich, efficient logging API and backend for Java.
-
lunasec
LunaSec - Dependency Security Scanner that automatically notifies you about vulnerabilities like Log4Shell or node-ipc in your Pull Requests and Builds. Protect yourself in 30 seconds with the LunaTrace GitHub App: https://github.com/marketplace/lunatrace-by-lunasec/
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
This shows that the MariaDB JDBC driver uses Logback as a logging framework. Although Logback is not affected by Log4Shell, it has a related vulnerability (of much lesser severity, no need to panic) fixed in version 1.2.8 and 1.3.0-alpha11. I checked the version used by the connector and found that it used 1.3.0-alpha10. Even though Logback is included as a test dependency in the MariaDB driver, I sent a pull request on GitHub to update it. I encourage you to do the same in any open-source project you find and that includes a vulnerable dependency.
I tried this with the JDBC connector project for the MariaDB database and got the following:
In more complex projects with a large number of JAR files, you can use tools such as Syft and Grype. Syft is a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems. It can be used with Grype which scans container images and filesystems for vulnerabilities through multiple levels of nesting.
The Log4j vulnerability tracked as CVE-2021-44228 (also known as Log4Shell) allows an attacker to execute arbitrary code in a system. If your application uses Log4j from version 2.0-alpha1 to 2.14.1, you should update to the latest version (2.16.0 at the time of writing this) as soon as possible.
In more complex projects with a large number of JAR files, you can use tools such as Syft and Grype. Syft is a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems. It can be used with Grype which scans container images and filesystems for vulnerabilities through multiple levels of nesting.
This shows that the MariaDB JDBC driver uses Logback as a logging framework. Although Logback is not affected by Log4Shell, it has a related vulnerability (of much lesser severity, no need to panic) fixed in version 1.2.8 and 1.3.0-alpha11. I checked the version used by the connector and found that it used 1.3.0-alpha10. Even though Logback is included as a test dependency in the MariaDB driver, I sent a pull request on GitHub to update it. I encourage you to do the same in any open-source project you find and that includes a vulnerable dependency.
The folks at LunaSec (an open-source data security platform) developed an open-source tool to scan directories and find files that have a matching hash to vulnerable Log4j dependencies. The tool is available for Windows, Linux, and macOS systems. All you have to do is run the tool passing the directory to scan. For example:
The team at FullHunt provided an open-source tool called log4j-scan, an automated and extensive scanner for finding vulnerable Log4j hosts. It allows teams to scan their infrastructure but also test for WAF (Web Application Firewall) bypasses that can result in code execution. The tool has several options but in short, you pass to the tool the URL to scan and you get a report on the vulnerabilities found. For example:
Related posts
- General Docker Troubleshooting, Best Practices & Where to Go From Here
- Open source container scanning tool to find vulnerabilities and suggest best practice improvements?
- Free tool for generating SBOM and CVEs against source or binaries
- Container scanners not scan software not added by package manager
- Log4J – A 10 step mitigation plan