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.
@LiveOverflow2 жыл бұрын
thanks for the added info. You can see my java knowledge is kinda old :D
@vaisakhkm7832 жыл бұрын
@@LiveOverflow But your work is amazing..... 🤗
@Dragiux2 жыл бұрын
@@spotlightsrule If you can run kotlin, you can upgrade your JVMs. Stop whining.
@omri93252 жыл бұрын
@@Dragiux It's not whining, it's facts, Java 8 is heavily used even today.
@EskoLuontola2 жыл бұрын
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.
@CarlosVieiraCrowSec2 жыл бұрын
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!
@Noctuu5 ай бұрын
I agree with you, I hate how most of the videos show us a payload without explaining why the payload is working
@seanvinsick52712 жыл бұрын
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-highcritic2 жыл бұрын
adding a 2nd thumbs-up here
@soviut3032 жыл бұрын
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.
@bryan3972 жыл бұрын
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
@MarzJonp2 жыл бұрын
Facts!
@dzhimy62662 жыл бұрын
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-dw4py2 жыл бұрын
@Dzhimy really bro, in this world we need more expert on Cybersecurity... And better programmers that not do mistakes
@stevegremory38492 жыл бұрын
@@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-dw4py2 жыл бұрын
@@stevegremory3849 I mean, they should be more careful ... it won't be perfectly because nobody is perfect
@Mrx-dw4py2 жыл бұрын
@@stevegremory3849 but let's stop fighting, I just want to talk, have no problems
@stevegremory38492 жыл бұрын
@@Mrx-dw4py nah nah bro sorry if I gave the impression that i was out to fight lmao
@roberttuck47682 жыл бұрын
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.
@srki222 жыл бұрын
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.
@JojOatXGME2 жыл бұрын
> 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.
@TheCardil2 жыл бұрын
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-ds8oz2 жыл бұрын
Wow that's actually a brilliant idea. It should be integrated into static analysers.
@FlorianWendelborn2 жыл бұрын
These kinds of things already exist. Snyk for example
@srki222 жыл бұрын
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.
@DryBones1112 жыл бұрын
@@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.
@TheCardil2 жыл бұрын
@@FlorianWendelborn the scanners that exist only warn about confirmed vulnerabilities, not possible ones.
@falxie_2 жыл бұрын
Actually knowing why that feature existed in the first place is something I haven't heard anywhere else
@123gostly2 жыл бұрын
This was genuinely beyond what other creators shared. Thank you for helping us understand the timeline and giving a broader understanding of the issue.
@guiorgy2 жыл бұрын
Honestly, the best video on Log4J that I watched so far!
@TigerWalts2 жыл бұрын
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.
@wlockuz44672 жыл бұрын
Yep, SQL injection is the first thing I thought of when I saw the exploit, the feature really is questionable.
@LKRaider2 жыл бұрын
The assumption seems to be that logs are not returned/exposed to users and that macro expansion is useful for debugging.
@romeomungiu29322 жыл бұрын
log4j lookup is the new format string
@TheCardil2 жыл бұрын
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!
@lal122 жыл бұрын
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...
@pavelhoral2 жыл бұрын
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...
@hpsmash772 жыл бұрын
its beyond me
@hhvhhvcz2 жыл бұрын
it's basically spicy SQL injection
@pavelhoral2 жыл бұрын
@@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.
@GroovBird2 жыл бұрын
@@pavelhoral this is SQL injection if the RDBMS could be convinced to download arbitrary code and execute it.
@BatteryAcid11032 жыл бұрын
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?
@umlal2 жыл бұрын
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!
@THeMin10002 жыл бұрын
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.
@dorb13372 жыл бұрын
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 .
@magawla2 жыл бұрын
The best explanation I've ever listened to about Log4j.
@faran45362 жыл бұрын
Well the most critical 0 day explained by the legend himself.🤩
@danielmoreno17122 жыл бұрын
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.
@benargee2 жыл бұрын
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%
@rujotheone2 жыл бұрын
Pretty sure NSA and the likes used it in their ops.
@Ash_180372 жыл бұрын
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"
@TomWhi2 жыл бұрын
I love your well thought out and eloquent way of sharing these types of topics! It’s the best post-panic breakdown video I’ve seen so far.
@MajorNr012 жыл бұрын
And here I was, thinking that hosting a little Minecraft server for me and my friends WASN'T going to ruin christmas.
@wlockuz44672 жыл бұрын
I am a developer and your channel has helped me develop a security oriented mindset. So I sincerely thank you for that.
@mahmoodmir64182 жыл бұрын
Excellent video my friend, as a former developer and now a security consultant I totally understand where you are coming from and there is a huge disconnect. I already shared this with my colleagues and looking forward to your next video. This is probably the only channel that I'm subscribing after watching just one video. Thank you!
@HansLemurson2 жыл бұрын
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"
@davidhcefx2 жыл бұрын
Absolutely. And library developers should also collect feedbacks on how frequent a certain feature has been used, in order to align with user expectations.
@wolfymaster2 жыл бұрын
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.
@a_demain2 жыл бұрын
As usual my site points to you as the best high level and low level explanation of this threat. keep up the good work.
@philpelzer2 жыл бұрын
I'm an developer and i love your channel and videos, they always been an help to make my code more secure and make it almost first priority in the way how i build my software. Thanks and keep it up!
@jasonpraful2 жыл бұрын
By far the best in-depth log4j vuln. Video I've seen. Great job👌
@anticat8672 жыл бұрын
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.
@bandie91012 жыл бұрын
actually this template substitution happes in the parameters, not in the format string.
@VeshrajGhimire2 жыл бұрын
Your contents are always unique and full of indepth knowledge Best content creator out there, lots of love!❤️❤️
@Time4Technology2 жыл бұрын
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.
@arpeetrathi2 жыл бұрын
Confession - Even if there is well documented article , blogs. But the content which you provide with explaination has no competition.Its fucking best❤😻
@ryansamarakoon82682 жыл бұрын
When something like this goes down I'm at the edge of my seat waiting for your take. No-one can explain these exploits like you can!
@durgeshpachghare69012 жыл бұрын
After watching many videos, I found this to be perfect and easy to understand. Great content. Thanks a lot!
@neptunian75632 жыл бұрын
Great explanation of the vulnerability itself and the context involved. Congratulations on your content! It always exceeds expectations!
@shravankumarsheri67322 жыл бұрын
Been waiting for his comment on his vulnerability, as usual, he nailed with
@LordHonkInc2 жыл бұрын
I appreciate the sentiment of not wanting to just rehash old info, but for what it's worth, I think all information you're willing to share is valuable if only one other person benefits from it; with something as serious as this that should count even more. Like, I generally tend to keep my thoughts to myself most of the time because I keep thinking I'd just be stating something somebody else has already said, but then I have to remind myself of the times when somebody came to me and said "that was actually really interesting, I didn't know that." It might not be something big, but even just a different perspective on a well-known topic can be invaluable (for instance, this channel has done a better job explaining things to me than three years of computer science at a university did, if only for the way the information was presented; I remember that the concept of the stack really only really clicked for me with your brilliant 0x series [which is... geez, five years old already? man, time flies, huh]). So, in closing (and I'm sorry for writing an essay about a line from the first minute of the video) I'm happy to hear that you put a lot of thought into your videos - not that that wasn't obvious - but don't think that just because a lot of people talk about something, you don't have a valuable contribution to add. Thank you for coming to my TEDtalk. Tip your waiter.
@romanxyz72482 жыл бұрын
I don't know how many people tell you this, but you're an amazing teacher 👏
@ciberman2 жыл бұрын
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.
@marcoantonio76482 жыл бұрын
Always my best source for topics on this.
@dermasmid2 жыл бұрын
Please don't hesitate to make a video about anything, you are my go to when it comes to security
@manan52 жыл бұрын
your videos are the best for indepth knowledge. Thanks thanks and thanks! waiting for part 2!!
@samsingh70252 жыл бұрын
Loved the Announcment in the beginning
@smithwillnot2 жыл бұрын
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.
@hpsmash772 жыл бұрын
-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
@maycodes2 жыл бұрын
This is the best explanation of Log4j on internet ! thanx, - mern Developer
@pranavkrishna44132 жыл бұрын
the small liveoverflow was creative :')
@chrisrudd64142 жыл бұрын
An excellent breakdown of the Log4j vulnerability and helped me understand why it appears (at present) that only the java versions of this are vulnerable (Log4j has ports in several other languages)
@user-ko7oo2qg1g2 жыл бұрын
I was waiting for your video on Log4j. Thank you for making such an informative video again. Now waiting for part 2.
@landongaus19062 жыл бұрын
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...
@iWhacko2 жыл бұрын
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.
@simbaclaws_youtube2 жыл бұрын
I'm a dev and love your content. It teaches me a lot. Thank you, you're awesome.
@ManiKandan-zh3nv2 жыл бұрын
Simply explained in perspective of usecase and its timeline awesome
@OwO-.2 жыл бұрын
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.
Just want to point out how great that outro was. The look you gave your own two fingers making the peace sign 😂. Great video though, looking forward to the second part as a developer!
@brunoais2 жыл бұрын
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.
@HenriqueValcanaia2 жыл бұрын
Very nice video, provided enough context and an interesting POV! Loved the timeline!
@daodemocracy62002 жыл бұрын
incredible work! you are a true journalist. now, DAO will take this issue.
@aspuzling2 жыл бұрын
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.
@LiveOverflow2 жыл бұрын
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?
@aspuzling2 жыл бұрын
@@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.
@MrCh0o2 жыл бұрын
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"
@AdamFJH2 жыл бұрын
@@aspuzling That is why this mess is really the developers fault.
@ekfliu2 жыл бұрын
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.
@mvdrider2 жыл бұрын
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! 💪🏻💯
@kbhatt27622 жыл бұрын
Excellent. Loved the timeline and your research. Really informative. Thanks a lot.
@danieltaylor41852 жыл бұрын
As a developer, I didn't know that this was a thing that could happen. I thought to myself, when learning Java, "Surely, this wouldn't allow for arbitrary code execution by default. Why would they do such a silly thing?" I had been inundated with the latest web frameworks like Spring, which have built-in features to prevent security vulnerabilities that make SQL injection attacks easy. But, much to my shock, I would have no idea that someone wouldn't have thought of this while developing log4j. It shows that, even though I've been working in this industry for years, there are still things to learn.
@evildead78452 жыл бұрын
Thank you for giving in detailed explanation on this! You are doing amazing work! I am novice in security domain and wanted to understand why this is "fire". Waiting for part 2 :D
@lo0s3_labz2 жыл бұрын
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.
@kovactac90732 жыл бұрын
This is great you went into lower detail this was what I was stuck on thanks for this.
@KrzOstr2 жыл бұрын
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!
@daggerone33702 жыл бұрын
I love Michael Zera's cyber security lessons
@NonTwinBrothers2 жыл бұрын
Thanks for having subtitles
@tomasalbertomunozpoupin15222 жыл бұрын
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
@LourencoAlvesPereira2 жыл бұрын
Flamegraphs-like in editing videos are impressive excellent!
@hjblokland2 жыл бұрын
Great video, well summarized. thanks!
@vauhner812 жыл бұрын
Excellent breakdown! Thanks!!!
@jozefwoo80792 жыл бұрын
Waiting for part 2! 😊
@iodar2 жыл бұрын
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.
@berndeckenfels2 жыл бұрын
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)
@steefant2 жыл бұрын
+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.
@MM-mh6nv2 жыл бұрын
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😆
@quentinlauterbach2 жыл бұрын
awesome video! I'm really excited for the next one aswell
@electoprogressivetv2 жыл бұрын
I really appreciate your effort and your simple explanations
@PandaMoniumHUN2 жыл бұрын
306 pages of documentation for a logging library. That should be enough to realize something is awfully wrong and to never touch the library.
@pvic69592 жыл бұрын
yelled at for not writing docs, yelled at for writing too detailed damned if you do, damned if you dont LOL
@inao-cz2 жыл бұрын
There are two more CVEs for Log4J after CVE-2021-44228. Both of them are high on CVSS in severity.
@mayach50922 жыл бұрын
Kudos to Alvaro and Oleksandr!!
@rockjhonson9202 жыл бұрын
did expected you would make video on this
@unutilized2 жыл бұрын
Thank you for such a thought out video
@johntera49582 жыл бұрын
i'm so hype for part 2
@bernardcrnkovic37692 жыл бұрын
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...
@bernardcrnkovic37692 жыл бұрын
Remember folks, separation of stateand logic in code is essential (I know, completely opposite of what you were taught at UNI in OOP classes 😁)
@bracco232 жыл бұрын
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.
@DelusionalLogic2 жыл бұрын
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.
@djthdinsessions2 жыл бұрын
This was engineered long before even microservices was a thing. But yes, that was a very idiot idea 😅
@vaisakhkm7832 жыл бұрын
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...
@logiciananimal2 жыл бұрын
Thanks for trying to bridge the gap between development and security - us in application security have to wear at least two hats, and it is very hard to do this!
@vasiliskonstantinou85772 жыл бұрын
Exelent video! Can't wait for the next video.
@nouai2 жыл бұрын
Totally agree that all not necessary / not essential features should be disabled by default.
@bernardcrnkovic37692 жыл бұрын
Brilliant breakdown, cool video as always 🔥
@srki222 жыл бұрын
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.
@kasuha2 жыл бұрын
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.
@DNinjaDave2 жыл бұрын
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.
@strouja2 жыл бұрын
Thanks for this, even though I read about this vulnerability and watched other videos on this, this was very very helpful and informative. Great job. Thanks again or I should say Danke sehr!!!
@casperes09122 жыл бұрын
I am indeed a developer. Generally not Java anymore, but it's nice keeping up with security and of course trying to follow security best practices :)
@berndeckenfels2 жыл бұрын
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.
@arwahsapi2 жыл бұрын
This alerts me that security hole is as dangerous as radioactive leak and must be treated with extreme cautions
@yutubl2 жыл бұрын
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.
@parthparmar23372 жыл бұрын
This was the first video where I actually learnt something and things didn't went off my head :)
@Tarodenaro2 жыл бұрын
Is anyone find the utmost irony by the fact that "Oracle totally not seeing this coming" part?