5 ms·

More realistically, this code is 20 years old, several generations of maintainers worked on it, accumulating patches over patches over patches and nobody wanted

More realistically, this code is 20 years old, several generations of maintainers worked on it, accumulating patches over patches over patches and nobody wanted to be the guy that say No / we should remove that feature. You can see the discussions on HN about Gnome removing features as a good example about how hard it is.

unbanned 5y ago
No it isn't 20yo. This feature is about 5
- wiseowise 5y ago
  They didn't say anything about the feature?
- mol4711 5y ago
  This JNDI "feature" is 8 years old. It was merged in 2013 from what I have seen, and has been defended by some as an "useful" feature. It has been known since at least BlackHat 2016 presentation that this is an incredibly dangerous and stupid thing to keep. cricket noises nobody reacted until now when minecraft servers got hacked.
  - js8 5y ago
    > nobody reacted until now when minecraft servers got hacked That shows which part of the IT industry is really needed.. :-)
    - bopbeepboop 5y ago
      On average, humans spend five days of their life watching Minecraft related content. Google recently had a banner announcing a trillion hours of Minecraft content watched; there are roughly 8 billion humans. So on average, a human has watched ~125 hours of Minecraft content. I think it’s just InfoSec has been too busy playing secret squirrel to secure our infrastructure: - SolarWinds - MS Exchange - log4j - Minecraft
    - bombcar 5y ago
      More importantly Minecraft servers are a target of convenience that both could and would be attacked by script kiddies. The open question is did anyone exploit this quietly and targeted before?
      - jethro_tell 5y ago
        Of coarse. Especially if it was known since black hat 2016.
  - josefx 5y ago
    > and has been defended by some as an "useful" feature. I would say the feature is useful but the implementation is insane. I would expect a SQL prepared statement approach, only contents of the statement / format string are resolved. Interpreting variables in user provided input just asks for SQL injection attacks and needs to be either prohibited or extremely restricted.
  - abhishekjha 5y ago
    I guess you are referring to this[0]. I am surprised if it was known that early then why did it take so long to find the issue? Or were exploits already run earlier and nobody reported? [0]https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-...
    - joe_guy 5y ago
      I only skimmed it but couldn't find any references to log4j.
  - avidphantasm 5y ago
    This whole fiasco is an argument to keep things simpler whenever possible.
simion314 5y ago
>You can see the discussions on HN about Gnome removing features as a good example about how hard it is. The issue with GNOME is the insincerity of feature removal, things like "nobody uses that", "nobody needs that", "you are doing it wrong" instead of just be sincere , "file picker is a usefull feature but we can't or don't care to implement it" , "optional server side decoration is a good feature but our devs want to work on cool shit not backwards compatibility" ... if you are an open source dev, be sincere and people will not be disgusted by your community and you don't get the go to example for bad developers/community.
- wcoenen 5y ago
  I'm not familiar with the GNOME story, but removing features takes courage and is actually a form of sincerity. A developer team can be insincere and avoid outrage by just leaving half-broken features in the software, stop testing them, and ignore all complaints about it. Low quality and inactivity doesn't make for as good a story on social media.
  - BrazzVuvuzela 5y ago
    > I'm not familiar with the GNOME story, but removing features takes courage Courage is not intrinsically admirable. Whether it's admirable or abhorrent depends on the context of what you're doing. Ditto for sincerity.
  - simion314 5y ago
    >but removing features takes courage and is actually a form of sincerity That is false, say I remove the feature X because reason A but I tell everyone that is for reason B. So I had the courage to remove X but I did not the courage to be sincere, maybe I am not sincere with myself and the real reason A is that the code was written by somebody else in the past and I want to implement new cool shit and not read somebody else code, but I can't admit that I don't care about feedback because I might be replaced as a project leader so I invent bullshit excuses like blame the previous developers that wrote bad code, blame the user that are using it wrong or invent some bullshit UX story with no real user tests to push my egotistic vision on everyone else because I am really an Apple fan but I could only get a job to work for RedHat
jsjohnst 5y ago
> More realistically, this code is 20 years old Actually, it’s not. Log4j 2 is a ground up rewrite of Log4j and is less than 9 years old from when the rewrite started, 7 years for the GA release. Log4j 1.x isn’t vulnerable as it doesn’t have this “feature”. Imho, this isn’t a “patches over patches” situation, it’s a very poorly thought out “feature” that almost nobody needed and shouldn’t have been added in the rewrite. The concept of “separation of concerns” exists for a reason. Your logging library should _just_ be concerned with logging.

unbanned 5y ago

No it isn't 20yo. This feature is about 5

wiseowise 5y ago
They didn't say anything about the feature?
mol4711 5y ago
This JNDI "feature" is 8 years old. It was merged in 2013 from what I have seen, and has been defended by some as an "useful" feature. It has been known since at least BlackHat 2016 presentation that this is an incredibly dangerous and stupid thing to keep. cricket noises nobody reacted until now when minecraft servers got hacked.
- js8 5y ago
  > nobody reacted until now when minecraft servers got hacked That shows which part of the IT industry is really needed.. :-)
  - bopbeepboop 5y ago
    On average, humans spend five days of their life watching Minecraft related content. Google recently had a banner announcing a trillion hours of Minecraft content watched; there are roughly 8 billion humans. So on average, a human has watched ~125 hours of Minecraft content. I think it’s just InfoSec has been too busy playing secret squirrel to secure our infrastructure: - SolarWinds - MS Exchange - log4j - Minecraft
  - bombcar 5y ago
    More importantly Minecraft servers are a target of convenience that both could and would be attacked by script kiddies. The open question is did anyone exploit this quietly and targeted before?
    - jethro_tell 5y ago
      Of coarse. Especially if it was known since black hat 2016.
- josefx 5y ago
  > and has been defended by some as an "useful" feature. I would say the feature is useful but the implementation is insane. I would expect a SQL prepared statement approach, only contents of the statement / format string are resolved. Interpreting variables in user provided input just asks for SQL injection attacks and needs to be either prohibited or extremely restricted.
- abhishekjha 5y ago
  I guess you are referring to this[0]. I am surprised if it was known that early then why did it take so long to find the issue? Or were exploits already run earlier and nobody reported? [0]https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-...
  - joe_guy 5y ago
    I only skimmed it but couldn't find any references to log4j.
- avidphantasm 5y ago
  This whole fiasco is an argument to keep things simpler whenever possible.

simion314 5y ago

>You can see the discussions on HN about Gnome removing features as a good example about how hard it is. The issue with GNOME is the insincerity of feature removal, things like "nobody uses that", "nobody needs that", "you are doing it wrong" instead of just be sincere , "file picker is a usefull feature but we can't or don't care to implement it" , "optional server side decoration is a good feature but our devs want to work on cool shit not backwards compatibility" ... if you are an open source dev, be sincere and people will not be disgusted by your community and you don't get the go to example for bad developers/community.

wcoenen 5y ago
I'm not familiar with the GNOME story, but removing features takes courage and is actually a form of sincerity. A developer team can be insincere and avoid outrage by just leaving half-broken features in the software, stop testing them, and ignore all complaints about it. Low quality and inactivity doesn't make for as good a story on social media.
- BrazzVuvuzela 5y ago
  > I'm not familiar with the GNOME story, but removing features takes courage Courage is not intrinsically admirable. Whether it's admirable or abhorrent depends on the context of what you're doing. Ditto for sincerity.
- simion314 5y ago
  >but removing features takes courage and is actually a form of sincerity That is false, say I remove the feature X because reason A but I tell everyone that is for reason B. So I had the courage to remove X but I did not the courage to be sincere, maybe I am not sincere with myself and the real reason A is that the code was written by somebody else in the past and I want to implement new cool shit and not read somebody else code, but I can't admit that I don't care about feedback because I might be replaced as a project leader so I invent bullshit excuses like blame the previous developers that wrote bad code, blame the user that are using it wrong or invent some bullshit UX story with no real user tests to push my egotistic vision on everyone else because I am really an Apple fan but I could only get a job to work for RedHat

jsjohnst 5y ago

> More realistically, this code is 20 years old Actually, it’s not. Log4j 2 is a ground up rewrite of Log4j and is less than 9 years old from when the rewrite started, 7 years for the GA release. Log4j 1.x isn’t vulnerable as it doesn’t have this “feature”. Imho, this isn’t a “patches over patches” situation, it’s a very poorly thought out “feature” that almost nobody needed and shouldn’t have been added in the rewrite. The concept of “separation of concerns” exists for a reason. Your logging library should _just_ be concerned with logging.