The log4j exploit made big news these days. What I am missing is how to test my own (amateur) servers for the exploit and how to fix any problems.
My systems do an automatic nightly update of their packages via an apt cronjob. Is this enough? Do I need to do more? Looking forward to Steve’s show today!
Check out the blogs and security bulletins of the products you use.
VMware and Ubiquiti Unifi as affected, for example. Just been through and upgraded my Unifi controller.
I’m just going through the official release from BSI.
Edit: The other thing is, if those services are internal, then you are not at immediate risk, only if they are externally accessible.
Our ERP solution, for example, uses Log4j and will be getting an update this week, but it doesn’t use Log4j Core, so shouldn’t be vulnerable, it isn’t accessible outside the company network and it isn’t accessible over http.
Even more specifically, you’re only at risk if the program (whatever program that uses logging via the version 2 of log4j (known as log4j2)), writes to logs, without appropriate sanitizing, input that it received from the user (or that was under the user control, such as HTTP headers.) Basically it is NEVER safe to process input from outside your program without considering it malicious and filtering it accordingly. Those that don’t sanitize their inputs are doomed to hell… this is just a current example because log4j is otherwise so useful that it is widely used.
While true, the problem is, unless you have written the software yourself, you don’t know whether it has been written properly or not, so you have to assume that it has does not properly sanitize the inputs.
I was following a cyber security thread on Twitter yesterday. One of the researchers managed to get himself in on the chat discussing the development of an exploit to take advantage of this hole. It will:
That’s kind of the problem - “the products I use” is less transparent to me than I would have hoped. Distributions are what distributions are, big piles of software rolled into an ISO, and given that logging is such a basic and ubiquitous activity of just about every single one of those pieces of software, I am really not sure what uses log4j and how bugged their implementation is.
On my pretty fresh Manjaro install, I have about 400 packages (pre-)installed. There is hardly any way for me to tell which has its issues and which does not.
I suppose I shall simply keep my updating game on and cross my fingers that the developers do their thing. I’d love to use a self-testing utility to see if my system(s) are susceptible to the issue…
Yes, but most of those packages (Linux distribution) are not written in Java.
Log4j is a Java class (the “J”). So you only need to identify Java applications that you have installed (server services with external access ports).
Theoretically, OpenOffice/LibreOffice could be affected, but it is unlikely and the attacker would need to send you a specially crafted document to take advantage of it, if they even use Log4j.
There are some scanners, such as this Python script on GitHub:
Well, that is part of the problem with these exploits as everyone involved knows they don’t write insecure code.
It’s like proofreading your own paper, you never spot the errors since you know what you meant to write, so you must have written it that way.