26 ms·
Third High Severity CVE in Log4j Is Published
- tomohawk 5y agoIt's been a minute since I primarily developed in Java, but back then we had switched away from log4j in favor of slf4j / logback. These were written by the author of log4j. We switched because they were significantly simpler than log4j. Switching over merely involved changing the jar files we used, and redoing the config.
- nimrody 5y agoIt's amazing that this library is used by so many large enterprises yet none of them made an effort to thoroughly audit the code (actually, it looks like Alibaba reported the first one. But the point stands that the code was used for so long and by so many.)
- hirako2000 5y agoEach enterprise doesn't only use this common library, it uses a few more hundreds. If the point of pulling libraries is to save tremendous time in not having to write them, I can assure you managers aren't keen in wasting their gains in looking deeply into what's inside. Spotting the flaws, even with careful reviewing is still unlikely to happen, and would benefit the community at wide over their selfish interests.Enterprises use of open source doesn't adhere to the open source étiquette.
- marcus0x62 5y agoNot only are they not interested in spending time auditing code, your typical enterprise lacks the skillset to do so effectively. They couldn't do it if they wanted to, short of contracting it out.
- _ph_ 5y agoThats the point. Giving back money for the libraries used might not fix anything and can be difficult in many cases. But the most and important way of "giving back" would be testing and review of the libraries used. If especially the large companies using this library had used some of the dev hours for testing and review, the bug should have been found early on.
- staticassertion 5y agoCode auditing is extremely expensive. I recently did some napkin math and my estimate is that for our relatively small project (a company of ~10) it would cost between 2 and 12 million dollars to have our rust dependencies audited, with Rust making up ~60% of our codebase. And that's a point in time audit. To maintain that value we'd have to redo the audit periodically. It's just not gonna happen.
- draw_down 5y agoThis is getting pretty expensive too, though.
- layer8 5y agoDealing with the current vulnerabilities is very likely cheaper than auditing each and every dependency with the thoroughness needed to actually catch those vulnerabilities. Also, nobody within the by affected enterprises gets blamed for those external vulnerabilities, nor are the enterprises liable for preventing them, so there is little incentive to prevent them proactively.
- rukuu001 5y agoI did this years ago with an open-source and reasonably popular non-Apache library. The results were so horrifying my boss quickly concluded such audits were outside our responsibility and the time I spent on the audit was written off. It was especially difficult for us because we’d shipped so much code that used the library, and replacing the library was unthinkable.
- mastax 5y agoDon't ask a question if you won't like the answer.
- deleted 5y ago[deleted]
- skottk 5y agoI assume at this point that this library has been audited many, many times by skilled professionals, none of whom thought to abuse the template + JNDI + LDAP chain in this way. It's just not as simple as "security audit finds all the vulnerabilities, then you fix them." You invest X in the review, you get the results that X/(hourly rate) finds. This is a lot of software with a ton of configurability-- that's a lot of variations to review and test. Now that someone found the first lump of gold and gave it away, there are thousands of eyes searching for the next one. These recent findings are all abuses of this same chain of functionality, just along different sets of settings. In another month we might have half-a dozen more of varying severity and scope. That _still_ won't prove that the overall library is then safe, but we will probably have a a little more confidence in this particular bit of crazy template formatting flexibility. Maybe not as much as we had had three weeks ago, but more than we do now.
- efitz 5y agoOn behalf of all information security people everywhere, I want to thank Apache for all the wonderful Christmas presents this year. I hope you step on a Lego.
- alanfranz 5y agoThis attitude should stop. They're volunteers. It's open source. Users are required to use such piece of software at their own will and risk. Log4j didn't ever get a single penny from most (all?) of their users, and now they should take all the blame. Why? The disclosure process was terrible, they clearly had no time to perform a thorough validation of the hotfixes, and this is the result. Why didn't anybody else step up to help them? Did any of the large companies using log4j pour some thousand dollars into the Apache foundation to let a couple of security-oriented engineers take a complete review of the patches? But then, it's log4j developers and Apache that should be blamed. Bah. That's SO pretentious.
- dylan604 5y ago>But then, it's log4j developers and Apache that should be blamed. Bah. That's SO pretentious. Um, yeah. They wrote the idiotic code that allowed this to happen. Who should get the blame then, the users? Duh, no. Should the hackers taking advantage of the exploit? Maybe, some, but they wouldn't be able to do it if the code wasn't so badly wrritten. >Why didn't anybody else step up to help them? To me, this is the pretentious part. I didn't write the code, I don't use the code, so why in the world should I be expected to fix the code? Do you use the code? Why didn't YOU fix it?
- alanfranz 5y agoIf you don’t use the code, you’re not vulnerable > who should get the blame? The users? If you leverage a ton of open source deps, shit is going to happen. You should not blame anyone. But if you must, yes: blame the users that choose such piss-poor software.
- 5y ago
- alanfranz 5y agoThanks to all Log4j developers. As users of your free software since ~20 years, we're sure that, if this vuln disclosure had been better and there were no sign of widespread in-the-wild exploitation, you would have done a better job at patching it, and a single release would have been enough. We won't hold a grudge against you; open source means collaboration, and you don't blame hard-working people that give away their software for free for honest mistakes. Your software still did far more good than bad to the software world. Thanks!
- jacquesc 5y agoThanks to Log4J developers for turning me off to Java 20yrs ago due to their horrible API design and developer experience. Does not shock me that this security vulnerability happened, but it did shock me that so many people kept using this awful library. I thus enjoyed a development career (mostly) free from this kind of needless pain and suffering.
- dang 5y agoPlease don't cross into personal attack. You can make your substantive points without swipes, and that's the spirit we want here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- mml 5y agoThe options at the time were even worse.
- Hallucinaut 5y agolog4j2 has little to do with the log4j you claim turned you off 20 years ago and almost no one works directly to the logging library API rather than an slf4j facade.
- jacquesc 5y agoFair enough. But to me it was the smell of a toxic Java ecosystem, where people had to use crappy software even though they knew how bad it was. It took a simple problem and turned it into a clusterfuck of configuration and complexity.
- Kreotiko 5y agoIf information security people would spend the same amount of time they are spending complaining about this vulnerability trying to educate their organisations on the importance of supporting open source solutions they depend on we wouldn’t be in this situation. I am sick of reading of very senior people complaining about the impact this vulnerability has had on their week when their companies don’t even contribute a penny to open source projects.
- natded 5y ago> educate their organisations on the importance of supporting open source solutions Githubs of the world could just gate downloads, pull requests etc. behind a payment to see what is the real valuation of open source software; I imagine it'd mostly settle around $0 excluding couple of big projects.
- samhw 5y agoUp until the semicolon, this was actually a decent point. I can see a future for high-quality open-source software hosted on an 'app store' which requires a small payment for use - or for commercial use, perhaps.
- ahtihn 5y agoAnd how are you going to prevent someone from just hosting a mirror for free?
- samhw 5y agoThat's the question that such an effort would have to solve. I think you're assuming a model where software is directly used by an individual consumer, though, which is not always the case. For commercial applications where your software is integrated into the end product, for instance, companies would never risk stealing unlicensed code considering the risk. How one would address the question you posed is entirely dependent on the domain one's operating in.
- 5y ago
- MikusR 5y agoThey should open source it so the community can improve and fix bugs.
- dreyfan 5y agoI’m enjoying the Apache Software Exploit Advent Calendar
- ashtonkem 5y agoI am not. Although one of my direct's decisions to setup a parent pom to manage versions across all our apps is paying back dividends this week.
- xigency 5y agoMore evidence that user provided data shouldn’t be logged at all.
- staticassertion 5y agoThat sounds like it would make debugging very hard for 0 benefit to anyone not using log4j.
- jacquesm 5y agoLogging can easily be a legal requirement.
- pmarreck 5y agoI'm thinking anyone who has to comply with Sarbanes-Oxley, for starters, potentially
- AtNightWeCode 5y agoWelcome to GDPR and hello to trace log everything. :)
- jacquesm 5y agoThis has absolutely nothing to do with the GDPR. In fact, the GDPR and various data retention laws are at odds with each other which is why the GDPR has a very explicit exemption for this.
- AtNightWeCode 5y agoNot sure what you are answering. If you for instance expose an endpoint by accident and then can't show logs for the access to it, you are going to have a problem in one of those GDPR hearings. The irony of GDPR is that you may end up with more logging of user data, not less.
- jacquesm 5y ago
- AzzieElbab 5y agoOmicron variant?
- peterkelly 5y agoHere's what I don't get: What is so complicated about logging that you can't implement the necessary functionality in your own codebase, and instead have to adopt a third-party library? The latter option represents a liability, which in this case (as with others) has shown can be a tremendous risk. Is the time saving really worth it, at the cost of risking disasters like this? I get that the tradeoff it is worth it for complicated things (e.g. crypto libraries). But logging, really? Software development culture today is too quick to adopt a huge tree of dependencies of unknown quality, rather than thinking about how to minimize dependencies to only those truly necessary. The leftpad fiasco was but an extreme example of this, but I see it all the time, and it seems probable that there are hundreds (maybe even thousands) of similarly severe problems out there in widely used dependencies that we just don't know about yet.
- cnorthwood 5y agobecause Log4J is also used by libraries. Which means you can configure the log level and capture logs from libraries and dependencies you use in a global configuration.
- doikor 5y agoYou really shouldn't use log4j in libraries. Instead use slf4j in a library and log4j (or whatever implementation for the facade you prefer) in the application using the library.
- isbvhodnvemrwvn 5y agoTell that to thousands of existing libraries.
- johnisgood 5y agoWhenever I write C, the goal is to have no or very few dependencies. When I see projects written in C, one of the features is that it has no dependencies. This is a good thing. I do not know why we are steering away from this.
- gundmc 5y agoAt least this one is "only" denial of service and not another RCE?
- layer8 5y agoYes, and it’s only applicable in very specific and likely quite rare circumstances. If not for the initial RCE vulnerability, no one would blink an eye.
- aborsy 5y agoDoes anyone know about the quality of crypto implementations in Java Cryptographic Extension (JCE), the standard crypto library in Java? We use a product that uses JCE. The log4j vulnerabilities worry me about the security of software in Java ecosystem in general.
- staticassertion 5y agoI don't know anything about it but I will say that people tend to audit crypto libraries and tend not to audit logging libraries.
- layer8 5y agoThey are generally high quality and implemented by cryptographers. Parts of the implementations are certified by NIST. Log4j is not part of the JDK and is an open source project with only few regular contributors. There is really no reason to infer any correlation to other parts of the Java ecosystem.
- ncmncm 5y ago"Certified by NIST" absolves people of responsibility without actually indicating any property of the code certified.
- kafkaIncarnate 5y agoMight want to read this thread: https://issues.apache.org/jira/browse/LOG4J2-3230 https://issues.apache.org/jira/browse/LOG4J2-3230 It's pretty interesting technically, and it's not really affecting 2.16.0 much except in weird edge-cases.
- BrandoElFollito 5y agoI see plenty of comments about security teams that should be doing this or that. I do not know about your security teams, but my security teams are now sitting 9 days straight trying to stop that shitshow. With teams complaining that they have to patch instead of doing Great Things. After that these security teams will be back to invisible work and forgotten again. Until the next issue. If your company has a truly different approach to security, tell it here - you may get really talented people knocking in because they are fed up with the security theater at their current job.
- ncmncm 5y agoThe most reliable place to find new bugs and security holes is next to others you just found out about. Bugs come in bunches. If you have fixed just one or two, more lurk right there. And, anyplace else that coder worked. The more you have found, the more remain to be found. Look at other places that coder worked that week. Or year.
- post-it 5y agoYour implication that specific bad coders are responsible for bugs is dangerous. Anyone can write a bug, and thinking that you're too good to do it is cocky.
- ncmncm 5y agoEvery bug is coded by a specific coder. We know there are huge differences in productivity of different coders. We know they repeat mistakes. Thus, the best place to look for another bug is in other code the same one wrote. But looking in your own code is probably next best. Ask yourself: if there is a bug somewhere in my code, where would it be? You may be surprised at how immediately the answer comes to mind. Look there.
- kevingadd 5y agoYes, but when a coder makes a specific mistake, it's likely they made it elsewhere. Similarly, when their mistake made it past code review, it likely made it past review elsewhere. They're not the only person making that mistake, but their diffs are a great place to start looking. A big subset of mistakes people make when writing software are the result of people not having the same understanding of a concept, policy or practice.
- extheat 5y agoIt really depends on the subject area of the code in specific. “Mistake” is a very broad term, in most cases when it’s used it’s not the implication that the writer didn’t know what they were doing, rather they wrote erroneous code—which ultimately everyone does at some point. What it is however indicative of, is a lack of thorough testing and review that could have potentially caught the error. Obscure errors in places such as parsers, rendering logic, complex algorithms, memory management, etc. are particularly tough areas because building a good exhaustive testing workflow can be a challenge. Even a good writer will make mistakes, otherwise we wouldn’t need proofreaders.
- throwaway81523 5y agoIs this still about malicious payloads in serialized Java packets? I don't use Java so maybe I'm being unjust, but I'm smiling slightly because Python went through this 20 years ago with regard to the pickle protocol. It was originally intended to be ok for transporting hostile data, and it took a fair amount of persuasion and a few security incidents to turn the community's thinking around about that. ast.literal_eval was invented partly for this reason, but the generally preferred way to serialize now is usually json.
- layer8 5y ago> Is this still about malicious payloads in serialized Java packets? No, it’s not.
- raverbashing 5y agoSo, again, why is log4j "evaluating" stuff in log strings? This is the root cause that people should be addressing Why are people still using JDNI? It is frail enough to have logs depend on a dns lookup, I can't imagine depending on a LDAP lookup. This is not such a fundamental issue as the above but it is pretty dangerous. Oh yes and of course one of the worse and least pythonic package in the Python standard library was "inspired" by the log4j monstrosity
- wiether 5y agoBecause a few years back it was all the hype and the Java community doesn't like deprecating stuff.
- cesarb 5y ago> Why are people still using JDNI? Because "java:comp/env" is the way for a J2EE web application to get values or objects from the configuration outside its container. Yes, nobody actually uses the remote parts of JNDI anymore, but the local variant (within the same process) is still in use. And that's what led to this vulnerability: someone wanted to be able to get these local values within the logging configuration, which is a valid use case. Not realizing that this opened the door to remote values and objects.
- junon 5y agoI maintain `debug` for Node.js and the Log4J devs are living my worst nightmare when it comes to that library. It's used just about everywhere and any sort of zero-day would have far reaching implications. Hugs for all of you. This can't be fun.
- deleted 5y ago[deleted]
- alkonaut 5y agoThis isn’t a RCE right? Compared to the previous one I wouldn’t call a denial of service high severity at this point. It might have been high severity two weeks ago. But to be clear: nested/recursive template expansion and expansion of user provided strings were never by design, correct, and the removal shouldn’t just be by configuration or considered breaking - it should simply be corrected (just like the jndi should be removed and not even be optionally possible)?
- mongol 5y agoI have never understood why logging has needed such complex frameworks.
- zibzab 5y agoBecause, this is how we do things in Enterprise. Okay, more seriously... this is why I am currently staying away from Rust. Because sometimes I don't even know if the random number generation crate I imported for my banking app came from Rust team or some random dude in zanzibar. (Sorry, I know HN loves Rust, so do I. But I currently that the cargo/crate system is a bit too easy to use and misuse).
- zibzab 5y agoHopefully this puts an end to those annoying log4j-LOTR memes. (Unless some hobbits have 3 breakfasts?)
- jsmythe45 5y agoI was pretty horrified to learn that log4j makes network calls, was even surprised to hear it parses log strings. Fortunately our log4j was too old and JVM too young to be vulnerable to the first exploit, but it seemed best to rip out log4j and replace it with something simpler anyway. java.util.logging seemed the obvious choice, but the API is different, so would have been a lot of s/debug/fine and so on. In the end, we: - wrote a new class with the same 'api' as the part of log4j that we use - globally replaced 'import org.apache.log4j.Logger' with our new class - fixed any compile errors by adding new methods to our class - wrote a test to make sure it rolled correctly and could handle lots of threads etc. Here's the code if you want to do something similar (don't know how long it will be accessible from there): <https://ideone.com/XKg5M9 https://ideone.com/XKg5M9>