I just received an email from my tech department that the Arduino suite has fallen victim to the Log4J security flaw.
The truth is a bit muddier than that (isn’t it always?) and you can read more about that here.
I have been wondering if we should be concerned about any of the other Robotics suite software we use specifically for FIRST. We are running WPILib 2019-2022 on our machines due to some older robots and newer bots that are using the VMX-Pis.
I guess this also calls into question how teams handle security.
Are your machines accessible to the outside world? WPILib is not an “active” component for development. It is not running log4j although it might use it on your robot. I don’t believe VSCode uses log4j. In general your IDE would not have ports open anyway (or shouldn’t). As in the Arduino IDE case, you would have to load in some source code from an untrusted source to even have a chance to exploit this vulnerability.
So in general it should be of little concern to teams, at least as far as robotics software goes.
GradleRIO did (until just a few days ago) use log4j for some logging. However, it was only used for logging information from the internal implementation when logging during deployment to the robot. The security flaw in log4j is really only a concern when an external person has control over the log message content (so primarily servers).
Thank you both for your answers. That does help some.
I guess I do not really understand this security hole. Are our computers air-gapped, no. Are they connected 24/7? also, no. So, I assume there is a nonzero risk, but they are not as vulnerable as tech feels they are.
We do allow all of our computers to connect to the Internet to keep updates going, look through codebase tutorials, access github, etc.
I also wonder about the fragmentation, which, while totally understandable, does make keeping software up-to-date difficult for us (It is not just WPILib we have installed, but all the various vendor libraries and tuners).
As a teacher who attempts to work closely with the tech department, I feel I am frequently stuck in the middle. I always push for accessibility (let’s make CS easy to access for the students), they of course, always push for security (They need a complete list and verification of every software used in the district).
They’re almost certainly not as vulnerable as tech feels they are. To exploit this, access would be needed to whatever is running log4j.
So in the Arduino IDE instance, just using it on it’s own doesn’t make it vulnerable, because it doesn’t allow any outside connections. To trigger the vulnerability you would have to load a module or some code into the Arduino IDE that is designed to trigger a log message to target the vulnerability. Basically you would have to purposefully download something extremely sketchy and try to use it in the Arduino IDE.
In your case, I would find it extremely unlikely that you are running anything on your computers that allows incoming connections (i.e. a webserver). So you have no way for someone to exploit this vulnerability. None of the FRC tools are set up to allow incoming connections, so even if they were using log4j in a vulnerable way (and it doesn’t look like they are anyway), they still couldn’t be exploited from the network.
So like @Peter_Johnson mentioned, it’s unlikely to be a concern for individual users and “PCs” but primarily servers and the companies running them.
Our laptops are air gapped. Programming and driver station. A nightmare the evening before a competition when I had to clean off something (msblaster? I can’t remember) reinforced that policy with me.
Ha. I can empathize - take hope in the fact this is the reality of the vast majority places where the folks in charge of security and the users are not one and the same. Which is pretty much everywhere.
While I don’t know all the nitty-gritty details I can take a spin at explaining it.
log4j is a library which creates plaintext, human-readable log files on disk. It’s used for programmers to help monitor that their programs are working right, and diagnosing when things go wrong. While there are many ways to accomplish logging, log4j is a very common library which is used in many many programs.
When doing logging in a program, and that program receives input from the “outside world”, it’s pretty common to include that input into some message in the log file. This is a best-practice, a good thing.
Since most programs interact with humans, humans generally can influence the content of these log messages. For example, in the case of the Arduino IDE, you can generate log messages when you click the “File->Open” option. When you provide a file path, the program will produce a log message about your input. By providing different file paths (valid or invalid), you can control the contents of what gets into the log files.
This also happens in web servers - every time you access a server, provide your credit card info, log on to gmail, anything… log messages are being generated with the info you provide from your browser.
This particular vulnerability exploits a bug in log4j where, for a specific style of log message, it would trigger the program to download code from any other computer and run it. This is called “Arbitrary code execution”. If a malicious human has the ability to influence the content of a log message in a program, they also have the ability to do Arbitrary Code Execution.
Sounds bad, right? Let’s keep digging.
From a “security” standpoint, all computer systems have what’s called an Attack Surface - literally, the set of all ways a malicious person could get in and do damage.
How “bad” a vulnerability is for a specific system can be explained in terms of how much adding that vulnerability increases the attack surface for that system.
Arbitrary Code Execution is very bad in most contexts. For example, in a web server, you have increased the attack surface by an enormous amount. Taking Google as an example - Users went from being able to read their own email, to being able to see email of anyone else on that server. Or see the server’s configuration. Or see what other servers it’s connected to, and attack them as well. When people say “the internet is on fire”, this is the kind of thing they’re talking about.
However, let’s consider the case of the Arduino IDE on a laptop at your school. The normal way to generate log messages through the Arduino IDE is to grab the laptop, open it up, turn it on (presumably it auto-connects to the internet), double-click the Arduino icon, and interact with the user interface. If a user does this, yes, they could leverage the log4j vulnerability and do Arbitrary Code Execution.
But here’s the catch: to get to the point where they exercise that vulnerability, they already have physical access to the computer, and full control of the mouse, keyboard, and command prompts. In that situation, regardless of whether the Arduino IDE is present or not, they already could do Arbitrary Code Execution. The punchline: Having Arduino installed on your personal computer does not increase the attack surface of your device. Therefor, in this particular case, you shouldn’t be concerned.
The scenario doesn’t change much if you imagine someone external who has ‘hacked’ through your network firewalls, scanned your network, hacked through the computer firewalls and protection software, and gets access to the Arduino IDE on one particular computer. If they’ve hacked that much, they already have the ability to do Arbitrary Code Execution, and the punchline is the same as above.
Hopefully it helps you have an informed conversation with your Security folks. Definitely listen to what they say - they very well may have concerns above and beyond the simplifications I’ve made here. They’re smart people, just with different motivations than you.
And, fwiw, if they do come back with a legit concern - I’ve got the Arduino IDE on all my personal computers, and would very much be interested to know if there are serious concerns associated with it.
Caveat
This was my primary source. I don’t do computer security for a living, so please be careful taking my words at face value. I am happy to be proven wrong, and will use the Edit button to its fullest capability!
It’s also helpful to review any specific for a specific software package. Since the arduino ide can execute plugins downloaded from the internet, there’s an additional attack vector from a malicious plugin.
I actually saw that. I read that page before posting. It would not be the first time tech locked something down for a security hole that had been patched already.
@gerthworm thank you for that explanation. It makes a lot of sense.
As someone who’s been dealing with it at work for the past week… this is both incomplete information and outdated.
The original issue had two possible mitigations listed, one of which was to upgrade to Java 8.0u121 or later. This, and the other mitigation (a system property setting) were later discredited, and shown to only limit exposure, while still leaving some attack vectors open. Indeed, a second vulnerability notice was released on tuesday, along with a second update to Log4j, for a related vulnerability that is NOT covered by those two originally proposed mitigations.
If updating to Log4j 2.16.0 is not possible, the only other true mitigation is to remove the JndiLookup class from the log4j-core jar, which completely removes the vulnerable code.
You might want to rely on professional security researchers over “scans” at work.
Originally, it was believed that more recent versions of Java 8 protected against it, as the default configuration prevents class loading via JNDI from remote hosts - until researchers showed that they could get around that limitation. That’s why that is no longer a recognized mitigation by the security community, and isn’t even listed on the apache website or on the CVE list as a mitigation any more. The other original mitigation, setting formatMsgNoLookups to true, was also originally listed in both places and has since been removed, as it was found insufficient when they discovered the second vulnerability on Tuesday.
In short, professional security researchers have determined that the only mitigations that cover all aspects of the vulnerabilities is to remove the vulnerable code, the JndiLookup class, from the log4j-core jar, or to upgrade to log4j version 2.16.0. I’d hate for you to be sitting there with a false sense of security and then be hit by an attacker.
And then this weekend, there was a third vulnerability announced (a denial of service) which resulted in log4j 2.17.
I agree this shouldn’t be too troublesome for robotics teams. People are reacting (and overreacting) based on the news. This is an extremely serious problem for websites and such. Whereas VSCode and the like aren’t/shouldn’t be accessible from the internet. Which means someone exploiting it already needs access to your computer. And if they have that, a remote control execution attack is a moot point.
Boy would I like to go more than a few days without a new log4j security vulnerability though.