Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security United States

FTC Warns of Legal Action Against Organizations That Fail To Patch Log4j Flaw (techcrunch.com) 60

U.S. organizations that fail to secure customer data against Log4Shell, a zero-day vulnerability in the widely-used Log4j Java logging library, could face legal repercussions, the Federal Trade Commission (FTC) has warned. From a report: In an alert this week, the consumer protection agency warned that the "serious" flaw, first discovered in December, is being exploited by a growing number of attackers and poses a "severe risk" to millions of consumer products. The public letter urges organizations to mitigate the vulnerability in order to reduce the likelihood of harm to consumers and to avoid potential legal action.

"When vulnerabilities are discovered and exploited, it risks a loss or breach of personal information, financial loss and other irreversible harms," the agency said. "The duty to take reasonable steps to mitigate known software vulnerabilities implicates laws including, among others, the Federal Trade Commission Act and the Gramm Leach Bliley Act. It is critical that companies and their vendors relying on Log4j act now, in order to reduce the likelihood of harm to consumers, and to avoid FTC legal action."

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

FTC Warns of Legal Action Against Organizations That Fail To Patch Log4j Flaw

Comments Filter:
  • If the companies that used the Log4j library are prosecuted, will they in turn try to file a (civil) suit for damages against the designers or programmers who made the poor choices? Will failure to configure the library appropriately to avoid the problem be a defense? Inquiring minds want to know!
    • IMO:
      No, unless the library in question was designed to be malicious in nature.
      No, if you fail to follow the proper guideline and cannot come with a good reason as to why.
    • by NFN_NLN ( 633283 ) on Wednesday January 05, 2022 @01:47PM (#62145613)

      If the users of libraries can't hold the library creators responsible (they can't guarantee no bugs or holes), WHY would they take that liability on? Inquiring minds want to know!

      https://www.gnu.org/licenses/g... [gnu.org]

      "For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software. For both users' and authors' sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions."

      • by gweihir ( 88907 )

        Simple: Commercial software usually effectively comes with no warranty as well, but has that hidden behind some legalese wall.

      • by laktech ( 998064 )
        so don't use GPL products if they don't provide the warranty that you desire for your users!
        • by NFN_NLN ( 633283 )

          You went the wrong direction. Even commercial software can't make those guarantees. Grand-parents entire premise of suing someone for an honest mistake is flawed, both in law and computing science. Commercial software *might* be better than opensource, or it might be worse but neither can make absolute warranty that there won't be bugs.

          • by Xenx ( 2211586 )
            Well, they could make warranty there won't be bugs. A warranty is just a promise to cover damages within the terms offered. It doesn't promise to be bug free, which is what it sounds like you're actually trying to say.
        • And what warranty coverage do you desire? In the case of commercial products, no manufacturer guarantees that their product is 100% defect free. At best there are rules and regulations to correct for defects. In this case on an open source product, there is a patch. The FTC says you should patch if you intend on using Log4i in the future. Or remove the software to avoid further vulnerabilities.
    • by gweihir ( 88907 )

      Depends on the software license. Usually FOSS comes with "no warranty of any kind" and they are in the clear. Note that most COTS software (like, for example, all Microsoft stuff) comes with the same, but they try to hide that fact.

    • by UnknowingFool ( 672806 ) on Wednesday January 05, 2022 @02:36PM (#62145801)

      If the companies that used the Log4j library are prosecuted, will they in turn try to file a (civil) suit for damages against the designers or programmers who made the poor choices? Will failure to configure the library appropriately to avoid the problem be a defense? Inquiring minds want to know!

      Then those users should understand what "legal liability" means. In this case the FTC is warning companies that knowingly using a defective product after they have been warned not to use that product (without fixing the product) opens them up for legal liability. This is no different than when a consumer does not fix a car ignoring a recall by the manufacturer. If someone dies in that car, then the consumer is subject to legal liability. They could try to put the blame on the manufacturer but I doubt they would get far legally.

      For example, like millions of others, my car had airbags that were recalled [wikipedia.org]. In that exact case, multiple car manufacturers were affected who used Takata airbags. Now if I ignored the recall and someone was hurt or died due to faulty airbags in my car, who would be liable? Me. In my case, it was all over the news, and I was sent a letter. Also my car dealership alerted me that a recall was pending and I should schedule an appointment for the work. I could not say that I was not notified.

    • They should probably all be jailed just for using Java, but it's never gonna happen.

    • Well NOO... it's not the librarys fault you're logging user provided input as-is.
  • Oh wait, you're still on JDK 8? Nevermind.

    • by Petersko ( 564140 ) on Wednesday January 05, 2022 @03:11PM (#62145921)

      "What's a pom? We don't have developers. We paid to have it made."

      "Talk to the vendor? They wanted more than we could afford for a contract."

      "Talk to a lawyer? The vendor went out of business a couple of years ago."

      Hire another vendor? The pandemic has crippled us financially."

      "Shut it off? It's our whole intake system for work."

      "Learn to code? Are you out of your fucking mind?"

      • by Shaeun ( 1867894 )

        "What's a pom? We don't have developers. We paid to have it made."

        "Talk to the vendor? They wanted more than we could afford for a contract."

        "Talk to a lawyer? The vendor went out of business a couple of years ago."

        Hire another vendor? The pandemic has crippled us financially."

        "Shut it off? It's our whole intake system for work."

        "Learn to code? Are you out of your fucking mind?"

        If you can't afford to play the game, then don't play.
        Sounds like a "We're going bankrupt" company to me...

      • So what you're saying is the Log4J vulnerability is a jobs program?

  • I hope there is a trend where if corporations ignore federal warnings they are subject to big leak lawsuits.

  • Sadly, the language from the article states that reasonable action must be taken and that doesn't necessarily mean patch:

    “The FTC intends to use its full legal authority to pursue companies that fail to takereasonablesteps to protect consumer data from exposureas a result of Log4j,or similar known vulnerabilities in the future,” the FTC said, adding that it plans to apply its legal authority to protect consumers in the cases of “similar known vulnerabilities in the future.”

    What I hate about language like this is that reasonable action could be as simple as saying "we don't allow external user inputs into our systems that aren't processed for invalid values." Or it could be something like "this app is used internally only by authorized users." While it's true that those are valid risk mitigators (though the effectiveness can easily be challenged) it's not th

    • So, the government is supposed to patch your lame internet facing Quake server or just shut it down?

      • No, the government is not supposed to patch it. That responsibility belongs to the organization using the software. What I'm trying to say is that "reasonable steps to protect consumer data" is NOT the same as patching. Yes, patching could be one of the options but many times organizations just mitigate things with varying degrees of success. Once you tell the government you put a mitigator in, I bet they'll just back down and say oh well. Plus, we haven't even gotten into the part where most organizations
    • Because patching Log4j is only one thing that a company can do and the FTC probably does not want to proscribe only one course of action. Companies can turn off and uninstall log4j if they want to remove the vulnerability. Companies can use alternatives.
      • Non-Patch (Score:4, Interesting)

        by JBMcB ( 73720 ) on Wednesday January 05, 2022 @03:24PM (#62145963)

        You can mitigate the issue by shutting off the JNDI remote call in the Java runtime. From what I understand, not a lot of software uses that feature, as it's done better and more safely by various enterprise libraries. There's a library you can load into your software that does it for you. You don't need to recompile anything, as an end-user you can add the library to your runtime.

        https://research.nccgroup.com/... [nccgroup.com]

      • You can't force a third-party application that your company uses to patch/mitigate Log4j. I get the not prescribing a course of action but some companies are going to use the software anyway, even if log4j has not been mitigated. And yes, you can alter your Java runtime and other things but that's not the point. Remove log4j from the equation and replace it with any other library and you get a giant mess. All I'm saying is it doesn't seem enforceable because companies will always say they took reasonable ac
        • The FTC says very specifically: "The duty to take reasonable steps to mitigate known software vulnerabilities implicateslaws including, among others, the Federal Trade Commission Actand the Gramm Leach Bliley Act.It is critical that companies and their vendors relying on Log4j act now, in order to reduce the likelihood of harm to consumers, and to avoid FTC legal action." The FTC is not saying companies MUST patch. The FTC says companies must take action. Like I said earlier some companies can use alternati
  • by gweihir ( 88907 ) on Wednesday January 05, 2022 @01:52PM (#62145629)

    For anybody that has still not patched things. There is really no other way of seeing this. Of course there will be many IT departments and many projects so dysfunctional that they simply cannot get it done. The cost of hiring "cheap" people.

    • If this is an ancient software package or hardware device distributed with no ongoing service contract or way EOL, why should the vendor do anything at all? What if it was free / open source? I get it if you're a business using log4j internally, but it sure doesn't seem to make any exceptions at all and so probably wouldn't have any legal grounds at all.

      • I don't think gweihir was talking about vendors needing to patch, but users.
        If you're running a public-facing service that is vulnerable to this exploit, you've already been told to stop doing it and why.

        • Maybe they're not, but FTC doesn't seem to specify - which is problematic.

          • by Shaeun ( 1867894 )

            Maybe they're not, but FTC doesn't seem to specify - which is problematic.

            TFA is pretty clear it's about the loss of PII due to this flaw.
            if you are using log4j with PII, you should be fined if you do not fix it.

        • by dstwins ( 167742 ) on Wednesday January 05, 2022 @03:00PM (#62145881) Homepage

          Considering the only way to get anything done in the US is if the cost of "not doing something" is higher than actually doing something.. this action is sorely needed.

          In the financial sector, and many other industries, companies run legacy/outdated systems and routinely ignore well known vulnerabilities simply because they have the luxury of passing the financial impact off to the end consumer so there is no real impact to them (other than negative press which given how much stuff goes on and how short the average american's attention span is, even that's not really much of a pain point).. So if the FTC steps in and fines the company AND makes it illegal to simply gouge the customer/end user to compensate.. Then some actual change/improvements will come about..

          But until that time, its pretty much business as usual.. "Oh, that 1M fine.. sure, we will pay it, and then spread it out as 0.25c per customer per month/period"

          • by gweihir ( 88907 )

            Considering the only way to get anything done in the US is if the cost of "not doing something" is higher than actually doing something.. this action is sorely needed.

            Pretty much. In Europe, if somebody steals all your customer data because you have not patched log4j for too long, that could get you in pretty hot water due to the GDPR, up to and including prison time (possible but unlikely) for those responsible. In the US, it will be news for a day and then everybody will again forget about it.

      • Comment removed based on user account deletion
    • Then good labor. At least on a large enough scale. On a large enough scale flooding the market with cheap labor massively depresses wages allowing you to pay significantly less overall for your labor. If you're running a small or mid-sized business you don't really think this way. But if you're the CEO of a megacorp these are actual can daily considerations and a part of your job.

      Everyone likes to think of a part of a CEO's job or their iron Man style visionaries. But nobody thinks about how they impact
  • Owners of small to medium businesses who had the wherewithal to get a custom application done by a vendor, but not to continue to pay an ongoing eternal "maintenance contract". They may or may not have the source code... they might not have the ability to compile and run it if they do... it might need non-trivial conversion from Java 6... they may not even know yet that they're at risk. They may never know.

    Note that this isn't unique to Java, even if this is a particularly awful example. I remember discover

    • by Shaeun ( 1867894 ) on Wednesday January 05, 2022 @03:25PM (#62145969)

      Owners of small to medium businesses who had the wherewithal to get a custom application done by a vendor, but not to continue to pay an ongoing eternal "maintenance contract". They may or may not have the source code... they might not have the ability to compile and run it if they do... it might need non-trivial conversion from Java 6... they may not even know yet that they're at risk. They may never know.

      Note that this isn't unique to Java, even if this is a particularly awful example. I remember discovering I couldn't patch a huge security hole in a mission critical product because an open source library dependency had deprecated Solaris support a few years previous. We ended up doing a costly linux port instead. It could be done because the resources of the company were enormous. A smaller enterprise would have struggled.

      It's bite the bullet or close the doors time if you are in that situation with Log4j. Open source isn't free. It still has to be maintained, and that still costs money. If you can not afford to maintain your software, you probably shouldn't be using said software. It is harsh, but it is true. Nothing is eternal, and all equipment wears. Digital assets are no different.

      • There's an assumption here that the described owners knew they were getting something with open source components.

        Since consultants and vendors are always extremely diligent in marching prospective clients through details like these and their implications, I guess we can let that slide.

  • Still calling it zero-day next year?

  • If they can fine organizations for failing to patch this kind of flaw, then they could probably fine organizations for not using or keeping their malware scanning software up to date as well, don't you think?
  • by bustinbrains ( 6800166 ) on Wednesday January 05, 2022 @05:27PM (#62146483)

    The only Java programming I do these days is a couple of little Android apps. And those are mostly glorified web apps. I hate starting Android Studio so I generally avoid launching it for 6+ months because Google decides to deprecate and obsolete everything every 2 weeks. A couple of years ago, I was about to publish a new version of one app and Android Studio updated that same day and literally broke the application that was ready to go by deprecating and removing functionality from the import libraries! Took two days to figure out how to fix the build so it would compile again. Java is awful but Android (and Google/Alphabet) is somehow much worse.

    There are plenty of far better programming languages to choose from.

  • FTC should provide a DNS server to query against and instruct the public to use a payload that queries it.

  • by esev ( 77914 )

    Where was the FTC 5 years ago with CVE-2017-5638 and Equifax?

So you think that money is the root of all evil. Have you ever asked what is the root of money? -- Ayn Rand

Working...