4 ms·

Between this and Log4j, I'm just glad it's Friday.

• eigen-vector 5y ago
  Unfortunately, patching vulns can't be put off for Monday.
  • deleted 5y ago
    [deleted]
• _jal 5y ago
  You are clearly not involved in patching.
  • Fordec 5y ago
    Simply already patched. Company sizes and number of attack surfaces vary. 22 hours is plenty of time for an input string filter on a centrally controlled endpoint and a dependency increment with the right CI pipeline.
    • zeko1195 5y ago
      lol no
      • deleted 5y ago
        [deleted]
    • shagie 5y ago
      Consider the possible ways for a string to be injected into any of the following: Apache Solr Apache Druid Apache Flink ElasticSearch Flume Apache Dubbo Logstash Kafka If you've got any of them, they're likely exploitable too. That list comes from: https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/ https://unit42.paloaltonetworks.com/apache-log4j-vulnerabili... The attack surface is quite a bit larger than many realize. I recently had a conversation with a person who wasn't at a Java shop so wasn't worried... until he said "oh, wait, ElasticSearch is vulnerable too?" You'll even see it in things like the connector between CouchBase and ElasticSearch ( https://forums.couchbase.com/t/ann-elasticsearch-connector-4-3-3-4-2-13-fixes-log4j-vulnerability/32402 https://forums.couchbase.com/t/ann-elasticsearch-connector-4... ).
      • EdwardDiego 5y ago
        Kafka is still on log4j1. It's only vulnerable if you're using a JMSAppender.
        • log4shell 5y ago
          Kafka is not vulnerable for this particular exploit but hdfs kafka connect plugin is.
      • Fordec 5y ago
        Lets see... Nope. Nope. Nope. Nope. Nope. Nope. Nope. aaaand... Nope. Plans for it, but not yet in production. Oh and before anyone starts, not in transitive dependencies either. Just good old bare metal EC2 instances without vendor lock in.