Some notes on the log4j vulnerability
The cybersecurity industry was in a panic this weekend over the “log4j” vulnerability. I thought I’d write up some notes.
Don’t panic. Yes, those involved in cybersecurity need to panic a bit, or at least, treat it with utmost urgency, working nights and over the weekend. But for everyone else, just make sure to update your phone, router, and TV over the next week. At some point, somebody will release a utility that’ll scan your Windows/macOS desktop for the vulnerability, so look out for that. But the bug doesn’t threaten you personally nearly as much as it threatens services out on the Internet.
It’s in a component used by a lots of software. There are over 10,000 products that have been identified as vulnerable, some very popular ones. It’s like when an airbag chip was found to be faulty, requiring most auto manufacturers to recall some car models — it’s hit or miss which products it actually impacts. That’s why cybersecurity industry is “panicking” — there’s so much work to be done to figure out exactly what is, and isn’t vulnerable. Luckily, it’s pretty easy to scan a system for that component without having to do something custom for each product.
It’s an injection bug. This is the second reason why cybersecurity industry is taking this seriously. Most attacks come as some sort of “command” (which firewalls and such double-check), but this attack gets smuggled in as mere “data” that’s supposed to be harmless. Only later, possibly not on the same system, is this data opened and treated as “code”. It’s a big threat to systems directly exposed to the Internet — but is also a threat to systems deep behind firewalls and other protection that merely process bits of data retrieved from the Internet.
There is no easy product fix. Lots of vendors are out in force talking about how their products can fix this problem. This can be helpful as long as the reader understands the context: no product is a magic pill that will fix it for you. Products should be considered second, after your primary task. Your primary task is to check all systems for the “log4j” component, starting with those exposed to the Internet, starting with a simple check if files with the pattern “log4j-core*.jar” exist on the system.
This is not a surprise. Here’s the analogy: the covid pandemic was a surprise, but hurricanes hitting Florida are not. Floridians are largely prepared for hurricanes, though every time a hurricane hits, they learn some new lessons on how to prepare even better for the next time. Conversely, this covid pandemic was a complete surprise, and requires major a major rethink one what we need to do to prepare for the next one. This ‘log4j’ event is more like the hurricane than the pandemic: we are actually prepared for it, and are responding well, though we’ll learn some lessons on how to be better prepared next time. However, there are chicken-littles who claim it’s more like the pandemic scale event, insisting we need a revolution, a complete change in how we’ve done things before. It’s a popular message. It doesn’t take any skill to go on stage and give a TED talk claiming everything is broken, and it’s popular among audiences because they don’t need any particular skill to understand the message. But if you understand cybersecurity, you find that things are complicated and that there are good reasons things are the way they are. Cybersecurity is about steady, evolutionary improvements, not revolutions.
A lesson on person attacks. The developers of ‘log4j’ are now feeling like sports players who just lost the championship game, with fans everywhere dunking on them. Sure, it looks like they fumbled that easily caught ball, but this ignores the complexity of the game going on at the time. Eventually I’m going to write up a blogpost for developers why this was an easily caught ball they fumbled, but I hope to do so in a way that doesn’t call them bad players. After all, they are playing in the major leagues so obviously aren’t bad players. But at the same time, there’s something here for future players to learn. Separation of code and data, with “taint”, is one of the top issues for secure code.