EOL Log4J 1.2.x and CVE-2019-17571, CVE-2021-44228, CVE-2021-45046 about team-explorer-everywhere

[ForNeVeR]

There are two new critical severity CVEs that affect this old version of the library CVE-2021-44228 and CVE-2021-45046.

Are you sure about that? The CVEs themselves only mention log4j 2.

[dude0001]

I am not a security expert, so this is not advice. However, I looked again and I think you may be correct on CVE-2021-44228. It looks like it only affects v2 of the library and I misunderstood. I mentioned CVE-2021-45046 only to point out there is already another CVE in the first attempt to fix these issues and the very latest version is needed to fix all know in issues currently. Thank you for asking for clarification, I don't want to spread misinformation as this is already a difficult situation for lots of people.

The issue that the version of Log4J used in this repo is EOL and has a high severity CVE that is a couple years old now is still a big concern for us. With these new CVEs attackers will be scanning for this library, try to take advantage of the old CVE in new ways or look for other exploits in the old version. If and when they find more issues they would not be patched in the EOL version. The issue still stands. Is there any plans to update to a supported version of Log4J without these vulnerabilities? Are there suggested mitigation steps we can take until a patch is provided?

[ForNeVeR]

The issue that the version of Log4J used in this repo is EOL and has a high severity CVE that is a couple years old now

Yes, this is true. Though, the issue is only active is the presence of socket-based logging, which isn't used in TEE.

[cypherfunc]

Log4J 1.2.x is not vulnerable to CVE-2021-44228, but there is a corresponding issue CVE-2021-4104 (https://access.redhat.com/security/cve/CVE-2021-4104) which is specific to Log4j 1.x.

Note this flaw ONLY affects applications which are specifically configured to use JMSAppender, which is not the default, or when the attacker has write access to the Log4j configuration for adding JMSAppender to the attacker's JNDI LDAP endpoint.

Is TEE vulnerable to this?

[cypherfunc]

see microsoft/azure-devops-intellij#465 (comment)

[cypherfunc]

For anyone else looking into this, the answer is no, see microsoft/azure-devops-intellij#465 (comment)