33

I have recently read about the zero-day issue in Log4J. I work with a few applications, written with .NET, that use the log4net logging library, which is based on Log4j.

Does log4net have any similar security vulnerabilities as the CVE-2021-44228 vulnerability to Log4j?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
FooAnon
  • 566
  • 1
  • 4
  • 11

5 Answers5

15

Vulnerability Details: CVE-2021-44228 (CVE Details) and CVE-2021-44228 (CVE) have the following note:

Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.

So, no. Log4Net is fine.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
David
  • 4,665
  • 4
  • 34
  • 60
4

Apparently it has to use JNDI and JVM. Ports are clear if they don't use those.

Does CVE-2021-44228 impact Log4j ports?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
heimzza
  • 276
  • 4
  • 12
3

No, it is specific to Log4j-core. Please see CVE-2021-44228 Detail (NIST).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
lexma
  • 409
  • 5
  • 14
1

Long ago I was programming C++ when I found out that the C++ package I was using to access the database was just a wrapper for Java code.

The fact that the security bug exists in a Java-only core part of Log4j doesn't mean that Log4Net is bug-free and safe. It might just as well have other security issues.

In fact, any piece of software can have vulnerabilities and probably has them too. It isn't just a problem with Log4j or Log4net but a problem with any package we quickly accept and put our trust in.

D S
  • 258
  • 9
  • 25
Martien van der Gaag
  • 19
  • 2
  • Any thoughts on how to avoid pulling in a vulnerable package? With the number of them in use, reviewing them all seems overwhelming. – Merkle Groot Dec 21 '21 at 14:15
  • 1
    A very good question but hard to answer. Depending on the size of the company you could get pentesters try to find vulnerabilities. They might be more efficient in finding vulnerabilities and more aware of existing vulnerabilities in the packages.Another way is to raise awareness among the devs on site how you can plug vulnerabilities, This will also help you find them quicker. – Martien van der Gaag Dec 21 '21 at 17:48
  • 1
    @MerkleGroot But also, put 3rd party library code behind a simple abstraction (simple as in: designed to only give you a couple of things that you decided are crucial), and use dependency inversion so that you can easily pluck the library out if you need to. – Filip Milovanović Dec 23 '21 at 03:04
  • 1
    As a general remark, I agree that we should question everything with respect to third-party software security vulnerabilities. However, my question was in specific regards to CVE-2021-44228. – FooAnon Dec 29 '21 at 15:44
0

Does log4net have any similar security vulnerabilities as the CVE-2021-44228 vulnerability to Log4j?

I don't believe so. If they did, it would be a coincidence. I don't think they share code.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Jeff Scott Brown
  • 26,804
  • 2
  • 30
  • 47