6 ms·

> When it was first revealed in early December 2021, the Log4Shell bug was described as one of the most severe security vulnerabilities ever. > The Apache Soft

> When it was first revealed in early December 2021, the Log4Shell bug was described as one of the most severe security vulnerabilities ever. > The Apache Software Foundation, which maintains the open-source tool, quickly released a patch... Apache horribly mismanaged this and did not release a patch until it was already widely known and being exploited in the wild. They also messed up and had to release several subsequent patches to actually fix the vulnerability. This greatly contributed to "[the] mad scramble to plug the gaps". You can watch the chaos unfold by reading through the GitHub PR. Remember, this was disclosed to Apache in November. https://github.com/apache/logging-log4j2/pull/608#issuecomment-990094911 https://github.com/apache/logging-log4j2/pull/608#issuecomme...

sdf4j 4y ago
Saying that "Apache mismanaged" it when talking about addressing a vuln is quite awkward. Probably fueled by lack of understanding of what the foundation does. The fact that every project have to have apache stamped in their name doesn't help either.
- richbell 4y ago
  So is saying "The Apache Software Foundation... quickly released a patch", but the average person doesn't care about the inner workings of the foundation because, as you mentioned, everything is stamped with "Apache". It may be technically incorrect, but most people wouldn't understand if you got into the minutiae.
  - wongarsu 4y ago
    They might be able to understand, but they wouldn't care. If there's a bug in Microsoft Office there's no discussion which engineer was responsible. Microsoft put their name on it and are thus first recipient of praise and blame alike. Apache Log4J2 is no different.
  - layer8 4y ago
    Apache provides infrastructure and some general organizational rules for projects, but the people who actually maintain any given Apache project are largly independent and autonomous, they are not "Apache".
    - richbell 4y ago
      You're right, but this misses the point of my comment. It's a distinction without a difference for most people, and trying to clarify the structure of the foundation to executives and senior leaders (technical and non-technical) only makes their perception of any Apache-branded or open source projects worse.
      - layer8 4y ago
        My point is one shouldn't bring up Apache in the first place when talking about a project like Log4j. It's similarly irrelevant as "hosted on GitHub".
        richbell 4y ago
        > My point is one shouldn't bring up Apache in the first place when talking about a project like Log4j. It's similarly irrelevant as "hosted on GitHub". That isn't comparable. - the name of the project is "Apache Log4J" - the tag-line is "*Apache Log4j* 2 is an upgrade to Log4j that provides significant improvements over its predecessor..." - it's hosted under the Apache organization - the documentation, release notes, and bug tracker is under the apache.org domain. - the artifacts are published under the org.apache namespace - etc. No competent person in the industry is going to think that GitHub is associated with the projects it hosts. There are also hundreds of projects stewarded by Eclipse, Red Hat, and other similar organizations that avoid this confusion by using sensible branding. What you're saying is more equivalent to "no reasonable person would think that Vitamin Water contains vitamins and is healthy". https://www.businessinsider.com/coca-cola-glacau-vitaminwater-misleading-advertising-lawsuit-2014-10 https://www.businessinsider.com/coca-cola-glacau-vitaminwate...
        4y ago
cogman10 4y ago
It was a complete misfeature from start to finish. They put in an "attempt to evaluate strings" feature. Literally as bad as someone doing a `console.log(eval(input))`. Not only is it that bad, but also it's something with just a tiny bit of inconvenience you can get with either String.format or the likes of slf4j's formatting ( `logger.info("{} value", foo.get());` ) They took the worst case for an injection attack and applied it everywhere.
- richbell 4y ago
  Not to mention that `log.info(eval(input))` made it effectively impossible to determine if you were compromised. If you weren't vulnerable you'd see "eval(input)" in your log, however, if you were vulnerable you wouldn't see anything.
- sys42590 4y ago
  In such cases I'd normally apply Hanlon's razor ( https://en.wikipedia.org/wiki/Hanlon%27s_razor https://en.wikipedia.org/wiki/Hanlon%27s_razor ) but this security gap is really huge and rather obvious if you have an informed look at the code. So this is one of the cases where I'd personally would not be surprised if in the far future someone admits on their death bed that malice was involved.
  - jerf 4y ago
    This particular bug has manifested in many places now, and in all those cases I find it plausible that it was a confluence of several independent teams (as in, not even working on the same code) adding features until, whoops, it turns out the combination is catastrophic. You find it obvious after the fact, but I don't think it is always obvious at the time. It's really easy for someone to see a feature like "interpolate strings better than ever" in their string library, and say to themselves, "Hey, that sounds good, let's turn it on!" without realizing that "better than ever" means "with arbitrary lookup from a string into a class of some sort", and then chain a few things together and hey presto you've got an arbitrary code execution vulnerability. I personally think allowing arbitrary string -> class lookup for all classes in the runtime is automatically a security code smell at best if not outright antipattern, but I don't think this is at all well understood yet. (While the general pattern is hard to avoid, you should have to register all classes/structs/values/whatever you want to automatically load from somehow. This prevents things like "I can use the OS object to execute arbitrary shell code" from automatically and unexpectedly creeping in.) Dynamic languages are all but based on such a capability, with their "eval" support. It's probably still going to be decades before this is generally understood "programmer wisdom", partially because the particular confluence of features that enables this bug is not common. It's just that when it does happen, it's catastrophic. But it's not actually that common.
deleted 4y ago
[deleted]

sdf4j 4y ago

Saying that "Apache mismanaged" it when talking about addressing a vuln is quite awkward. Probably fueled by lack of understanding of what the foundation does. The fact that every project have to have apache stamped in their name doesn't help either.

richbell 4y ago
So is saying "The Apache Software Foundation... quickly released a patch", but the average person doesn't care about the inner workings of the foundation because, as you mentioned, everything is stamped with "Apache". It may be technically incorrect, but most people wouldn't understand if you got into the minutiae.
- wongarsu 4y ago
  They might be able to understand, but they wouldn't care. If there's a bug in Microsoft Office there's no discussion which engineer was responsible. Microsoft put their name on it and are thus first recipient of praise and blame alike. Apache Log4J2 is no different.
- layer8 4y ago
  Apache provides infrastructure and some general organizational rules for projects, but the people who actually maintain any given Apache project are largly independent and autonomous, they are not "Apache".
  - richbell 4y ago
    You're right, but this misses the point of my comment. It's a distinction without a difference for most people, and trying to clarify the structure of the foundation to executives and senior leaders (technical and non-technical) only makes their perception of any Apache-branded or open source projects worse.
    - layer8 4y ago
      My point is one shouldn't bring up Apache in the first place when talking about a project like Log4j. It's similarly irrelevant as "hosted on GitHub".
      - richbell 4y ago
        > My point is one shouldn't bring up Apache in the first place when talking about a project like Log4j. It's similarly irrelevant as "hosted on GitHub". That isn't comparable. - the name of the project is "Apache Log4J" - the tag-line is "*Apache Log4j* 2 is an upgrade to Log4j that provides significant improvements over its predecessor..." - it's hosted under the Apache organization - the documentation, release notes, and bug tracker is under the apache.org domain. - the artifacts are published under the org.apache namespace - etc. No competent person in the industry is going to think that GitHub is associated with the projects it hosts. There are also hundreds of projects stewarded by Eclipse, Red Hat, and other similar organizations that avoid this confusion by using sensible branding. What you're saying is more equivalent to "no reasonable person would think that Vitamin Water contains vitamins and is healthy". https://www.businessinsider.com/coca-cola-glacau-vitaminwater-misleading-advertising-lawsuit-2014-10 https://www.businessinsider.com/coca-cola-glacau-vitaminwate...
        4y ago

cogman10 4y ago

It was a complete misfeature from start to finish. They put in an "attempt to evaluate strings" feature. Literally as bad as someone doing a `console.log(eval(input))`. Not only is it that bad, but also it's something with just a tiny bit of inconvenience you can get with either String.format or the likes of slf4j's formatting ( `logger.info("{} value", foo.get());` ) They took the worst case for an injection attack and applied it everywhere.

richbell 4y ago
Not to mention that `log.info(eval(input))` made it effectively impossible to determine if you were compromised. If you weren't vulnerable you'd see "eval(input)" in your log, however, if you were vulnerable you wouldn't see anything.
sys42590 4y ago
In such cases I'd normally apply Hanlon's razor ( https://en.wikipedia.org/wiki/Hanlon%27s_razor https://en.wikipedia.org/wiki/Hanlon%27s_razor ) but this security gap is really huge and rather obvious if you have an informed look at the code. So this is one of the cases where I'd personally would not be surprised if in the far future someone admits on their death bed that malice was involved.
- jerf 4y ago
  This particular bug has manifested in many places now, and in all those cases I find it plausible that it was a confluence of several independent teams (as in, not even working on the same code) adding features until, whoops, it turns out the combination is catastrophic. You find it obvious after the fact, but I don't think it is always obvious at the time. It's really easy for someone to see a feature like "interpolate strings better than ever" in their string library, and say to themselves, "Hey, that sounds good, let's turn it on!" without realizing that "better than ever" means "with arbitrary lookup from a string into a class of some sort", and then chain a few things together and hey presto you've got an arbitrary code execution vulnerability. I personally think allowing arbitrary string -> class lookup for all classes in the runtime is automatically a security code smell at best if not outright antipattern, but I don't think this is at all well understood yet. (While the general pattern is hard to avoid, you should have to register all classes/structs/values/whatever you want to automatically load from somehow. This prevents things like "I can use the OS object to execute arbitrary shell code" from automatically and unexpectedly creeping in.) Dynamic languages are all but based on such a capability, with their "eval" support. It's probably still going to be decades before this is generally understood "programmer wisdom", partially because the particular confluence of features that enables this bug is not common. It's just that when it does happen, it's catastrophic. But it's not actually that common.

deleted 4y ago

[deleted]