This forum has been archived. All content is frozen. Please use KDE Discuss instead.

log4j vulnerability fix

Tags: None
(comma "," separated)
User avatar
st8t2dyssyd3nt
Registered Member
Posts
9
Karma
0

log4j vulnerability fix  Topic is solved

Sat Dec 18, 2021 2:46 pm
the fix is from CVE . . . for the CVE-2021-44228 and CVE-2021-45046. Update will not allow the upgrade to liblog4j2-java from 2.15 to 2.16 from https://logging.apache.org/log4j/2.x/. It has to be applied manually:

apt --only-upgrade install liblog4j2-java ;
and verify it is v2.16 in synaptic by searching liblog4j2-java or log4j.

Image

Image

It is a java attack. and widevine, sql, etc, all services use some form of java or directly copied and rewritten version of java, from Oracle, to copy it. It was LDAP attack, with a script, affecting java with JNDI and Msg lookups to access information. It arose from the attacks on Amazon AWS cloud storage through a facebook dns server. The need was for a "no" msg lookup feature to be set = true and jndi to be set as manually enabled. it is recommended to move to version 2.16. You do want to also prolly manually update the engine from source.

***The update is approved and maintained by the ubuntu universe repository****

Last edited by st8t2dyssyd3nt on Sat Dec 18, 2021 3:22 pm, edited 1 time in total.
User avatar
st8t2dyssyd3nt
Registered Member
Posts
9
Karma
0

Re: log4j vulnerability fix

Sat Dec 18, 2021 3:18 pm
Uninstalling java does not protect you. Web servers all around the world use some form of java or a replicated program that is still vulnerable to LDAP and DNS. And, I have concerns about the default enabling of JNDI lookups. I wish there was a way to have it enabled by default and merely delete certificates for trust authority. I did remove the amazon root certificates. I want nothing to do with Amazon or Facebook DNS servers. They are not a part of regular high tier internet resources. They are discounted new charter portions. And, so are voluntary contributor platforms. It is awful. The contributor platforms are great resources in an amass of lower grade; or, up to say $2.5 billion net smaller businesses, that are overrun with attackers. I had it working with just manually updating the engine from source code to 3.8.x which was not available in the universe repository last Tuesday in the early morning when the first CVE attack fix was released. An immediate second for the JNDI problem, was a terrible amount of work for resources that were not available. By removing those certificates, I had no problems with card lookups. I do not want SSL approval for Amazon certificates at all. I do not want SSL or SSH connections for Amazon. I refuse to use Amazon. There is no telling what is going to arrive next because of that.

Image
User avatar
st8t2dyssyd3nt
Registered Member
Posts
9
Karma
0

Re: log4j vulnerability fix

Sat Dec 18, 2021 3:29 pm
-A.K.A. no sockets to Amazon, plz?!!!
User avatar
st8t2dyssyd3nt
Registered Member
Posts
9
Karma
0

Re: log4j vulnerability fix

Sat Dec 18, 2021 3:45 pm
So, now we only need to compile liblog4j-java version 2.17 for top layer lookups from source. ^-^
User avatar
st8t2dyssyd3nt
Registered Member
Posts
9
Karma
0

Re: log4j vulnerability fix

Sat Dec 18, 2021 4:44 pm
1. https://logging.apache.org/log4j/2.x/

2. https://9to5mac.com/2021/12/14/apple-pa ... erability/

3. https://www.microsoft.com/security/blog ... loitation/

- " CVE-2021-45046"

Apple was the first to protect iCloud. That was said. However, what was said was never backed by a lab with proven evidence. Apache, Houston, TX, released the fix for on Tuesday, December 14th, 2021 at 0200 Mountain time, U.S. Or, 2:00 A.M. The problem fixed CVE-2021-44228 and the next vulnerability arose: CVE-2021-45046. Now, within a week, the need for a top layer lookup entry is pssibly finalized concerning CVE-2021-45105; and, log4j v2.17.

Sadly Microsoft is still on CVE-2021-44228 with no fixes for the newer two, insisting it does not use Java. It uses a replica of Java, that works with Java. It is vulnerable to Java, and all of their info was released days later; or, not at all.

CISA (https://www.cisa.gov/uscert/apache-log4 ... y-guidance) is stuck on version 2.16. Apache has already released 2.17 as finalized limiting only top layer lookups for name and resource inquiries.
User avatar
st8t2dyssyd3nt
Registered Member
Posts
9
Karma
0

Re: log4j vulnerability fix

Sat Dec 18, 2021 4:56 pm
The keys contain multiple public keys with several good signatures. They are not entirely trusted, but monitored by Apache. So, the hash needs to match after the download

"gpg --print-md SHA512 apache-log4j-2.17.0-bin.tar.gz"

output matches hash from "https://downloads.apache.org/logging/log4j/2.17.0/apache-log4j-2.17.0-bin.tar.gz.sha512"

Image

I am on a Testing lab with no Personally Identifiable Information. I am on a VPN. It does not matter any way. ;) Be it that I have a matching Hash, have extracted and retained the RSA key, and have the full output text of the imported keys, I have the identities of all participators. Apache does this to monitor changes. So, it is safe. It is safer than any other technique. Oracle and Apache are my favs. I take it vry seriously if you bother them. <3.

I have gotten to the point to where I have manually compiled log4j with a backup of version 2.16. I am going to build it into the OS and see what happens. This is because I want version 2.17 and it is not available from the universe repository yet. I am in contact with them. brb.
User avatar
st8t2dyssyd3nt
Registered Member
Posts
9
Karma
0

Re: log4j vulnerability fix

Sat Dec 18, 2021 6:37 pm
It works only in one session. The upgrade feature insists upon overwriting it. However, the file searches yielded it was that version 2.17 was deployed in the /etc, /usr/share, etc bin locations. We need this update asap. I contacted the universal repository admins. And, requested it. It takes a long time to compile from source, and 3-3.5 minutes to implement each time. I have a workbook on the server and an additional employee to call me so I may be woken from home to remotely log in to keep the server running between upates. Blah!!
User avatar
st8t2dyssyd3nt
Registered Member
Posts
9
Karma
0

Re: log4j vulnerability fix

Sat Dec 18, 2021 6:46 pm
I can make new connections require 2.17, but that is all. This is terrible. Reading the lawful requirements for Apache 2 is even more alarming. The standards required by law for encryption concerning exporting and importing is entirely unlawful. My honest, professional opinion, is that the governments of the world are preventing the patch for 2.17 with lawlessness concerning requirements for monitoring online activity with similar scans. So export the requirements for class requiring all versions of servers to have these scans disabled for CVE-2021-45105 and lock its config to require the changes, and protection against prior threats. I have system speed improvements, as well, and graphical enhancements. Performance enhancements. I wish they would start to deny harmful servers from getting the patches. But, that is lawlessness. Sheesh. I wish Apache could maintain there own upgrades through all platforms with a storage and configuration barrier between them having minimal delay relative to the server push update process with backups. I require an agreement for certain types of info to be provided and the script from another app that is not Java, collects it, allows it, and deletes the app script once it has it. That, too, in other instances will be terrible.
User avatar
st8t2dyssyd3nt
Registered Member
Posts
9
Karma
0

Re: log4j vulnerability fix

Wed Dec 22, 2021 3:20 pm
**** the 2.17 patch is ready and can be downloaded here: http://archive.ubuntu.com/ubuntu/pool/u ... .1_all.deb

It is still in the universe repository, yet fixes the vulnerability with CVE-2021-45105

This is the best solution as of yet. It will block the final recursive scanning as well as the other two vulnerabilities: CVE-2021-45046 & CVE-2021-44228. install with something like gdebi package installer or synaptic, etc . . . :)

Image


Bookmarks



Who is online

Registered users: bartoloni, Bing [Bot], Google [Bot], Sogou [Bot], Yahoo [Bot]