An article in today's Register, https://www.theregister.com/2022/05/23/npm_dependencies_vulnerable/ has got me thinking. One quote from it is "These 2,415 people with these email addresses are currently more trusted than your own software engineers as they can effectively run any code they want on your production infrastructure without review from anyone". When the Log4J vulnerability appeared, I found out (I hardly ever use Java) that the offending module could be in any .jar without it being obvious to the programmer. At least, when I install a CPAN module, I can see a list of the modules it brings with it, even if I don't usually pay enough attention. But sometimes I need to be very security conscious.

Looking for vulnerabilities in CPAN took me to https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=cpan. There's not a lot there, and many of them are closed in the latest version. But looking at one of them, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4184, I see that the module was updated <update>last month two years ago, seven years after the vulnerability was reported</update>, but that there is nothing in the changes file to indicate that the vulnerability has been addressed even though it's nine years old. Nor is there anything in the docs even acknowledging the existence of the vulnerability.

The changes file does, however, reveal another worry.

1.148 Thu Nov 16 10:21 2006
- Debian has chosen to distribute their own Data::UUID, which has a different interface and breaks other modules.

What, then, do people do in the real world? Are checks for CVEs enough? Do people do code reviews of every module they use in every language? It sounds beyond the bounds of reasonability to me. Are there certifications for modules (and if so, who certifies the certifiers - that old question)? I know people who prefer to install Perl packages on Debian via apt because it makes them easier to delete, but the quote above makes me fear that the CPAN and apt packages need not be the same.

Regards,

John Davies

Update: I read the date carelessly & got it wrong. Thanks, Hippo.

Replies are listed 'Best First'.
Re: Libraries and security
by mr_mischief (Monsignor) on Jun 20, 2022 at 18:07 UTC

    This may be a bit oversimplified, but a search of metacpan for UUID returns 355 results. If I was maintaining code against a module upstream that seemed unresponsive to security threats, I'd consider a PR to that module and, failing that, a PR to the code using it to retarget against another module.

    One thing to remember with any of these systems is not to either stay stuck on old versions past their usefulness nor blindly update to the latest versions without looking. People get into the habit of not updating, which keeps you from getting fixes. Other people get in the habit of updating in automation without reviewing the changes, which allows supply chain attacks. If you're using a CVE-tracking system like Mitre, they'll tend to tell you in which versions a vulnerability was fixed. The module's changelog should mention the CVE and that it was addressed, too.

    If you do want to do your own security review of every piece of code you use, more power to you. I wish you the best. Yet most developers are not security experts and many security experts are not software developers. There are certain overlapping skills one needs to do a thorough and reliable security review of code. Checking against a single known vulnerability disclosure is a bit easier, but not everyone is ready to do that. I would suggest most developers trust the disclosure/correction/reported correction cycle of systems like the CVE reporting sites, complete with CVSS. If you can show a known vulnerability and can show it hasn't been addressed, move on to different dependencies if you can.

    In some cases it's possible to look at the CVSS breakdown, look at how your code is used, inspect how your code uses the dependency, and determine a way to acceptably mitigate risks in unpatched dependencies. That, again, is neither purely development nor purely security knowledge.

    Your core concern appears to be that developing software which faces an unknown public is not easy to do securely. To that, I can only say that you're absolutely correct. It is not a simple process to assemble multiple pieces from multiple internal and external parties, do some integration around them, deploy them to public-facing systems, and have a reasonably secure system. There are ways to make it easier, but not to make it easy. Many of the ways to make it easier do not make it less expensive. Such is life.

[reply]
Re: Libraries and security
by hippo (Archbishop) on May 23, 2022 at 20:22 UTC
    I see that the module was updated last month

    The last release looks to be 1.226 from 2 years ago. Did you mean something else?

    🦛

[reply]
Re: Libraries and security
by etj (Priest) on Jun 05, 2024 at 17:47 UTC
    The only way to be sure is to read all the source code. That includes the source code for the OS kernel and utilities, and also all the microcode in all the various bits of hardware.

    Or, one can assess and manage risk in a way that balances cost and benefit.

[reply]

Back to Meditations