I love how you actually demonstrate the vulnerability and not just talk about it, like what most others are doing. Keep it up mate, you've got my Subscribe!
It's my first week working in cyber security environment professionally. Trying to get a grasp on my organization's infrastructure while trying to help with the log4j vuln has been a real trial by fire lol. Always enjoy your content!
I understand. I just joined a new org as part of the infrastructure team. I still don't know all our systems, but I'm learning fast as I help to find and patch systems as needed/available.
The ${…} syntax is not part of Java - it’s solely a Log4j syntax. (If it were part of java there would have been no problem, as it would have been evaluated at compile-time, not run-time)
@@kpaxxapk6397 In theory, it's a fair point - it certainly would be possible to sanitize it. But 1) the documentation did not state this anywhere afaik and 2) no one is interested in having a logging framework where you have to sanitize everything. People just want to do "log.error("My error: {}", error)" and be done with it. I've used Log4j before some years ago, and never knew about that "Lookup" feature - and aparently i was not the only one. :) Imho, it was a very annoying feature, security flaw or not, as i don't want the text i log to sometimes be transformed into something else, just because it happens to contain "${" and "}"... And this undesirable feature was enabled by default...
@@kpaxxapk6397 Note: It would kind of be possible for Log4j to sanitize it itself... If they forced you to use it in a specific way... You CAN (but don't have to) use the logger as having a format string as first param, and then data-values for the rest of the params (similar to printf, etc)..: log.info("This is the format string. Data is {} and {}", data1, data2);
@@zaitarh This RCE was a feature, not a bug, I saw the code, it was done intentionally, I'm sure someone added this feature on purpose to use it for what the video showed us.
I can't believe that it is that simple. The first thing you learn is always to control the input that is given. That is why you wont just take the given SQL command and execute it. To think that log4j didn't sanitise their input ist just CRAZY. That's a one liner, my god...
Words cannot describe- how did this slip unnoticed? I cannot imagine writing code that would result in behavior like this, and yet it must surely be a trap even experienced developers might fall into.
@@maxwellmapako3820 This is like a classic example of unsanitized input. Idk how any experienced developer like those working with the Apache Foundation couldn't expect that.
What coding tool are you using here? What do you reccomend for people learning code? It's very interesting watching everyones reaction and discovery of this vulnerability.
Just started a new job, and moved my support area from networking to applications. Day 1 of the new gig and I was hearing it was an all-hands to deal with the "new vulnerability". Thankfully new enough that there was no headache for me to deal with, but oof, glad to see what they were up against!
I'm still confused about how the jndi payload gets executed (i.e. calc.exe) in this case - isn't the jndi lookup just returning data? what is it that makes it actually execute calc.exe??? nobody seems to be able to explain this.
As I've understood it, it's basically a "hook" and the intended functionality of log4j which says: take this url, load the object/function there and run it. So the reason it is run is because that's how it was supposed to be. It's not the malicious code itself that says that it should be run. But I may be wrong here.
To answer your question: yes. everything in here is data (even this video itself), eg: Y2FsYy5leGU= is calc.exe in base64, that is the resource is loading thru JNDI and passed it to the log4j logguer as a variable to be logged. I think that is clear enough, hopefully for you too. Cheers!
I actually worked with programs that use log4j, and found it clunky and cumbersome to use with the programs I was delevoping. I didn't know it was so widespread. So is this bug like that xckd comic about Robert"); Drop Tables Students? Because it sounds like it.
More like xkcd 2347: Dependency. All modern infrastructure is built on a project someone thanklessly maintains in their free time :( And this vuln vas known as far back as BlackHat 2016.
@@demoniack81 it's been a while so I forgot the details, but whatever logging setup we had just did not work properly when we updated log4j, and a lot of the log messages had to be rewritten or changed just so the files would be generated and logged to. And my company had this overly complicated standard that log messages had to follow but didn't quite tell us how to make it display properly with log4j - when the older system was already doing so. So many bugs that were "this log is not displaying the error message properly", and I'd have to track down and fix it because there was some variable that needed updating.
In short, Log4j is a Java library that is used for logging errors and other software activities. ... The exploit lets an attacker load arbitrary Java code on a server, allowing them to take control.
when I try to do same thing in my eclipse using log4j < 2.16, the jndi url is not getting invoked. It is simply printing in log message.. Any clue why ?
Hello, i am just curious. I have a statement and would like to know if my logic is correct. The vulnerability is caused due to no input checking in the program, allowing unintentional interaction with the user? Is this a correct way to view this or am i way off base?
To be clear, it's the log4j logger that is doing the ${variable} expansion, and not the shell (?) e.g., if you print out username within the code it is not a problem, but log4j is (somehow) executing it ? Thanks!
I still don't get it. What is it that is being returned over LDAP? Is it the base64-encoded string "calc.exe"? Is it a Java object which is doing Runtime.getRuntime().exec("calc.exe")? It's been nearly a week and I still don't get it!
So you're telling me that the Log4j vulnerability is roughly the same as there was with linux a while ago where if you put something like [{:}};} (don't remember the exact spelling) you can then enter a command that can be executed from an app or the other thing that happened to twitter where you could send a tweet that would retweet itself in your browser... Why is it always the same vulnerability that is found?
Great. Now show the LDAP server configuration and how exactly it serves the java object payload. None of the videos seem to explain how that works. They either evade it or use marshalsec LDAP server also never explaining how it works.
Hi Marc, great video. If I see it right, the outbound connections to e.g. a LDAP server is always unencrypted since JNDI does regular (unencrypted) lookups. That means that companies could look for unexpected outbound LDAP requests to servers on the internet right? Just curious. Would there be a way to make these outbound requests encrypted? Thank you!
Those ${variable} sequences aren't actually handled at the Java level, they're at the log4j level and they're called "lookups" if you want to find documentation or anything.
how did you manager to get a Java lookup accepted on the commandline? When i enter ${java:version} it is evaluated on the CLI leading to no value, leading to an java.lang.ArrayIndexOutOfBoundsException in the java program.
I'm only there 1:00. And I can tell that knowing this is how it works, this is not a library I would use by any means. I don't want unintended random string parsing happening randomly in my code.
Coming from a C++ background, I can't see why the code in "username" gets evaluated. Is it because log4j triggers this evaluation somehow ? Why would it do that ?
correct, log4j evaluates the variable that is wrapped around by ${...} (its own syntax for string interpolation). That and combined by some remote JNDI lookup/mechanism within the library itself, a feature that they claimed were needed for backward compatibility purposes (??). Note that JNDI is a standard in Java that allows remote object load/lookup (!!).
Great video. Question, so is the problem that even though log4j stores that command string in a log file it gets executed while being written to the file?
3 ปีที่แล้ว +5
thanks for the explanation, going to make a documentary on this!
good explination. told exactly what it is and how it works. yeah i know what im looking at already but for anyone else that has no idea, this is the video they should watch
Nice demonstration, but the code is unreadable on a medium-sized smartphone like mine. Please consider zooming or increasing the font size before uploading.
hi can anyone help me when i try to inject any executor in any game it says "This exploit is down while critical ace/rce vuln is fixed" this is on roblox btw
I know I’m late to the party but I would greatly appreciate it of someone could clarify some things for me: 1) that error at the end, I cant quite catch it but I figure it must be due to the fact that the downloaded object cannot be concatenated without a toString method or something like that? 2) Isnt that base64 ‘calculator.exe’ just a directory on your server, not part of the actual object? 3) what is that on line 8? Is setting that property necessary for this exploit to work? Again, I appreciate highly any response :)
I have to ask, what happens if you are running a VPN? Will the VPNs server get infected with whatever malware/ransomware/trojan/ddos/worm a black hat sends their way?
Actually, I want to know how this was still a vulnerability in the first place. It should be pretty obvious that ${...} is a bad thing, especially combined with jndi. It just makes me wonder how they did not think of this before.
Exactly. If I knew about this feature of log4j (I dont do java), it would immediately raise concern. String templates (format strings, f strings, etc.) should NEVER be evaluated by the program itself.
i am somewhat of a beginner programmer but i am so glad i'm able to understand so much words. back when i didnt know anything about programming, this entire video would make no sense to me at all but now, instead of simply not understanding what he says, i just... just fucking feel bored i mean like it's awesome vulneratbility which i could use to run rick astley video on somebodys PC or something, but i am not programming such stuff. . . i am simply not programming at all, the only experience i had was in unity
The vulnerability has been around for approximately 9 months - check twitter… likely an intern raised at a standup at one of the fang companies and all of a sudden everything is on fire… also the term you’re looking for is string interpolation, which is a conman programming term ;)
No, the issue IS the logger. This vulnerability does not exist if you simply print to stdout with the basic Java functions. No one expects a logging library to be WORSE at handling user input than a basic call to System.out.println(). I'm frankly astonished that *anyone* could have ever thought that allowing a JNDI lookup _in a freaking log message_ was a good idea, even just from a performance standpoint. How this got out into production will forever be a mistery to me.
@@demoniack81 The real problem is that we can't even count on professionals to be aware of the issues in the OWASP Top 10. Careless handling of user input is playing with fire. In log4j 2.17.0 careless handling of user input is still playing with fire. If you log using println careless handling of user input is still playing with fire. Log4j just happened to be the thing that enabled developers that play with fire to burn themselves this time around. It won't be the last.
This seems like a problem with the user of the library, not the library itself. You should be using `log.error("Hello: {}", username)` not `log.error("Hello: "+ username)`. This is analogous to SQL injection... You need to properly prepare you parameters.
It's quite a good video but I think you should have talken about the jndi/ldap breach that enable rce. Jndi/ldap basically doesn't allow to inject malicious code, but a breach form 2017 make it possible to inject and initialize a custom Java class the ldap server redirects to
Great demonstration, Marcus!
U got 1 subscriber
hey john
@@anuzravatMore like 1.2million
You saying "just came out a few days ago" makes it sound like a fun new game just got released haha
Yeah lol, I just realized that 😂
🤣🤣🤣🤣🤣
Tbf for us security professionals this is basically like a new game was just released 😂
@@-bubby9633 🤣🤣🤣
😂😂
I love how you actually demonstrate the vulnerability and not just talk about it, like what most others are doing. Keep it up mate, you've got my Subscribe!
Yup, learnt more from this than the over engineered blogs I've been tracking!
not to mention how he only did it in ~3 mins, saves a lot of times for such a great explanation
It's my first week working in cyber security environment professionally. Trying to get a grasp on my organization's infrastructure while trying to help with the log4j vuln has been a real trial by fire lol. Always enjoy your content!
I understand. I just joined a new org as part of the infrastructure team. I still don't know all our systems, but I'm learning fast as I help to find and patch systems as needed/available.
Welcome to the industry and good luck!
@@complexedone Good Luck. We will get there eventually!
what have you been doing to help? what's your role? i'm looking to start in security soon!
Best way to learn quickly though. This is a blessing in disguise for you!
Clicking various links for 30 minutes, trying to understand the issue, and you explain it in less than 4. Thank you!
With videos out there in 20+ mins and you here with less than 4 mins explaining it so clearly, I know which video to click from next time.
Thanks Marcus. I appreciate your ability to explain a vulnerability like this and demo it in a really understandable way.
First time understanding what this means. Thanks.
Finally no bullshitting around. Straight to the point and understandable for every novice programmer
the variable thing in a string is called string interpolation my dude!
The ${…} syntax is not part of Java - it’s solely a Log4j syntax. (If it were part of java there would have been no problem, as it would have been evaluated at compile-time, not run-time)
@@kpaxxapk6397 the logger should sanitise the input the same way an ORM sanitises model insance lookups to avoid SQL injection.
@@kpaxxapk6397 In theory, it's a fair point - it certainly would be possible to sanitize it. But 1) the documentation did not state this anywhere afaik and 2) no one is interested in having a logging framework where you have to sanitize everything. People just want to do "log.error("My error: {}", error)" and be done with it.
I've used Log4j before some years ago, and never knew about that "Lookup" feature - and aparently i was not the only one. :) Imho, it was a very annoying feature, security flaw or not, as i don't want the text i log to sometimes be transformed into something else, just because it happens to contain "${" and "}"... And this undesirable feature was enabled by default...
@@kpaxxapk6397 Note: It would kind of be possible for Log4j to sanitize it itself... If they forced you to use it in a specific way... You CAN (but don't have to) use the logger as having a format string as first param, and then data-values for the rest of the params (similar to printf, etc)..: log.info("This is the format string. Data is {} and {}", data1, data2);
@@zaitarh This RCE was a feature, not a bug, I saw the code, it was done intentionally, I'm sure someone added this feature on purpose to use it for what the video showed us.
No idea why I always assume the ${...} syntax is Spel from the spring spell syntax but I'm not 100% sure if that's correct or not
I had problem understand this from days and you explained it under 4 mins. You're amazing Marcus 👏❤️
I can't believe that it is that simple. The first thing you learn is always to control the input that is given. That is why you wont just take the given SQL command and execute it. To think that log4j didn't sanitise their input ist just CRAZY. That's a one liner, my god...
Greetings from Indonesia, I really admire you, and you are great. I'm just a beginner who wants to learn like you from the bottom
I work in IT and the last week or two has been absolutely mental thanks to this
Better than java brains log4j explanation,now i understand
Words cannot describe- how did this slip unnoticed? I cannot imagine writing code that would result in behavior like this, and yet it must surely be a trap even experienced developers might fall into.
I honestly believe that you cannot cater for what you don't expect 🤣
@@maxwellmapako3820 This is like a classic example of unsanitized input. Idk how any experienced developer like those working with the Apache Foundation couldn't expect that.
I was just thinking - this seems adjacent to our classic case of SQL injection. Crazy
Very well explained. Good video Marcus!
"versatile" is the key word for this vulnerability.
thanks for explaining! :)
Thanks for simplifying the vulnerability
Best summary yet
Awesome video! Quick question: What is the symbol you have on line 11 of your code just after "logger.error(" but before "Hello..."
It says "s:" and is inserted by the ide to let you know what the parameter's called
parameter hinting
What coding tool are you using here? What do you reccomend for people learning code?
It's very interesting watching everyones reaction and discovery of this vulnerability.
That’s IntelliJ ide
Loooove IntelliJ
if you learn with gedit and terminal you will be like Superman growing in Earth
Thanks for such layman explanation, I was able to grasp it..
'Drop bobby tables' for Java. Nice! Thank you for this.
Always cool to see a Marcus video out on a new vuln!
This is one of the great demonstrations I have listened on TH-cam. You are amazing!!
how does an attacker make the call in the first place though? (have access to call the function with the string
By controlling some input that gets logged by the application
Just started a new job, and moved my support area from networking to applications. Day 1 of the new gig and I was hearing it was an all-hands to deal with the "new vulnerability". Thankfully new enough that there was no headache for me to deal with, but oof, glad to see what they were up against!
This 4 minute video was more clear and valuable then the 30minute one i just watched on this rce
cough johnhammond cough
I'm still confused about how the jndi payload gets executed (i.e. calc.exe) in this case - isn't the jndi lookup just returning data? what is it that makes it actually execute calc.exe??? nobody seems to be able to explain this.
As I've understood it, it's basically a "hook" and the intended functionality of log4j which says: take this url, load the object/function there and run it. So the reason it is run is because that's how it was supposed to be. It's not the malicious code itself that says that it should be run. But I may be wrong here.
To answer your question: yes. everything in here is data (even this video itself), eg: Y2FsYy5leGU= is calc.exe in base64, that is the resource is loading thru JNDI and passed it to the log4j logguer as a variable to be logged. I think that is clear enough, hopefully for you too. Cheers!
How can you set up the LDAP server on localhost and which port to choose?
Fantastic demonstration!
I actually worked with programs that use log4j, and found it clunky and cumbersome to use with the programs I was delevoping. I didn't know it was so widespread.
So is this bug like that xckd comic about Robert"); Drop Tables Students? Because it sounds like it.
More like xkcd 2347: Dependency. All modern infrastructure is built on a project someone thanklessly maintains in their free time :( And this vuln vas known as far back as BlackHat 2016.
How dooes one find log4j "cumbersome"? It's literally one jar and one .properties / .xml config file and off you go.
@@demoniack81 it's been a while so I forgot the details, but whatever logging setup we had just did not work properly when we updated log4j, and a lot of the log messages had to be rewritten or changed just so the files would be generated and logged to. And my company had this overly complicated standard that log messages had to follow but didn't quite tell us how to make it display properly with log4j - when the older system was already doing so.
So many bugs that were "this log is not displaying the error message properly", and I'd have to track down and fix it because there was some variable that needed updating.
One of the best explanations with practical demo. Thank you ..
Thank You Marcus, simple but quiet clear to understand
Can u also input a lambda?
Could you solve this issue by looking for an outcommenting the feature in the log4j library?
In short, Log4j is a Java library that is used for logging errors and other software activities. ... The exploit lets an attacker load arbitrary Java code on a server, allowing them to take control.
when I try to do same thing in my eclipse using log4j < 2.16, the jndi url is not getting invoked.
It is simply printing in log message.. Any clue why ?
Maybe I'm overlooking things but it seems so obvious. How did this vulnerability take years to discover?
Its not a part of java as somebody mentioned before. The syntax is kind of string interpolation though.
Hello, i am just curious.
I have a statement and would like to know if my logic is correct.
The vulnerability is caused due to no input checking in the program, allowing unintentional interaction with the user?
Is this a correct way to view this or am i way off base?
just what am looking for....thx dude
Nice explanation, I believe showing how easy it is to do is the scary part more than anything since a lot of applications use log4j.
Thanks for the demo. May i know what will be the parent process of "calc.exe"? would it be "java.exe"?
Yup, it'll be the java VM
To be clear, it's the log4j logger that is doing the ${variable} expansion, and not the shell (?) e.g., if you print out username within the code it is not a problem, but log4j is (somehow) executing it ? Thanks!
Correct
I still don't get it. What is it that is being returned over LDAP? Is it the base64-encoded string "calc.exe"? Is it a Java object which is doing Runtime.getRuntime().exec("calc.exe")? It's been nearly a week and I still don't get it!
Subbed. That was an excellent explanation.
So you're telling me that the Log4j vulnerability is roughly the same as there was with linux a while ago where if you put something like [{:}};} (don't remember the exact spelling) you can then enter a command that can be executed from an app or the other thing that happened to twitter where you could send a tweet that would retweet itself in your browser...
Why is it always the same vulnerability that is found?
Great explanation.
I just didn't quite understand one thing. Is it necessary for the object you are loading to exist in the ldap server ?
Yes, but as the attacker can point the lookup to an ldap server they control, that's easy to arrange.
How to fix the issue any steps are there
Great. Now show the LDAP server configuration and how exactly it serves the java object payload. None of the videos seem to explain how that works. They either evade it or use marshalsec LDAP server also never explaining how it works.
Isn't it somewhat similar to SQL Injection?
Hi Marc, great video. If I see it right, the outbound connections to e.g. a LDAP server is always unencrypted since JNDI does regular (unencrypted) lookups. That means that companies could look for unexpected outbound LDAP requests to servers on the internet right? Just curious. Would there be a way to make these outbound requests encrypted? Thank you!
Those ${variable} sequences aren't actually handled at the Java level, they're at the log4j level and they're called "lookups" if you want to find documentation or anything.
how did you manager to get a Java lookup accepted on the commandline? When i enter ${java:version} it is evaluated on the CLI leading to no value, leading to an java.lang.ArrayIndexOutOfBoundsException in the java program.
This explanation is so cool! I’ve been hearing about the vulnerability but nobody took the time to explain it this way. Thank you! :)
In regards to 0:46, this is called string interpolation :)
I'm only there 1:00. And I can tell that knowing this is how it works, this is not a library I would use by any means. I don't want unintended random string parsing happening randomly in my code.
clean explanation marcus!
Coming from a C++ background, I can't see why the code in "username" gets evaluated. Is it because log4j triggers this evaluation somehow ? Why would it do that ?
correct, log4j evaluates the variable that is wrapped around by ${...} (its own syntax for string interpolation). That and combined by some remote JNDI lookup/mechanism within the library itself, a feature that they claimed were needed for backward compatibility purposes (??). Note that JNDI is a standard in Java that allows remote object load/lookup (!!).
Great video. Question, so is the problem that even though log4j stores that command string in a log file it gets executed while being written to the file?
thanks for the explanation, going to make a documentary on this!
Purchased botted sub account, ratio
Great, a whole documentary nobody asked for.
like si llegaste aquí por el video de german
Yo
And if I go to 2b2t from my phone, for example, will the exploit work on me?
(I play java minecraft on my phone)
Wow, that is a pretty glaring vulnerability. Amazing it's only just been discovered.
Isn't 1.8 not vulnerable from the exploit though?
Wasn't the base64 an extra indirection?
The class you're loading can't pop Calc.exe directly? 🙄
Nice explanation ! Thank you :)
Great job at presenting the vulnerability!
I wonder how many 0-day expoits out there in the open software.
well, well
that's really interesting
thanks for uploading!
good explination. told exactly what it is and how it works. yeah i know what im looking at already but for anyone else that has no idea, this is the video they should watch
Nice demonstration, but the code is unreadable on a medium-sized smartphone like mine. Please consider zooming or increasing the font size before uploading.
0:47 this is called „string interpolation“ and it‘s not a java-thing only
Great video! plain, simple and without bias.
hi can anyone help me
when i try to inject any executor in any game it says
"This exploit is down while critical ace/rce vuln is fixed"
this is on roblox btw
I know I’m late to the party but I would greatly appreciate it of someone could clarify some things for me:
1) that error at the end, I cant quite catch it but I figure it must be due to the fact that the downloaded object cannot be concatenated without a toString method or something like that?
2) Isnt that base64 ‘calculator.exe’ just a directory on your server, not part of the actual object?
3) what is that on line 8? Is setting that property necessary for this exploit to work?
Again, I appreciate highly any response :)
I have to ask, what happens if you are running a VPN? Will the VPNs server get infected with whatever malware/ransomware/trojan/ddos/worm a black hat sends their way?
${variable} is EL expression for server scripting. Looks similar with string interpolation from c# : $"{yourVarHere}"
Great explanation. And wow.
Actually, I want to know how this was still a vulnerability in the first place.
It should be pretty obvious that ${...} is a bad thing,
especially combined with jndi.
It just makes me wonder how they did not think of this before.
Exactly. If I knew about this feature of log4j (I dont do java), it would immediately raise concern. String templates (format strings, f strings, etc.) should NEVER be evaluated by the program itself.
How has this just came out? Seems like a pretty straight forward exploit? Was it a new feature of log4j or something that has existed for a long time?
Since 2013
0:45 don't know the name in Java jargon, but in Javascript this would be a Template literal / Template string.
great explanation and demo
i am somewhat of a beginner programmer but i am so glad i'm able to understand so much words. back when i didnt know anything about programming, this entire video would make no sense to me at all
but now, instead of simply not understanding what he says, i just... just fucking feel bored
i mean like it's awesome vulneratbility which i could use to run rick astley video on somebodys PC or something, but i am not programming such stuff. . . i am simply not programming at all, the only experience i had was in unity
Upgrading to 2.15/2.16 version of Log4J resolves this.
Thank god you didn’t title this “log4 in layman’s term”
Thanks Marcus! Sweet and clean explanation!
The vulnerability has been around for approximately 9 months - check twitter… likely an intern raised at a standup at one of the fang companies and all of a sudden everything is on fire… also the term you’re looking for is string interpolation, which is a conman programming term ;)
so basically its not the logger thats the issue, it's not sanitizing user input. thought this was learned from SQL injection
No, the issue IS the logger. This vulnerability does not exist if you simply print to stdout with the basic Java functions.
No one expects a logging library to be WORSE at handling user input than a basic call to System.out.println(). I'm frankly astonished that *anyone* could have ever thought that allowing a JNDI lookup _in a freaking log message_ was a good idea, even just from a performance standpoint. How this got out into production will forever be a mistery to me.
@@demoniack81 The real problem is that we can't even count on professionals to be aware of the issues in the OWASP Top 10. Careless handling of user input is playing with fire. In log4j 2.17.0 careless handling of user input is still playing with fire. If you log using println careless handling of user input is still playing with fire.
Log4j just happened to be the thing that enabled developers that play with fire to burn themselves this time around. It won't be the last.
nice demo, thanks!
thank you for this video marcus!!! alot of news on this and this has helped me out get a better understanding of how the vulnerability functions
Pretty much every security team in an organization is stuck on log4j meeting 😜 Wonderful explanation though of the exploit.
what terminal thing are you using where you can see both the application code and terminal? (Im a noob dont yell LOL)
thats the built in terminal in IntelliJ
When the calculator actually popped up, I laughed out loud.
Great great great video
This seems like a problem with the user of the library, not the library itself. You should be using `log.error("Hello: {}", username)` not `log.error("Hello: "+ username)`.
This is analogous to SQL injection... You need to properly prepare you parameters.
It's quite a good video but I think you should have talken about the jndi/ldap breach that enable rce. Jndi/ldap basically doesn't allow to inject malicious code, but a breach form 2017 make it possible to inject and initialize a custom Java class the ldap server redirects to
Everytime I look at these vulnerabilities I am always surprised by how seemingly simple they are. Computers are weird, man…