Log4j Vulnerability (Log4Shell) Explained // CVE-2021-44228

[@Ashnurazg]

It's important to mention that the SecurityManager is deprecated in Java 17 for removal in Java 18. Why - you might ask? - It's very old, it was implemented back in the old days where Java was run inside of applets at websites. No one uses applets anymore, it's a dead feature and JEP 398 (-> Java 17) deprecated it for removal as well. All browsers removed support for applets. Nowadays JS, WebAssembly, etc. are used. - SecurityManager's configuration is very complicated, it has poor performance and it's not widely used. For securing object de-/serialization the JEP 290 (-> Java 9) and JEP 415 (-> Java 17) implemented filters for object serialization and deserialization.

[@LiveOverflow]

thanks for the added info. You can see my java knowledge is kinda old :D

[@vaisakhkm783]

@@LiveOverflow But your work is amazing..... 🤗

[@Dragiux]

@@spotlightsrule If you can run kotlin, you can upgrade your JVMs. Stop whining.

[@omri9325]

@@Dragiux It's not whining, it's facts, Java 8 is heavily used even today.

[@EskoLuontola]

In the Devoxx UK 2018 conference, Oracle's chief architect Mark Reinhold said that their long-term goal is to remove serialization from Java. But there is no JEP about it yet, so it'll likely still take many more years.

[@CarlosVieiraCrowSec]

This is the first video I've seen the real and correct explanation of how JNDI works and how deep this vulnerability was... Awesome work!

[@Noctuu]

I agree with you, I hate how most of the videos show us a payload without explaining why the payload is working

[@TheCardil]

Fascinating view on Log4Shell, and why it wasn't noticed earlier. Maybe we should build linters controlled by security researchers to hint us, developers, about possible vulnerabilities.

[@VivekYadav-ds8oz]

Wow that's actually a brilliant idea. It should be integrated into static analysers.

[@FlorianWendelborn]

These kinds of things already exist. Snyk for example

[@srki22]

Maybe it was not noticed earlier because serious companies have their server in VPC so that servers cannot connect to a random server on the internet that hosts malicious code.

[@DryBones111]

@@srki22 a secure application should be secure on several layers. Relying on a firewall means that all you need is one vulnerability on the firewall to crack open your application.

[@TheCardil]

@@FlorianWendelborn the scanners that exist only warn about confirmed vulnerabilities, not possible ones.

[@dzhimy6266]

The problem in security is that there's this weird corporate push to express the "you don't need to code to get into security" idea, which if what you're doing is exploiting software, you need to know how software is built, you basically need to have previously been a developer, that's not gatekeeping, it's literally a job requirement. I think there's more people than we would like to admit in the security field testing and exploiting software with zero software development experience, or basic coding experience when what we need is people who know how to build software, we need more software engineers in security, and we need more security testers in software development and software QA.

[@Mrx-dw4py]

@Dzhimy really bro, in this world we need more expert on Cybersecurity... And better programmers that not do mistakes

[@stevegremory3849]

@@Mrx-dw4py no shit bro why don't you become one then? it's not that easy. We're humans, besides making kids, we make mistakes; hell even the kids can be mistakes!

[@Mrx-dw4py]

@@stevegremory3849 I mean, they should be more careful ... it won't be perfectly because nobody is perfect

[@Mrx-dw4py]

@@stevegremory3849 but let's stop fighting, I just want to talk, have no problems

[@stevegremory3849]

@@Mrx-dw4py nah nah bro sorry if I gave the impression that i was out to fight lmao

[@pavelhoral]

For me it is absolutely unbelievable, how someone could have thought that it is a good feature to do any processing on the message part itself. That is simply bonkers...

[@hpsmash77]

its beyond me

[@hhvhhvcz]

it's basically spicy SQL injection

[@pavelhoral]

@@hhvhhvcz This is much worse than that. This is "SQL injection" iff the injection part would work on prepared statements... that is the bonkers part. Imagine someone would process SQL commands in your query parameters.

[@GroovBird]

@@pavelhoral this is SQL injection if the RDBMS could be convinced to download arbitrary code and execute it.

[@BatteryAcid1103]

Agreed 100%... The most sane approach for this would simply be to require the developer to perform the JNDI lookup themselves and log whatever contents are desired using the more standard Log4J formatting options. Even ignoring security implications, requiring some type of (slow) network transfer simply to log a string is bizarre. I understand the getting some data from some network location and logging some of that data, but only in a scenario where you're also going to *use that data for something!* If you just download something, log it, then throw it away... why?

[@MajorNr01]

And here I was, thinking that hosting a little Minecraft server for me and my friends WASN'T going to ruin christmas.

[@roberttuck4768]

This is exactly the analysis I was hoping someone would do. I believe one of the reasons that the problem was not found earlier, is that although many developers are aware of developments in the hacking world, none of them were aware that this lookup facility was a feature in log4j. In fact, even after I looked at the documentation, it wasn't immediately clear that message lookup was something that is not only available in config files, but also in log messages and even log parameters. Log4j is something that is typically set up early on in the life of a project and most developers although they may make use of it extensively will probably never really delve much into configuration or advanced features, so it is very much a fire-and-forget thing. One thing that is very clear from your video is that what in hindsight looks like an incredibly stupid design feature in log4j, was much more innocuous when it was conceived in 2013, and that it was only after the JNDI exploit was discovered that its security should have been reconsidered. Having said that, even without the JNDI lookup RCE, further security concerns have been raised which have led them to remove message lookups completely from their latest update.

[@srki22]

Maybe it was not noticed earlier because serious companies have their server in VPC so that servers cannot connect to a random server on the internet that hosts malicious code. For example in AWS they motivated people to have servers in VPC. When you create a Redshift server, Dax, or RDBS by default it is in VPC so that it cannot access the internet so Log4J2 could not connect to another server. That is the main reason why we don't have a catastrophe now.

[@JojOatXGME]

> In fact, even after I looked at the documentation, it wasn't immediately clear that message lookup was something that is not only available in config files, but also in log messages and even log parameters. I agree. After hearing about this vulnerability, I was scanning through the documentation and couldn't find a description how to trigger the lookups from log messages. > One thing that is very clear from your video is that what in hindsight looks like an incredibly stupid design feature in log4j, was much more innocuous when it was conceived in 2013, and that it was only after the JNDI exploit was discovered that its security should have been reconsidered. I don't agree. It is still a stupid design. Just reading the first sentence of issues.apache.org/jira/browse/LOG4J2-905 should trigger alarm bells in everyone's head. Running string interpolations, which are intended for the developers, on untrusted strings is negligent in my opinion. This is a vulnerability even without JNDI, although it would be less critical. For example, secrets (like API tokens) are often stored in environment variables. With ${env:MY_API_TOKEN} and nothing else, everyone with access to the log files could "steel" the secrets. And even if you don't find a way to exploit this feature, it still makes the log files untrustworthy since you never know what was actually logged. Besides, deserialization is known to be unsecure for a long time. I think most Java developers know that. I learned that in my first year at the university. Even if nobody had built a RCE for JNDI, the exploitability might have been expectable. Furthermore, triggering network requests to arbitrary addresses is already pretty bad and can already be used to extract sensitive information, so you don't need the RCE after all.

[@bryan397]

Dude, doesn’t matter how much content there is on the internet! You always make amazing videos! So never doubt! You’re one of my favourite youtube channels

[@MarzJonp]

Facts!

[@soviut303]

Don't worry too much about repackaging existing material, especially when it comes to vulnerabilities. I'm a software developer and the only things I've heard/seen on the topic are "check that these apps are patched". So hearing you amplify what others have said about the cause of the vulnerability are good for folks like me.

[@seanvinsick5271]

I'm a software engineer, and I love your videos. Especially binary exploitation and the sudoedit series. Security is everyone's responsibility, not just the researchers. That's like saying bugs are QAs responsibility to find. Writing code without security in mind is what leads to stuff like this.

[@highpraise-highcritic]

adding a 2nd thumbs-up here

[@HansLemurson]

It seems there's a design issue with features being "Safe by default" vs. "Can add safety restrictions if you know it's an option"

[@davidhcefx]

Absolutely. And library developers should also collect feedbacks on how frequent a certain feature has been used, in order to align with user expectations.

[@TigerWalts]

Before even considering the RCE exploit, I think that it's insane that by default log4j allowed lookups to be parsed in a log message. You wouldn't dream of adding an unsanitised string to an SQL command, so why allow this? The moment someone noticed that it's possible to log an environment variable by logging a lookup string, it should have been made an opt-in feature. In this age of micro-services, security credentials are passed to containers primarily using environment variables. The names of these variables are publicly documented in open source projects. So if your logger echos back to the user their input, but with the lookups parsed and populated, this feature can be used to leak usernames, passwords and and keys.

[@wlockuz4467]

Yep, SQL injection is the first thing I thought of when I saw the exploit, the feature really is questionable.

[@LKRaider]

The assumption seems to be that logs are not returned/exposed to users and that macro expansion is useful for debugging.

[@romeomungiu2932]

log4j lookup is the new format string

[@TheCardil]

Well. This is also possible because developers tend to log data, they shouldn't. By logging user provided data you are essentially creating a database in terms of GDPR. If developers would log only non user data (user internal identifier for example), this vector of attack should not be possible. Log4j is exposing interface for devs, a trusted people, who should know what to put inside that string. But, people don't think about it. Let's just toString on everything!

[@lal12]

My thoughts exactly. Even from a functionality standpoint it is stupid to pass user input directly into such a method. I mean what if some legit user input contains "${...}"? Is an exception thrown and the message not logged? Is the message just scrambled? Either way it shouldn't have been done like this just due to functionality. And security wise it is a well known issue and bad practice. It is known from contexts of SQL injections, shell injections and so on. And even for the pretty old printf function it is clear Zou have to pass user input as a later argument and not as the first/format Parameter. I mean obviously how the Log4j stuff works and is used is problematic. However all in all it seems to be more of a usage issue/mistake than an actual bug in the library. The whole jndi thing is well dangerous too. Such requests should for one be made explicitly and secondly be made once at startup. But to meet the whole java stuff seems to be a mess anyway...

[@hpsmash77]

-shares whole objects carelessly (this one's for java) -uses a very bloated and obscure features rich library, which can apparently run code -doesn't make the obscure features opt in -RCE is found surprised Pikachu face okay jokes aside, how many times do people have to yell that a thing should do what it says it does and should not bring the obscure features in scope by default 😑 le UNIX philosophy

[@OwO-.]

8:40 This. It's such a bad idea to make stuff do other stuff that you wouldn't expect, like Java's URL class making DNS lookups when putting them in a Hash table.

[@Pharisaeus]

en.wikipedia.org/wiki/Principle_of_least_astonishment ;)

[@anticat867]

Coming from C, I know that I should always use print("%s", user_input) and not print(user_input). I was wondering for the past two weeks why Log4j does not have this separation. Guess I will find out in part 2 - looking forward to it.

[@bandie9101]

actually this template substitution happes in the parameters, not in the format string.

[@danielmoreno1712]

It's baffling to me how the issue was identified years ago, yet it was not treated as the serious security flaw it is up until recently. Really makes me wonder how much was this vulnerability exploited accross the years it managed to stay under the radar, and how didn't it get the attention it deserved for so long.

[@benargee]

This is probably the case for a lot of vulnerabilities. I heard the NSA is just hoarding zero days. The probability that another person discovers the same zero day completely on their own is more than 0%

[@rujotheone]

Pretty sure NSA and the likes used it in their ops.

[@Ash_18037]

Not that baffling to me, looks like it was a combination of far too specific scope/mindset during that JNDI research/talk so they did not even consider the software using JDNI, and the classic 'someone else's problem to fix'. Also I think you mean "yet it was NOT treated as the serious security flaw"

[@falxie_]

Actually knowing why that feature existed in the first place is something I haven't heard anywhere else

[@THeMin1000]

Thank you for your amazing work. And yes I believe specialization is great is how we reach a higher level in terms of potential in a field, understanding the emergence when fields combine is where we generally overlook.

[@faran_siddiqui-d3t]

Well the most critical 0 day explained by the legend himself.🤩

[@PandaMoniumHUN]

306 pages of documentation for a logging library. That should be enough to realize something is awfully wrong and to never touch the library.

[@pvic6959]

yelled at for not writing docs, yelled at for writing too detailed damned if you do, damned if you dont LOL

[@smithwillnot]

What I got from this: we need more developers to transfer into security over time and there should be more security research teams who incorporate (probably active) developers into their teams. Ofc it would be great if these developers have a lot of experience. To be fair I have no clue about the way security research teams work, maybe this is a thing already anyway. Also from your takeaway, it would be nice having more active communication between researcher and development worlds.

[@steefant]

+5 insightful ;) minor remark: i think there was no "leak" but that the vulnerability might have been exploited in the wild and alibaba noticed it via monitoring not own research and CF simply found the same traces when looking more closely after the fact. but i am just speculating without even checking what's the established public truth here.

[@dorb1337]

I do believe that there are many videos and resources about this topic and any other topic on the tech fields. But, and it's a big 'but', it's a matter of who delivers this material and how. To the bottom line - most of the times, your explanations and talks are much more simple to understand than the others :) so keep sharing your knowledge with us .

[@aspuzling]

I think there's one very key detail that you're missing here. Lookups as a feature was never intended to be used in messages. I believe even the Log4J maintainers didn't know it was a feature. Lookups as part of patterns are well documented. Lookups as part of messages were not documented at all. You can't blame consumers of the library for not spotting it as it was never mentioned in the documentation. I believe Log4J maintainers never thought that JNDI lookups were vulnerable because they never expected a lookup to be formed by an untrusted user or be formed via user input. The fact that this feature was completely removed in 2.15.0 without any mention of breaking backwards compatibility seems to confirm this.

[@LiveOverflow]

Yeah that makes sense. At least from the documentation it seems that way. However the issue in 2014 with the unexpected lookup should have lead them to realize it. They treated it as an expected behaviour, no?

[@aspuzling]

@@LiveOverflow Yeah that is a good point. I see that a symptom of feature inertia. The developers saw this and thought "well that's weird but I guess we can add config to disable it" without stopping to think whether or not this was a feature that should exist at all.

[@MrCh0o]

When you talk about patterns or messages, you mean the patterns used in configuration files and the messages that are sent to logger, right? I wonder how that same lookup feature could really slip in unintentionally then. Something like the pattern values being expanded first and lookups being performed as the next step? But that seems to immediately raise a question of "what if the expanded values had lookup substrings in them"

[@AdamFJH]

@@aspuzling That is why this mess is really the developers fault.

[@ekfliu]

LOL that is so bad, that is like using Prepare Statement where the SQL is coming from user input instead of hard configuration file within the application itself. Yeah people do these kind of stupid stuff.

[@lal12]

Even from a functionality standpoint it is stupid to pass user input directly into such a method. I mean what if some legit user input contains "${...}"? Is an exception thrown and the message not logged? Is the message just scrambled? Either way it shouldn't have been done like this just due to functionality. And security wise it is a well known issue and bad practice. It is known from contexts of SQL injections, shell injections and so on. And even for the pretty old printf function it is clear you have to pass user input as a later argument and not as the first/format Parameter. I mean obviously how the Log4j stuff works and is used is problematic. However all in all it seems to be more of a usage issue/mistake than an actual bug in the library. The whole jndi thing is well dangerous too. Such requests should for one be made explicitly and secondly be made once at startup. But to meet the whole java stuff seems to be a mess anyway...

[@umlal]

Thanks for the video, still added some value for me. As a security professional seeing the internet evolves and dented with this magnificent exploit is euphoric, such an amazing journey!

[@alxt111]

Will you cover the NSO Pegasus exploit? It is truely mind blowing and I don't fully understand it.

[@brunoais]

I didn't know about remote code execution. Until now I didn't know about the talk there. As a programmer I stopped using log4j in around 2015 due to how much I saw log4j had a "opt-out" mentality and no real means to tell it, in a log message, where the safe content is and where the user content is. I never worked with jndi, so I would never have thought about those issues. Actually, my last drop happened with the issue outlined by the bug in 2014! I was logging user content and I was trying some weird contents. I ended up, as a user of the program, creating a message with side-effects. For me, it was the last drop (talking about dodging a bullet). I have been using logback since. I hope I went through a correct option.... BTW, The golden rule is: Never treat input any other way than either a number, a string or a predefined set of possibilities (tested very strictly). Always when it's a string, treat it for what it is, a string. Not a codified command as a string NO! Just a sequence of characters.

[@forbiddenera]

@15:35 I disagree. Rule #1 of software development. Never, ever trust input.

[@guiorgy]

Honestly, the best video on Log4J that I watched so far!

[@lo0s3_labz]

I think for a lot of organizations security isn’t an integrated focus inside the business itself (it’s a cost to the business, almost like paying insurance) therefore it’s just not a major focus or driver. It’s always a game of catch up due to that underlying reason. Also depending on the organization (old/large businesses think of major tech debt for example), it’s not so much a matter of a 0-day or custom web app vuln that poses the most risk to the business, that’s more expensive for an attacker. People and processes are more easily exploited at lower costs. If I can phish a user to gain initial access to a corp network or a devs machine and ride credentials to the gold, I don’t need to invest time into reversing an application or understand any of the code. Things are evolving in the industry as we are moving more into cloud hosted solutions, etc., so some of the attack surface shrinks, but the underlying issue still remains the same.

[@landongaus1906]

Thank you for explaining this with so much detail and backstory... I look forward to your Part 2, but I have to say I think you hit the nail on the head about developers expectations, opt-in features, etc... Maybe the security research field didn't raise the alarm soon enough but it is the fault of developers who thought it was a good idea to add these advanced lookup features and leave them enabled by default. I concur most developers wouldn't know they are there and would just expect log4j to log a string without doing anything else fancy. I wouldn't fall on your sword as a security researcher when the bigger issue is the judgment of log4j developers being misguided. Additionally, I think it is just a terrible idea to deserialize and reserialize objects with constructors and methods and whatnot... That should be considered drunk driving and developers should not be taking the lazy/quick route doing that sort of thing if they care at all about the security of the programs they write...

[@manan5]

your videos are the best for indepth knowledge. Thanks thanks and thanks! waiting for part 2!!

[@bernardcrnkovic3769]

I don't know who thought that "Hmm, instead of just serializing data and sending JSONs, lets just send full blown bytecode that can be deserialized and executed in JVM without ability to be validated" would be a good idea??? I simply can't see how that feature aids anything. If anything, makes systems more complex and harder to reason about because of COMPLETELY scattered state across microservices in god-knows-what objects...

[@bernardcrnkovic3769]

Remember folks, separation of stateand logic in code is essential (I know, completely opposite of what you were taught at UNI in OOP classes 😁)

[@bracco23]

The feature is already part of the earliest java versions, in a time when the internet wasn't as widespread, hacking and security was still a thing a few people did for the lolz and there was not as much care about data and how to best protect them. Legacy things don't have the best track record for security.

[@DelusionalLogic]

Serialization is from back when Java was the dream of commoditized classes. The dream was that business people would just slap together premade objects downloaded directly from the internet in GUIs, and that would be programming. The dream was big marketplaces if custom objects and effortless integration. Reality fell far short, but that's why serialization is what it is.

[@djthdinsessions]

This was engineered long before even microservices was a thing. But yes, that was a very idiot idea 😅

[@vaisakhkm783]

That one dev be like: If object can used everywhere in Java, why can just sent it in the network also... That would be COOL...

[@123gostly]

This was genuinely beyond what other creators shared. Thank you for helping us understand the timeline and giving a broader understanding of the issue.

[@mvdrider]

I think developers are part of the security community, I believe security is within the software engineer field, not on the side, is very hard to imagine that the people that write the code or design the system is not aware of security(imho) at least as a software engineer I feel that way :) maybe we need better testing also, and testing is within the software engineer field as well. Great video! Thank you so much for sharing! 💪🏻💯

[@ciberman]

I would love if you can make more of these "Security for developers" videos. I consider myself a developer but I want to know about security, so I think this kind of videos are super useful.

[@iWhacko]

I'm a software engineer. Specialized in Java. Also dabble a bit in security. I always aim to disable features by default, instead of enabling them. It's the same with user permissions, always disallow a user to do something unless specifiacally granted access.

[@berndeckenfels]

Java struggles greatly with de-ser problems. After the BH talk there have been a few fixes (that’s a story of fails all by its own), but the last fix (which is not on by default) was from April 2021 with com.sun.jndi.ldap.object.trustSerialData=false that one would help against RCE and should probably be used in every JVM by default.

[@Time4Technology]

Very good video! I thought it would be the same I've seen already multiple times, but this gave great insight about interesting historical points and raises awareness for the gap between development and security research.

[@srki22]

Serious companies have their servers in VPC without internet access (except inbound connection through some ports) so their servers cannot access a radnom site on the internet that had a malicious code.

[@Tarodenaro]

Is anyone find the utmost irony by the fact that "Oracle totally not seeing this coming" part?

[@iodar]

THANK YOU so much for talking about opt-in. I am still confused as to why this is a default setting in a logging library.

[@Meskalin_]

the space between the %m and %n physically hurt me

[@TimLF]

Why anyone using log4j instead of the jdk logger idk, seems like bloatware needlessly increasing attack surface.

[@wolfymaster]

You couldn't have discussed the gap between dev and security any better. Been following your channel and other security folks for years, but as you said, there's a lifetime of information and research I wish I had time to learn - but my day to day is on the dev side.

[@pranavkrishna4413]

the small liveoverflow was creative :')

[@AbdelrahmanRashed]

2016 : Applications should not perform JNDI lookups with untrusted data. 2021 : JNDI lookups go brrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr Guys I think we are evolving backwards, aren't we ?

[@freesoftwaretalk]

did you even watch the video? He actually addressed exactly this.

[@AbdelrahmanRashed]

@@freesoftwaretalk this is just a joke about the situation we are in right now. Also I don't like to shift the blame but I think this is 90% log4j team fault. And yes I watched the video ofc

[@marcellkovacs5452]

@@AbdelrahmanRashed 2013 comes before 2016

[@Leeengold]

What I do not yet understand (Im not in CyberSec) is how this can actively be used to attack your system. E.g. I play a minecraft version with with the vulnerable log4j version, how can the attacker induce a log request with his malicious JNDI request?

[@VeshrajGhimire]

Your contents are always unique and full of indepth knowledge Best content creator out there, lots of love!❤️❤️

[@atpray]

Open source does not mean secure. It is a big misconception.

[@RedStone576]

can agree

[@MM-mh6nv]

Great job sir! I'm loved to share this with my colleague. May I know when will be part 2 available? I can't wait for it😆

[@edgeeffect]

I'm a server-side developer (in Python/PHP/Ruby... not Java) .... surely the only advice for developers is to not use untrusted data for ANYTHING apart from validating/sanitizing that untrusted data into trusted data? Or am I still missing something?

[@WolfrostWasTaken]

I saw A LOT of enterprise Java projects absolute and utter BS with SOAP shit with WSDL 13k lines long. I can assure you that boomer """"programmers"""" LOVE to not think about anything when programming. They LOVE IT. And they will not stop. Actually, let me formalize my thoughts a bit better, especially in relation to what you said at the end of the video. How can we join the worlds of cybersecurity and software engineering? The problem is that, in the case of Log4J, everyone uses it just because "it's convenient" (the exact same reasoning that leads to sending entire Java objects through the wire, something sooooo utterly insecure I have no words to describe it). Convenience should be security-enabled BY DEFAULT, and that's the responsibility of both designers of libraries and users of libraries. If something goes wrong, the fault can be found from both parties... Convenience over security is what ultimately leads to catastrophic vulnerabilities. The pattern is always the same. So we should give up a bit of convenience in pursuit of better software security and, ultimately, to better software in general.

[@berndeckenfels]

The lookup for JNDI is not only (seldom?) used to lookup strings to log, but it can also be used in log4j to get things like jms message broker .. this is the part which is still present (behind a new switch enableJNDI)

[@yutubl]

What can we learn from this CVE-2021-44228 Log4Shell? 1.) Know your tools and libraries and configuration with respect to functionality, safety and security, and improve the knowledge with teamwork or consulting expierienced experts. As far as I understood this CVE-2021-44228 log4shell/log4j & other youtube videos - I expect this type of security issue may arise again in future outside of Java/Log4J/JNDI with not java releated different programming frameworks, languages environment as the basic key point was network LDAP storage and how it can be used from applications. 2.) Old outdated tools, libraries may lead to complexer software environments than small lean development teams can handle efficiently, this also may be with over-engineered standard software and their complex environment configuration and documentation gaps, 3.) Writing own lean software w/o complex libraries & environments can be a security benefit, if you know what you do: how to design appropriate software architecture, implement and test your own software product.

[@khaledgaber8730]

I have one question, after the JNDI Blackout talk, this issue was totally resolved in 2018 by disabling the RemoteClassLoading, so how is still happens till 2021. I don't get it, can you explain why?

[@atol71]

I just wonder if the log4j library has been used by Oracle (sic) developers in java JVM(JDK) development and has the whole Java ecosystem been compromised? Maybe? Eh? Could it?

[@timelessnesses]

**Log4shell exists** Developer program their program using java and using log4j for logging: OH FU- Another dev but they made offline program: haha get f*cked u can't get me >:) Another dev with another programming language: haha I will be a good spectator and I will watch this mess.

[@tswdev]

At 16:28, we can resolve the issue by having automated tools that scan the code base for known problematic patterns. I know this exists already for pip/pipenv (?), npm (?) and for a few things within docker images. But its not very widespread. IDE support for such scans would go a long way. Known anti-patterns or insecure code points could be handled. Correct me if I am wrong, but I think I have seen warnings about using `eval()` for example in JetBrains IDEs but less obvious points are usually overlooked because there is no (afaik) tool that automatically scans your code for such vulnerabilities in IDEs.

[@conceptrat]

Have I missed something here. Surely Log4J should be sanitizing the incoming message. Isn't this somewhat equivalent to how SQL Injection attacks work and the mitigation was to not accept a direct SQL statement. On top of that having a URI whitelist for the actual JNDI call would have also been pertinent. Or is that what you mean by Security Research failed Software Engineering?

[@Praecantetia]

What I don't get is why they made log4j public. They could have kept it secret and we may have never known for years!

[@lucrativelepton]

Why can't devs stop sending whole objects over the wire? JavaScript's eslint will yell at you if you try to use `eval`, which can be like the object deserialization in Java. "Eval === evil" they say, and we just don't do it. So what's the holdup?

[@samsingh7025]

Loved the Announcment in the beginning

[@jacoblessard8213]

Overflow I love your videos and your explanation on this but actually, this vulnerability has been thought to have been being used secretly by certain people since 2013.

[@LiveOverflow]

Source?

[@jacoblessard8213]

@@LiveOverflow There are a handful of people that just think/ have said this in general but here's one of the sources kzbin.info/www/bejne/pouUiKihnbh-jNU @1:20

[@LiveOverflow]

There is nothing? The person just said the vuln was in the code since 2013. Not that somebody knew about it since 2013

[@jeffvalore5010]

IMO is this an example of poor library design and understanding of basic security concepts. The log messages should not be having replacements performed on them in Log4j at all. The log format in configuration (the "pattern") could specify replacements, but not the individual log messages, which are usually going to contain user-entered/untrusted data. People worked on this library for this long and never thought that having special processing syntax in what is passed to logger.info could eventually be exploited?

[@PandaMoniumHUN]

IMO the real issue here is that Log4J developers decided that lookups should be enabled by default. This is yet another example of never-ever trust user input. If I was using a logging library and logging request information (eg. for debugging purposes), I’d never expect my logger library to parse parameters passed to it.

[@MarkusGeiger]

I tried security bugs as software bugs so every developer should take them serious. Problem is security tower teams at corporations. And corporations and the high abstraction of java: I'd say C or Python developers look more into what a library does. Enterprise monkeys just push to the have the job being done by some "enterprise class" library. And the add the funding of open source projects: only prestige projects do get funding. In the end: no serious java developer would use log4j now days since java has now own good log classes or people use Kotlin etc. But well, enterprises are not always up to date... and if #1 priority is money you try to slay security problems with money as well. Who cares about devs with a burnout after some weekends of log4j hell? Just my 5cents.

[@MrFun23]

I don't agree with the "We failed devs" comment. I'm a software developer myself, but I come from quite a hardcore academic background, I was studying robotics and automation for my bachelor's and machine learning for my masters. And one thing I know for sure is that it's just hard (impossible?) to be good in multiple different fields. Let's take for example machine learning researchers who are incredible in math and, well, machine learning and they also happen to do some programming for their research, but let's be honest they are terrible programmers. But it's perfectly normal because we are all humans and we don't have all the time in the world to do multiple different things. It's just how the world works and for things like these to be discovered the starts must align correctly :D

[@paaao]

Bottom line, the world is full of sooo much data, code, methods, processes, build ons, add ons, inter ops, conversions, etc... that things like this will always go unnoticed for a long time. The NSA, and every other govt is literally paying people half a mil a year to do nothing but sift around through the boring details, and crawl through the trenches of the latest fads, to build their treasure troves of exploits just like this. If you want security, remove every feature except the ones you absolutely need. Then remove at least 1/4 of those, and find a simpler, but maybe more labor intensive, way to do what you need to do. Not what someone wants to do. Not what makes the profit line rise 2 bucks. Now you're on the right path. Problem is, you'll have every manager and CEO shit canning you for being difficult, and not "streamlining" the operation. You're falling behind the curve, they'll say. So onto the security hole treasure hunt. There's bags of goodies out there for the taking. Play the development game, and see how bad it really is out there. The treasure trove will literally fall into your lap.

[@starmoonxy]

Hi Fabien, you mentioned that the vuln wasn't discovered through Minecraft's bug bounty program as the internet popularly believes; how was it then discovered?

[@xxGravitonxx]

Great video but switching from a very dark image (facecam with background) to a very bright image (website with white background) is very painful to watch

[@nfuryboss]

Alibaba got into trouble for reporting to Apache first about the Log4J exploit bug instead of Chinese's government security agency. Suspension for 6 months.

[@DNinjaDave]

An example lookup that you might to with log4j ldap is if your incoming windows username is something that doesn't relate to the user like "corp54237" you might use an ldap lookup to grab the users display name from AD and log that along with the random username they are assigned.

[@zyxzevn]

Similar developers that made: while(1){ char str[50]; gets(str); printf(str); };

[@kasuha]

While technically it is JNDI vulnerability, the fault on log4j side is that it does lookup parsing on potentially untrusted data. If nothing else, it allows users to scramble the log messages beyond recognition. I can understand the simple input was carried over from log4j v1 where it was still safe but SQL injection is a thing known for a long time so it surprised me they did not give parsed input a new method instead.

[@inao-cz]

There are two more CVEs for Log4J after CVE-2021-44228. Both of them are high on CVSS in severity.

[@johannes-vollmer]

If not every structural information was crammed into a string, it would never have been an issue - why "message [%d]" instead of

[@Yotanido]

It should not have been doing any kinds of lookups, in my opinion. That person that asked for an option to disable lookups should never have been there. If you want to have lookups like that, separate format string and data - don't allow data to be interpreted as a format string. You see exploits involving format strings all the time. Usually because developers use format strings incorrectly and pass in untrusted data, but in this case there wasn't even an option for doing it correctly, was there? Note that I am not blaming developers who use format strings incorrectly. It's confusing and the danger is not very apparent. I personally really like how in rust, format strings are required to be a string literal. You can't pass variables in. You can't replicate this in most languages, but... it is a very nice feature.

[@guiller2371]

It took so long because nobody bothers to understand libraries or reading documentation before using them, because they are so many. People simply download everything and follow quick tutorials.

[@NonTwinBrothers]

Thanks for having subtitles

[@KrzOstr]

I really liked your video and I thought: sounds like a German accent... checking imprint and realizing that it is the same zip code as mine 2 months ago :D Greetings to Lichterfelde!

[@m4rt_]

15:35 I'm a developer and hacker :) (I'm leaning development in school, and learning hacking in my spare time)

[@tomasalbertomunozpoupin1522]

I think apart of having an IT security department, a security expert should be a part o every developer team. Security beign so important this days, it would bring that knowledge more close into the development process

[@kbhatt2762]

Excellent. Loved the timeline and your research. Really informative. Thanks a lot.

[@ManiKandan-zh3nv]

Simply explained in perspective of usecase and its timeline awesome

[@jrcarreiro]

Awesome. Where I can find those pdfs files? (Network Programming)

[@shapelessed]

First thing about security in web dev is that you do NOT evaluate unsanitized and untrusted code... You'll be shamed for the rest of your like if you do it.

[@activeturtle770]

Is it just me or his videos are becoming darker XD Darker literally. Not figuratively.

[@niklas3128]

Wait wait wait hold up 🛑 How do they all know about the ldap server tho? 💀

[@exoooooooo]

"Copy and Paste what other people's already written about and repackage it in the video form" this reminds me to the channel that create video about bug bounty report lmao

[@danielsonski]

We, programmers, often need to do some hacky things in order to get stuff running, because security makes it harder... (yes, that's a strange sentence)

[@KvapuJanjalia]

Laughing at log4j will get your comment deleted. Why are you so thin-skinned?

[@mr_daihatsu]

So what if this was just left alone to be exploited by the "community" [state sanctioned] for certain operations

[@nilanjenator]

Why does the thumbnail have 'Hacker vs Developer' (Haven't seen the whole video. )

[@krzysztoflewandowski8262]

CVE-2017-5645 was around 2017, same issue

[@maycodes]

This is the best explanation of Log4j on internet ! thanx, - mern Developer

[@Spiderboydk]

I disagree that the entire blame is on the security community. Cooperation takes at least two parties, so neither party is completely guilt-free.

[@NoBody-tz4fb]

Dev guys don't know shi$& about security, usually.

[@daodemocracy6200]

incredible work! you are a true journalist. now, DAO will take this issue.