- Joined
- May 18, 1997
- Messages
- 55,534
PSA: Potential security vulnerability in Elasticsearch and more via Apache Log4j (Log4Shell)
Patch is applied. Thanks RoldanLT ! The best forum admin I have ever had.
This damn guy is quick!
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Worked all weekend. Better safe than sorry approach.Spent most of yesterday and part of today patching our systems at work. Some vendors don't even know if some of their systems are affected as of now. Been a shit show, but I think most companies will pull through.
UniFi Network Application 6.5.54
Bugfixes
- Fix a security vulnerability found in a 3rd party library (CVE-2021-44228).
Palo Alto pushed out an updated threat Library yesterday for that exploit, I’m glad they did but it caused me some fun unexpected surprises this morning when it was also blocking the BAcNet traffic coming too and from our boiler system causing them to not fire up on a morning of -20.
Northern Canada. Either way PA fixed it once I let them know and they had it all squared up by their next virus definitions update some 8h later.Wow, where are you that you are having those temps? We have been having an unusually mild winter thus far here in New England.
Yea, our software teams are thrilled lol. Time to update again.FYI: Looks like the fix did not completely alleviate the issue.
https://nvd.nist.gov/vuln/detail/CVE-2021-45046
The design that even allowed for this in the first place is fucking insane.
Like seriously WTF.
All the pieces, in isolation, make sense. Logging - cool. Parsing logs to trigger events - sane. Running code off of a log - great for testing (gather a crash dump, pull an analyzer, etc), but potentially risky.It reminds me of this XKCD comic:
View attachment 422246
Seemingly insignificant and small packages that everyone depends upon, that were originally written in a different era before everything was online and never brought up to modern standards.
There are probably plenty more log4j's hiding out there in plain sight, included with or depended on all sorts of major projects.
Of course, the Apache Software Foundation is more than "some random person in Nebraska" but still... Things still fall through the cracks, especially when they are something seemingly trivial like a small log tracking module...
I think it is a direct comment on the Heartbleed bug from OpenSSL, which was maintained by two guys in their spare time because nobody else was doing it. Funding for the project dried up in 2003, but so many sites were using it they maintained it for free in their spare time as their repeated requests for funding went unanswered, until Heartbleed happened and the world saw the situation they were in and went "oh shit!".It reminds me of this XKCD comic:
View attachment 422246
Seemingly insignificant and small packages that everyone depends upon, that were originally written in a different era before everything was online and never brought up to modern standards.
There are probably plenty more log4j's hiding out there in plain sight, included with or depended on by all sorts of major projects.
Of course, the Apache Software Foundation is more than "some random person in Nebraska" but still... Things still fall through the cracks, especially when they are something seemingly trivial like a small log tracking module...
It's a consequence of two things. First, log4j has a bunch of things you can include in the logging, of the format ${type:parameter}. You can think of the types as 'modules' and since everything enterprisey tends towards maximum bloat, there are dozens of modules. At some point someone added ${jndi:xxx} as a module. JNDI is a bloated enterprisey monstrosity that encompasses five major bits of network related functionality. As soon as you add the ${jndi:} bit you get access to parts of it that make no sense for logging like 'fetch and execute remote code'. It's like you needed a canoe to cross a pond, but you just dropped in a nuclear aircraft carrier because it was handy. What could go wrong?
The second part was the absolutely boneheaded decision by log4j to look for and execute the ${type:parameter} in everything being logged, including random user data. You never interpret user data, ever, unless you're explicitly doing user scripting. It should only apply in your log configuration strings. Now you've handed everyone access to jndi and the keys to your nuclear aircraft carrier.
So it's just a series of bad decisions that I'm sure seemed like okay ideas at the time because they made things more convenient and we always go for convenience over security.