Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security Privacy

CISA Director: We'll Be Dealing With Log4j For a Long Time (cnet.com) 46

Security professionals will be dealing with the fallout from the Log4j bug for a long time to come, top officials for the Cybersecurity and Infrastructure Security Agency said Monday. CNET reports: If left unpatched or otherwise unfixed, the major security flaw discovered a month ago in the Java-logging library Apache Log4j poses risks for huge swaths of the internet. The vulnerability in the widely used software could be exploited by cyberattackers to take over computer servers, potentially putting everything from consumer electronics to government and corporate systems at risk of a cyberattack. No US federal agencies have been compromised as a result of the vulnerability, CISA Director Jen Easterly told reporters on a call Monday. In addition, no major cyberattacks involving the bug have been reported in the US, though many attacks go unreported, she said.

Easterly said the sheer scope of the vulnerability, which affects tens of millions of internet-connected devices, makes it the worst she has seen in her career. It's possible, she said, that attackers are biding their time, waiting for companies and others to lower their defenses before they attack. "We do expect Log4Shell to be used in intrusions well into the future," Easterly said, using the name for the bug in the Log4j software. She noted the Equifax data breach in 2017, which compromised the personal information of nearly 150 million Americans, stemmed from a vulnerability in open-source software. Most of the attempts to exploit the bug, so far, have been focused on low-level crypto mining or attempts to draw devices into botnets, she said.

This discussion has been archived. No new comments can be posted.

CISA Director: We'll Be Dealing With Log4j For a Long Time

Comments Filter:
  • She noted the Equifax data breach in 2017, which compromised the personal information of nearly 150 million Americans, stemmed from a vulnerability in open-source software.

    Yeah, I've worked with Equifax, and it's is plainly evident that the open source parts of their stack are the most secure parts.

    • by gweihir ( 88907 )

      Also, the problem at Equifax was abysmal incompetence demonstrated by not patching a known Apache vulnerability for a long time. Well, their CISO was a music major, I believe and that explains a lot. Not her fault really, but the one of those that hired her.

      • by jmccue ( 834797 )

        Well, their CISO was a music major

        Actually there is proven correlation between Music and Math, and many Music Majors tend to be good in IT.

        Now I am not saying the CISO did not make mistakes, but I tend to believe Equifax pushed back on any security maintenance because we all know CEO Bonus takes first priority.

      • by fedos ( 150319 )
        Her major doesn't matter. If you're hired as a CISO then based on experience not the specifics of your undergrad degree. So as long as she sufficient experience in IT/cybersecurity then that's what counts.
        • by gweihir ( 88907 )

          Her major matters very much. You cannot get good at IT security at this level without the right education first. The gap is just too large. You may be able to do it with an IT but not IT-security education after a decade or two, but without even the basics? No chance.

          But anyways, her performance clearly showed she cannot do it. Yes, I am a ware a CISO does not patch Apache servers. But it is a CISO's job to make sure they get patched in a timely matter. That did not happen and it is one of the glaringly obv

  • She noted the Equifax data breach in 2017, which compromised the personal information of nearly 150 million Americans, stemmed from a vulnerability in open-source software.

    From TFA

    Apache Log4j poses risks for huge swaths of the internet. The vulnerability in the widely used software could be exploited by cyberattackers to take over computer servers, potentially putting everything from consumer electronics to government and corporate systems at risk of a cyberattack.

    This kind of hyperbole isn't warranted or necessary. I seem to remember a much bigger issue with Solarwinds that is still being cleaned up [congress.gov] but the same hyperbole was used. Such statements only push companies to force developers into closed-source solutions that are no better.

    You can't have computer systems on the Internet with zero risk; there will always be some zero-day vulnerability that will get exposed, and then there'll be a mad rush for a fix and remediation.

    • by Jeremi ( 14640 )

      Such statements only push companies to force developers into closed-source solutions that are no better.

      Agreed that closed-source solutions are no better, but there might be a benefit in having different companies using different solutions. The problem with everybody in the world running the same logging package is the same problem with monocultures in farming -- when a vulnerability is found, it affects everyone at once and causes a major problem.

      Consider a hypothetical world where instead of everybody running log4j, there were two dozen different logging packages in use, all of roughly equal popularity. I

      • valid point but I think Log4J is a case of bloat, That's where you had slf4j come in because there were developers who were frankly tired of what Log4J was becoming. There are alternatives, java.util.logging, logback, et al. but Log4J still gets used. So, there are alternatives and I'm sure this hyperbole will do a lot to force a lot of organizations to look at Log4J usage overall despite it being a framework that does what it needs to, albeit with a lot of features you probably don't nor will you ever use

        • by narcc ( 412956 )

          albeit with a lot of features you probably don't nor will you ever use.

          If we had any sense, we'd start to question why we use gigantic do-everything libraries when our needs are generally a lot simpler.

          • If we had any sense, we'd start to question why we use gigantic do-everything libraries when our needs are generally a lot simpler.

            Time for a fork?

            • by narcc ( 412956 )

              For a lot of people, they'd probably be better off just writing something themselves. You'd be amazed at how often that saves time in both the near term and the long term.

              Sometimes, your need just really aren't that complex. I've seen people layer on a lot of complexity to ultimately get the equivalent of writing to stderr.

              Though, in this case, the standard library provides a perfectly suitable alternative. I have no idea why anyone would still be using log4j this late.

      • There are actually half a dozen logging packages for Java.

        And there is a logging API on top of all of them to unify them all.

        And to further stretch the situation, there are probably more than a dozen of log4j library versions: and only 2 are vulnerable.

        at the expense of developers having to learn to use multiple logging packages, of course.
        Not at all. After all all those libraries only have like 4 method calls:
        log
        debug
        inform
        message

        And: as mentioned above, there is a unifying API on top of al of them, since

      • There are indeed advantages to having competing solution, with roughly equal usage.

        Does proprietary software lead to that?
        I present Excel. And Active Directory. And Windows.

        On the other hand, I've been writing software for 25 years and never once used log4j in anything I ever wrote.

        Today I was working on some flight control firmware for quadcopters (aka "drones"). Firmware for flight controllers for people who build their own drone rather than buying from DJI or any of the other companies is a bit of niche

      • by Bert64 ( 520050 )

        Well that's already the case to some degree.
        Log4j is only usable for java developers, many systems are developed in other languages and thus aren't affected.
        Even for java developers, there are alternatives to log4j albeit less widely used ones.

        One issue however is a lack of modularity, or laziness in the part of developers not removing the functionality they don't use.
        You have a huge framework which provides tons of functionality catering to every possible use case. However each individual developer will li

      • Agreed that closed-source solutions are no better...

        Worse, with fewer eyes on the source.

    • by gweihir ( 88907 )

      Some idiots try to make them feel all fuzzy and warm by believing that COTS does not have the same (or worse) problem. In actual reality, FOSS does have a problem with maintenance and getting the maintainers financed, but the commercial problem is worse: Companies going out of business and suddenly nobody can maintain their software because there is no source code or copyright stands in the way.

      So in actual reality, FOSS is and remains superior. It is just not without its own problems.

    • > You can't have computer systems on the Internet with zero risk; there will always be some zero-day vulnerability that will get exposed, and then there'll be a mad rush for a fix and remediation.

      That's one reason Equifax got hacked - months after the issue was known and patches were available, Equifax hadn't patched. Try goping three months without patching your Windows servers that are exposed on the internet, or any other major proprietary software. Not patching, not installing updates, was the bigge

      • The sad thing is that Equifax saw no permanent loss as a result of their lax security. Their stock is higher than ever, people still use and trust them.

    • Comment removed based on user account deletion
  • ... heartbleed, solarwinds, etc etc.. She just have had a short career.
  • It's not a bug (Score:4, Informative)

    by jsonn ( 792303 ) on Monday January 10, 2022 @07:39PM (#62162533)
    Can we please stop calling it a bug? It's working exactly as designed. Sure, the design is broken and a security nightmare, but it doesn't change the fact that it is very intentional behavior.
  • There's an easy fix for this log4j issue, just remove Java from all the computers. Then you have nothing to worry about, including all the jdni exploits that haven't been published yet, but are being kept hidden for 90 days until some of them are fixed.
    • by kiviQr ( 3443687 )
      Right, then remove everything else, erase drive with DoD 5220.22-M, unplug computer, then burry it 20ft of cement in undisclosed location. Then you can consider it semi-secure.
      • erase drive with DoD 5220.22-M, unplug computer, then burry it 20ft of cement in undisclosed location

        You sound like one of clients who stated that if the work we do is stolen then it is worse than if we hadn't done the work at all. I was opting for a more subtle approach. Many of my clients have quite happily removed Java from all their systems and are reaping the benefits, particularly in the finance sector.

        • by kiviQr ( 3443687 )
          I am coming from the approach that every single line of code (no matter what language) is a liability. Extrapolate it to zero.
          • Yes I understood the gist of your previous answer, and it's a huge headache working in these environments where every new line of code is considered a liability. For some reason the old working code is fully trusted though not to crash the plane (it did), drill a hole through a patient with a laser (did this too), or launch a missile into... somewhere it shouldn't have. (errr)
        • That is a really stupid comment.

          Why would anyone remove something that is actually not there?

          Hm?

          To "remove Java" one has to install it first.

          And there is no computer in the world since 10 or 15 years where Java comes preinstalled.

          Stupid idiot

          Ah, and if one installs Java: he obviously is running Java programs. So deinstalling means: he can not run his Java programs anymore.

          Did I mention: Stupid idiot? I think I did.

          • by Bert64 ( 520050 )

            And there is no computer in the world since 10 or 15 years where Java comes preinstalled.

            Pretty sure Oracle are still selling servers with Java preinstalled.

            • Pretty sure Oracle are still selling servers with Java preinstalled.
              Oh, sure.

              And since when are we talking about servers when a stupid /. er says: "you only have to deinstall Java from YOUR computer"?

              Hint: even if you have a server in the basement, as long as you do not run a Java program, that uses the library in question AND is somehow accessible from the internet, THEN there is no damn reason to remove Java.

              On top of that: if you are running such a software, you obviously NEED Java, and hence can not rem

          • Ah yes name calling, the sign of a true Java developer. I left a response to what is obviously another Java developer here https://slashdot.org/comments.... [slashdot.org] . I picked their comment to respond to because they seemed to have a wider vocabulary that you.
            • I did not call you names.
              I called you stupid.

              And I made the relevant parts of my post bold for a reason.

              If you are too stupid to grasp that removing Java when you are actually not running any Java program: makes no sense. Then you are stupid.

              If you are too stupid to grasp, that you can not "remove Java" when you are dependent on running a certain Java program: you are beyond stupid.

              Your choice.

              Change "Java" with "Python" or "C++" or what ever - if you think Java developers are the only ones who grasp that r

    • a) no it is not
      b) you are an idiot
      c) having java on your computer does not make you open for an exploit: you actually have to run a java program - yeah, and that is why b) is true, how one can so stupid to think he is vulnerable to an "insert language exploit" when he is actually not running software in that language, is beyond me
      d) the vulnerability is not Java, but a very specific set of libraries. In this case: log4j.
      e) People running that software, simply can not "delete Java", because: oops! They are r

      • d) the vulnerability is not Java, but a very specific set of libraries. In this case: log4j.

        The vulnerability is related to jndi, which is a bit of a java thing you know. There will be more of these. Here's one to get you started. https://jfrog.com/blog/the-jnd... [jfrog.com]

        And yeah, people run programs that are dependent on Java. The solution that seems to have gone over your head is you replace them with functionally equivalent programs that aren't dependent on Java. Funny enough I'm doing semi automated conversio

        • by Nadir ( 805 )
          The vulnerability is related to log4j exposing access to JNDI. The JDK JNDI bug was fixed three years ago.
        • The vulnerability is related to jndi, which is a bit of a java thing you know.
          Yes and no.

          The vulenaribilty would not exist of not:
          a) the programmers of log4j had deliberately programmed the vulneranbility into log4j
          b) the programmers of log4j had not used jndi to load a class remotlely - deliberately

          The solution that seems to have gone over your head is you replace them with functionally equivalent programs that aren't dependent on Java.
          That is not a solution.

          If you are so stupid, I wonder how you can even

    • by swilver ( 617741 )

      What would you suggest to replace it with? A language designed by the company with the worst remote exploits in history?

      • What would you suggest to replace it with? A language designed by the company with the worst remote exploits in history?

        Ah yes, a poke at Microsoft, a deflection tactic I've seen from many Java programmers since this Log4j exploit showed its head. Yes Microsoft a company so homogenous, who's workers are all so in lockstep, that the coding style present in the operating system called Windows from the 1990s and early 2000s, is reflected in the Office products and developer tools in the year 2022. What an ama

  • You will, I wont. Used C++ against everyone's golden advice.

  • there are many people are looking for the myhr cvs [employeeloginportals.com] guide

Brain off-line, please wait.

Working...