11 ms·

Log4j 2.15.0 – Previously suggested mitigations may not be enough

271 points by News-Dog 5y ago

usrbinbash 5y ago
So code written in a language that encourages building a gazillion indirections instead of just doing things procedurally is hard to fix? I'm shocked ;-)
- _old_dude_ 5y ago
  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.
freeqaz 5y ago
Thread on this from yesterday: https://news.ycombinator.com/item?id=29561532 https://news.ycombinator.com/item?id=29561532
diegocg 5y ago
This is starting to remind me of the coronavirus
- bartread 5y ago
  If you mean it's turning into a grinding and repetitive groundhog day, I concur. We don't even use log4j and yet are fielding a steady stream of requests to reassure clients that we've mitigated against it, which hasn't been an issue because we don't use it (although we do use log4net with Stackify and it's certainly a possibility that may be compromised in future), and of course are having to audit all our own suppliers. I encourage companies to post information on their websites about this so we don't all have to keep emailing you (I'm trying to get some info up on ours detailing mitigations, for similar reasons; once it's there I can send some all company comms and hopefully never see another email in my inbox with "log4j" in the subject line). Of course, this whole issue is crucially important to deal with, but it's also frustrating because it's an entirely non-value-adding time-vampire.
- sschueller 5y ago
  https://twitter.com/rickhanlonii/status/1470074730279546895 https://twitter.com/rickhanlonii/status/1470074730279546895
stickfigure 5y ago
I must confess to feeling that the reach of this CVE is a bit oversold. Yes, it's a terrible RCE and a major catastrophe for anyone using log4j. But log4j hasn't been the popular choice for logging implementations in a long time. Libraries typically use facades like slf4j or commons-logging, so the risk of pulling in an active log4j implementation transitively is pretty small. Your application/appserver either logs with log4j or not, and your developers are probably aware of this when they configured logging. You shouldn't need to pour over code to figure it out. It would be far worse if this exploit existed in slf4j or commons-logging.
- oblio 5y ago
  He he, an optimist. log4j is in widespread use, directly or indirectly. Most people don't give a crap about the exact Java logging library, the only places that actually care are those that bike shed, since functionally Java logging stuff is generally quite robust and full featured. The worst part about my previous phrase is that the places that don't care about the Java logging library frequently don't do security audits, so prepare for a ton of exploits and data leaks in the following months and years.
- theevilsharpie 5y ago
  > You shouldn't need to pour over code to figure it out. It's not just your code that is vulnerable. Our in-house software doesn't use log4j, but a number of third-party components we use do and needed to be patched.
- smarx007 5y ago
  For the record, both SLF4J and commons-logging as logging frontends allow log4j to be used as a logging backend.
- alenmilk 5y ago
  I have ported a Spring Boot application from log4j to logback and it was pretty easy since we used slf4j. The code was the same, the only thing I had to do is to convert the logging configuration. The features mapped one to one and it to some fidgeting to make it work, but all in all it was pretty straight forward. Would recommend.
guidedlight 5y ago
This vulnerability will likely turn out to follow the trajectory of the Meltdown and Spectre vulnerabilities from...(checks google)... 2018. I speculate will be a cluster of newly discovered vulnerabilities that follow a similar pattern, possibility across a number of familiar Java libraries.
- chromanoid 5y ago
  Mmh, I don't think so. Beside logging most other libraries will already sanitize user input since it is a more commonly known attack vector for those kind of libraries. I would compare the vulnerability to https://github.com/frohoff/ysoserial https://github.com/frohoff/ysoserial.
- sumtechguy 5y ago
  What I have been pondering again in the past few days is dependency management. For many projects this is a open pom file pop in the new version, recompile, deploy and bobs your uncle you are good. But some projects are little more interesting in that they include libs like this, or include libs that include it. It is part of their foundation/framework. So you can still put in override and ignore what the lib wants. But now when it comes time to upgrade that top lib maybe there are 6 newer versions of the one problematic lib you were concerned about today, but now it is a year later and you forgot about it. What is the mental context to say 'oh yeah go back and check that'. You may have got used to ignoring the 'hey you are overriding that jar file'. Are you going to do that for all of the libs/jars this top level framework drags in? It is not just java that has this sort of issue. NPM (though you can float the versions at least), nuget, rust, C++ containers, etc. A lot of projects out there have taken on this maven central style building. Which is a huge productivity boon. But in many ways has not helped us with dependency hell, and in some cases has made it wildly worse. I see simple projects pulling in 150+ items in some cases. What is the mental context of actually managing that? And have real fun if your project depends on a 'dead' project where there are little to no updates. This one is at least high profile enough that many people are revisiting old build chains that have long ago been forgotten and updating them. That will kill out many other vulins that have been lurking. But many will just do that one jar set and call it a day. But you are probably right we are going to get see a few of these style of attacks.
charcircuit 5y ago
We already had a submission about this
archi42 5y ago
In other news: If I can intercept the log messages (unencrypted remote syslog, or log file public accessible, log messages also shown to the user) I can still just inject stuff like "${env:DATABASE_PASSWORD:-xxx}". Lots of people are only focusing on the aspect how this can be abused to inject arbitrary code, while it is actually a similar class like SQL injections: Blindly trusting user input instead of doing proper sanitization. (The whole discussion why a logging mechanism should support the whole JDNI stuff is still perfectly valid).
- Sebb767 5y ago
  This is somewhat intended, though. Also, for intercepting the logs you need _a lot_ more access than for an unauthenticated RCE and that database might not actually be accessible from the outside. It's not cool, but far less severe than the original issue.
  - archi42 5y ago
    Yes, absolutely. log4shell is a pwn fest that makes the recent Exchange debacle look rather innocent (and that was already quite bad). But I can envision scenarios like unencrypted rsyslog on a LAN being relevant during pentests, or misconfigured (read: attacker readable) log files.
- xorcist 5y ago
  People think they are safe because they don't allow for outgoing ldap, but combined with a way to do dns lookups, these kind of things can get really scary. The java ecosystem is full of these abstractions, that are not outright security problems in themselves, but give rise to complex interactions that makes it hard to judge what the implications are. This particular logging system has been used by millions of developers for the better part of a decade before any one single person realized the actual implications.
  - ethanbond 5y ago
    Just a minor clarification that’s worth being explicit about: It has been used by millions of developers for the better part of a decade before anyone disclosed the implications.
tinus_hn 5y ago
Why is there no environment variable to turn off parsing the messages completely?
- Macha 5y ago
  There was. It wasn't checked in all contexts. Hence the second CVE
archo5 5y ago
Why is nobody still concerned with the fact that log4j-core is nearly 50 KLOC big and massively overengineered? A bit much for a logging library, isn't it? How many users of this library even know 10% of what's going on in there? For a comparison, the entire original Doom was only 40 KLOC. https://www.reddit.com/r/Doom/comments/g7wbxr/number_of_lines_of_code_in_classic_doom/ https://www.reddit.com/r/Doom/comments/g7wbxr/number_of_line...
- broodbucket 5y ago
  You can apply the same logic to most of the stack of most of everything. Not to downplay the issue, but it's hardly an isolated case. Noone cares until they have to care, and by that point it's too late.
rq1 5y ago
Did someone think about tricking google bots into following URLs with the malicious bits? It can be "fun". :)
John23832 5y ago
This seems to be what we’ve always known: Interpreters with public input are just vulnerabilities waiting to happen.
krylon 5y ago
When I was shopping for groceries today, I saw something strange. The buses have displays to show what Line they are, today all of the buses I saw had blank displays. On my way home, I could see the display on the bus driver's seat, which only displayed an otherwise blank Windows Embedded CE 6.0 start screen. Oh, and the thingy you put your ticket in get the stamp was out of order on all the buses. Made me wonder if that was due to some component involved was using log4j? I don't think it's very likely - why would the bus display or the ticket stamping machine be affected in a way that requires turning them off? But who knows, maybe somebody overreacted, or maybe these depend on some backoffice infrastructure that is temporarily offline due to log4j. It was weird, though. This is the first time I remember a security vulnerability made the national news (in Germany, if it matters). I don't think even Heartbleed got that much attention outside IT news outlets.
jet390 5y ago
The recent log4j vulnerability really piqued my interest, and I've spent the last few evenings working on a proof of concept Java agent that could mitigate similar vulnerabilities in the future, for applications that are able to completely forego platform features like JNDI, serialization or native process execution. Link to the project: https://github.com/gredler/aegis4j https://github.com/gredler/aegis4j It's not a lot of code, but it uses parts of the platform that I think are a bit unusual for most devs, so it was quite interesting to implement. Happy to discuss details, ideas, and concerns. One idea for a possible improvement is to make the feature block list adaptive, i.e. watch what the application uses in the first few minutes of execution, and then shut down all unused "dangerous" features for the remaining lifetime of the VM. Not sure how reliable this would be though, especially for services which have background jobs that might only run once a day.
keule 5y ago
Really glad I took the extra time to switch to logback
altspace 5y ago
Does anybody use the Jndi lookup feature at the root of this vulnerability? I wonder if it was a feature bloat

271 points by News-Dog 5y ago

So code written in a language that encourages building a gazillion indirections instead of just doing things procedurally is hard to fix? I'm shocked ;-)

_old_dude_ 5y ago
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.

freeqaz 5y ago

Thread on this from yesterday: https://news.ycombinator.com/item?id=29561532 https://news.ycombinator.com/item?id=29561532

diegocg 5y ago

This is starting to remind me of the coronavirus

bartread 5y ago
If you mean it's turning into a grinding and repetitive groundhog day, I concur. We don't even use log4j and yet are fielding a steady stream of requests to reassure clients that we've mitigated against it, which hasn't been an issue because we don't use it (although we do use log4net with Stackify and it's certainly a possibility that may be compromised in future), and of course are having to audit all our own suppliers. I encourage companies to post information on their websites about this so we don't all have to keep emailing you (I'm trying to get some info up on ours detailing mitigations, for similar reasons; once it's there I can send some all company comms and hopefully never see another email in my inbox with "log4j" in the subject line). Of course, this whole issue is crucially important to deal with, but it's also frustrating because it's an entirely non-value-adding time-vampire.
sschueller 5y ago
https://twitter.com/rickhanlonii/status/1470074730279546895 https://twitter.com/rickhanlonii/status/1470074730279546895

stickfigure 5y ago

I must confess to feeling that the reach of this CVE is a bit oversold. Yes, it's a terrible RCE and a major catastrophe for anyone using log4j. But log4j hasn't been the popular choice for logging implementations in a long time. Libraries typically use facades like slf4j or commons-logging, so the risk of pulling in an active log4j implementation transitively is pretty small. Your application/appserver either logs with log4j or not, and your developers are probably aware of this when they configured logging. You shouldn't need to pour over code to figure it out. It would be far worse if this exploit existed in slf4j or commons-logging.

oblio 5y ago
He he, an optimist. log4j is in widespread use, directly or indirectly. Most people don't give a crap about the exact Java logging library, the only places that actually care are those that bike shed, since functionally Java logging stuff is generally quite robust and full featured. The worst part about my previous phrase is that the places that don't care about the Java logging library frequently don't do security audits, so prepare for a ton of exploits and data leaks in the following months and years.
theevilsharpie 5y ago
> You shouldn't need to pour over code to figure it out. It's not just your code that is vulnerable. Our in-house software doesn't use log4j, but a number of third-party components we use do and needed to be patched.
smarx007 5y ago
For the record, both SLF4J and commons-logging as logging frontends allow log4j to be used as a logging backend.
alenmilk 5y ago
I have ported a Spring Boot application from log4j to logback and it was pretty easy since we used slf4j. The code was the same, the only thing I had to do is to convert the logging configuration. The features mapped one to one and it to some fidgeting to make it work, but all in all it was pretty straight forward. Would recommend.

guidedlight 5y ago

This vulnerability will likely turn out to follow the trajectory of the Meltdown and Spectre vulnerabilities from...(checks google)... 2018. I speculate will be a cluster of newly discovered vulnerabilities that follow a similar pattern, possibility across a number of familiar Java libraries.

chromanoid 5y ago
Mmh, I don't think so. Beside logging most other libraries will already sanitize user input since it is a more commonly known attack vector for those kind of libraries. I would compare the vulnerability to https://github.com/frohoff/ysoserial https://github.com/frohoff/ysoserial.
sumtechguy 5y ago
What I have been pondering again in the past few days is dependency management. For many projects this is a open pom file pop in the new version, recompile, deploy and bobs your uncle you are good. But some projects are little more interesting in that they include libs like this, or include libs that include it. It is part of their foundation/framework. So you can still put in override and ignore what the lib wants. But now when it comes time to upgrade that top lib maybe there are 6 newer versions of the one problematic lib you were concerned about today, but now it is a year later and you forgot about it. What is the mental context to say 'oh yeah go back and check that'. You may have got used to ignoring the 'hey you are overriding that jar file'. Are you going to do that for all of the libs/jars this top level framework drags in? It is not just java that has this sort of issue. NPM (though you can float the versions at least), nuget, rust, C++ containers, etc. A lot of projects out there have taken on this maven central style building. Which is a huge productivity boon. But in many ways has not helped us with dependency hell, and in some cases has made it wildly worse. I see simple projects pulling in 150+ items in some cases. What is the mental context of actually managing that? And have real fun if your project depends on a 'dead' project where there are little to no updates. This one is at least high profile enough that many people are revisiting old build chains that have long ago been forgotten and updating them. That will kill out many other vulins that have been lurking. But many will just do that one jar set and call it a day. But you are probably right we are going to get see a few of these style of attacks.

charcircuit 5y ago

We already had a submission about this

archi42 5y ago

In other news: If I can intercept the log messages (unencrypted remote syslog, or log file public accessible, log messages also shown to the user) I can still just inject stuff like "${env:DATABASE_PASSWORD:-xxx}". Lots of people are only focusing on the aspect how this can be abused to inject arbitrary code, while it is actually a similar class like SQL injections: Blindly trusting user input instead of doing proper sanitization. (The whole discussion why a logging mechanism should support the whole JDNI stuff is still perfectly valid).

Sebb767 5y ago
This is somewhat intended, though. Also, for intercepting the logs you need _a lot_ more access than for an unauthenticated RCE and that database might not actually be accessible from the outside. It's not cool, but far less severe than the original issue.
- archi42 5y ago
  Yes, absolutely. log4shell is a pwn fest that makes the recent Exchange debacle look rather innocent (and that was already quite bad). But I can envision scenarios like unencrypted rsyslog on a LAN being relevant during pentests, or misconfigured (read: attacker readable) log files.
xorcist 5y ago
People think they are safe because they don't allow for outgoing ldap, but combined with a way to do dns lookups, these kind of things can get really scary. The java ecosystem is full of these abstractions, that are not outright security problems in themselves, but give rise to complex interactions that makes it hard to judge what the implications are. This particular logging system has been used by millions of developers for the better part of a decade before any one single person realized the actual implications.
- ethanbond 5y ago
  Just a minor clarification that’s worth being explicit about: It has been used by millions of developers for the better part of a decade before anyone disclosed the implications.

tinus_hn 5y ago

Why is there no environment variable to turn off parsing the messages completely?

Macha 5y ago
There was. It wasn't checked in all contexts. Hence the second CVE

archo5 5y ago

Why is nobody still concerned with the fact that log4j-core is nearly 50 KLOC big and massively overengineered? A bit much for a logging library, isn't it? How many users of this library even know 10% of what's going on in there? For a comparison, the entire original Doom was only 40 KLOC. https://www.reddit.com/r/Doom/comments/g7wbxr/number_of_lines_of_code_in_classic_doom/ https://www.reddit.com/r/Doom/comments/g7wbxr/number_of_line...

broodbucket 5y ago
You can apply the same logic to most of the stack of most of everything. Not to downplay the issue, but it's hardly an isolated case. Noone cares until they have to care, and by that point it's too late.

rq1 5y ago

Did someone think about tricking google bots into following URLs with the malicious bits? It can be "fun". :)

John23832 5y ago

This seems to be what we’ve always known: Interpreters with public input are just vulnerabilities waiting to happen.

krylon 5y ago

When I was shopping for groceries today, I saw something strange. The buses have displays to show what Line they are, today all of the buses I saw had blank displays. On my way home, I could see the display on the bus driver's seat, which only displayed an otherwise blank Windows Embedded CE 6.0 start screen. Oh, and the thingy you put your ticket in get the stamp was out of order on all the buses. Made me wonder if that was due to some component involved was using log4j? I don't think it's very likely - why would the bus display or the ticket stamping machine be affected in a way that requires turning them off? But who knows, maybe somebody overreacted, or maybe these depend on some backoffice infrastructure that is temporarily offline due to log4j. It was weird, though. This is the first time I remember a security vulnerability made the national news (in Germany, if it matters). I don't think even Heartbleed got that much attention outside IT news outlets.

jet390 5y ago

The recent log4j vulnerability really piqued my interest, and I've spent the last few evenings working on a proof of concept Java agent that could mitigate similar vulnerabilities in the future, for applications that are able to completely forego platform features like JNDI, serialization or native process execution. Link to the project: https://github.com/gredler/aegis4j https://github.com/gredler/aegis4j It's not a lot of code, but it uses parts of the platform that I think are a bit unusual for most devs, so it was quite interesting to implement. Happy to discuss details, ideas, and concerns. One idea for a possible improvement is to make the feature block list adaptive, i.e. watch what the application uses in the first few minutes of execution, and then shut down all unused "dangerous" features for the remaining lifetime of the VM. Not sure how reliable this would be though, especially for services which have background jobs that might only run once a day.

keule 5y ago

Really glad I took the extra time to switch to logback

altspace 5y ago

Does anybody use the Jndi lookup feature at the root of this vulnerability? I wonder if it was a feature bloat