So... guys and gals... ladies and gentlemen... the cat is out of the bag. And this seems to be serious.
The question is... how bad is it? Cause the internet is buzzing with panic at the moment but we also have to protect ourselves at the end of the day.
I know for sure that MPLab X uses Java, I think also Eclipse uses Java and generally many many programs do use Java.
There are security experts saying that endpoints can also be affected so. Did anybody find workarounds, problems etc.?
I do not know if this is the right place to place this post. I do not know if there was a post prior to mine discussing this.
But I would guess that there are people running IoT servers here, and there are people generally concerned which also
know much much more than me.
Let´s discuss this.
Cheers,
Lefteris
Yes, endpoints are potentially affected. The big issue is, that it is not always obvious if a program even uses java or not, since any program can just bring it's own JRE along.
Anything that connects to arbitrary systems, or can open arbitrary files downloaded from the internet is potentially in danger.
On the other hand, anything that can only connect to specific external systems *might* not be affected as much, as long as these external systems are actually safe.
There are now a couple of tools available, both for Windows and Linux, that can be used to search for log4j2 components. To be safe you should assume that any application that includes log4j2 is vulnerable.
Yup, I read all the scare stories, and thought it was serious. I run a web store that is constantly hacked at by Russians. So, I did some research, and found that MANY web sites do NOT use Log4j, and it is not installed on my site. So, I didn't need to take any action.
Jon
A quick browse of my PC shows that Cadence use it and STM32 Cube uses it. This is V2, the one with the issue. There are other products which use V1, which doesn't have this issue but probably has others.
Care to share a tool or two? Right now the whole internet feels poisonous
"Keep calm and carry on."
Best slogan ever.
The risk is low for desktop applications that might be using log4j (e.g. MPLABX). An attacker would need to cause something to be logged by the application, which if it isn't interacting with an attacker-controlled service on the Internet, would be unlikely for a desktop app (unless it's a browser or some such). So I wouldn't be too worried as an end user.
If you host applications or use hosted applications written in Java, it's fairly likely that you are vulnerable, and there are a wide variety of potential vectors for the exploit, since all it requires of the attacker is to be able to cause some chosen text to be emitted as a log entry. That could be via a URI, request header, filename, etc. etc. etc. it doesn't matter, and would be hard to track down and verify that all cases are not vulnerable. So if you are hosting any such applications, either upgrade or apply a mitigation ASAP.
It allows remote code execution and is pretty easy to exploit, so is very very serious, as such exploits go, which is why everyone is (hopefully was, since they have mitigated by now) panicking.
CloudFlare has a good writeup on how the vulnerability works, as well as how to mitigate:
https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/
But that might make a lot of routers actually vulnerable and I don´t really see how these are going to get fixed any time soon,
if ever in some cases. Probably we´ll get some support for newer models. In any case, that´s just such a shitstorm.
In any case, that´s just such a shitstorm
Hey, it's open source. As has been pointed out on here many times, a billion eyes could review it so it cannot be less safe than any commercial product. How dare anyone think otherwise.
But that might make a lot of routers actually vulnerable and I don´t really see how these are going to get fixed any time soon,
if ever in some cases. Probably we´ll get some support for newer models. In any case, that´s just such a shitstorm.
It's quite unlikely that any consumer grade routers or other embedded devices are running Java. It just doesn't make sense for most embedded applications, certainly using log4j would be weird also, as you're usually not wanting to write many logs to save your flash write cycles. I wouldn't be worried about your router, and any other embedded IoT devices either; maybe some fancy GUI things like your fridge or whatever. But even in the extremely unlikely event that they are vulnerable to this, they'll be behind your router and not accessible from the Internet, and probably have hardcoded endpoints, so it'd be difficult for an attacker to inject a payload.
In any case, that´s just such a shitstorm
Hey, it's open source. As has been pointed out on here many times, a billion eyes could review it so it cannot be less safe than any commercial product. How dare anyone think otherwise.
Well it seems that these billion eyes weren´t really all that enough. Imagine what happens with proprietary. BTW the fault was found from people fooling around in minecraft from all places.
ve7xen, your comments are reassuring. But there are many reasons a router would run something fancy. For example "some German company can´t remember the name" routers have IoT
server support, they have integrated the IoT access point. Do they run Java or some kind of Apache? Who knows, maybe yes maybe not.
Ubiquity routers that run their Unify server were also hit, don´t know how and how much and whether this was front facing or not. ( Maybe you had to have the cloud services activated for that to be
front facing, I dunno ).
The next days / weeks / months are going to be fun!
Yet another reason Java is a bad idea in, well, just about everywhere.
ve7xen, your comments are reassuring. But there are many reasons a router would run something fancy. For example "some German company can´t remember the name" routers have IoT
server support, they have integrated the IoT access point. Do they run Java or some kind of Apache? Who knows, maybe yes maybe not.
Normal routers still only have 64-256MB of RAM, which is pretty tight for a Java application server. IoT devices typically even less. And unless you are wanting to run a GUI or something, it doesn't make a lot of sense to use Java for this, it has to interact a lot with the system and has no need to scale or a need for a complex data model. But you're right, there's probably something out there, I just wouldn't worry too much about your cost-down consumer router.
Ubiquity routers that run their Unify server were also hit, don´t know how and how much and whether this was front facing or not. ( Maybe you had to have the cloud services activated for that to be
front facing, I dunno ).
The UniFi controller that is vulnerable is software that runs on a standard server, not something that runs on the managed devices. Treat such things as you would treat any other application.
Yet another reason Java is a bad idea in, well, just about everywhere.
Nothing particular about java here. This kind of thing can and does happen in pretty much any web development framework regardless of language. The scope of this is a result of monoculture, java is an extremely popular language for web development, developing and supporting distributed web applications requires a good log system and there are only a few reasonable choices. So when a problem is found it hits everyone.
The question is: what is the reasonable alternative?
The world when everyone just rolled their own in perl in the late 90s was definitely not better or more secure despite those applications being much simpler.
The world when everyone just rolled their own in perl in the late 90s was definitely not better or more secure
For a start, at that time you were protecting against accidental errors (like line noise) not malicious hacking. But if everyone rolled their own and it was less secure, the fallout would be limited.
But I agree that not rolling your own is generally better in many areas.
Since some software runs a local webserver (for no clear reason), yes, everything that has the potential to log something is at varying levels of danger.
Recipe for disaster:
- Lacking Mail Security
- Word-Macros enabled
- Unaware User
- Local Java based server with Log4J