[GTALUG] security threats of Open Source

David Thornton northdot9 at gmail.com
Fri Nov 20 15:25:42 EST 2020


As administrators we have a responsibility to vet. Even if it's to
"deligate" the vetting, we have to vet the deligate.

Npm is a hot mess, and most people get that now.

Galaxy / puppetforge / helm stuff ? Take a number.

It sprouts faster than you can get on it sometimes.

Pays the mortgage :)

David

On Sat, Jan 25, 2020 at 4:05 PM D. Hugh Redelmeier via talk <talk at gtalug.org>
wrote:

> | From: Dhaval Giani via talk <talk at gtalug.org>
>
> | On Thu, Jan 23, 2020 at 11:08 AM D. Hugh Redelmeier via talk <
> | talk at gtalug.org> wrote:
> |
> | > <
> | >
> https://www.zdnet.com/article/microsoft-spots-malicious-npm-package-stealing-data-from-unix-systems/
> | > >
> | >
> | > This article list six cases of malware contributed to npm (the repo for
> | > sharing node.js and JavaScript source).
> | >
> | > How many undetected cases exist?
> | >
> | > I've alway pretended that Linux distros vet their code.
> |
> |
> | They do, but npm is different. npm is indepdent of the distro itself. And
> | people want to use npm because it gives them the latest and the greatest.
>
> I'm sorry that I wasn't clearer.
>
> I was changing the subject a bit.  Just like npm has problems because
> vetting contributions is a hard problem, so too Linux distros have
> problems because vetting contributions is a hard problem.
>
> I know npm (JavaScript), CPAN (perl), CTAN (TeX), CPAN (Python),
> github, probably crates.io (Rust), etc. each bypass the disto.
>
> Any security flaws identified by a distro get fixed by updates but
> anything users sourced from these other repos will not be fixed by
> distro updates.  A serious logistic problem for users, even if they
> are unaware of it.
>
> I try to avoid these repos for just that reason but it is kind of
> hard.
>
> | >   I'm not sure how
> | > true that is.  Probably the greatest protection is the time delay
> between
> | > contribution and distribution.
> | >
> | >
> | I would be wary of this approach. There are a bunch of security fixes,
> | where you probably don't want too long a delay. Part of responsibility
> also
> | lies on the user to validate the update. With it being open source, and a
> | "volunteer" model, some of that has to be accepted b the user.
>
> Sorry, I meant: the time delay between creating a piece of software
> and it being adopted by Linux distros.  Not a delay because the user
> avoids distro updates.
>
> I imagine the barrier to contributing to npm is zero.  But I don't
> actually know.  See below.
>
> The barrier to contribution to any distro I know of is a bit higher.
> That involves time, effort, and creativity.  But not enough to prevent
> a determined and skilled contributor of malware.  The easiest way is
> probably to infiltrate a group that produces a piece of software
> already accepted by many distros.  Then it depends on the vetting by
> that project.
>
> More on npm:
>
> <https://en.wikipedia.org/wiki/Npm_(software)>
>
> npm is the "Node Package Manager".  It accompanies node.js.  It hooks
> up to a "registry", by default nodejs.com (a commercial entity).
> Here's a bit from Wikipedia (all caps added by me):
>
>         Over 477,000 packages are available on the main npm
>         registry.[16] The registry has NO VETTING process for
>         submission, which means that packages found there can be low
>         quality, insecure, or malicious.[15] Instead, npm relies on
>         user reports to take down packages if they violate policies by
>         being low quality, insecure or malicious.[17] npm exposes
>         statistics including number of downloads and number of
>         depending packages to assist developers in judging the quality
>         of packages.[18]
> ---
> Post to this mailing list talk at gtalug.org
> Unsubscribe from this mailing list
> https://gtalug.org/mailman/listinfo/talk
>


-- 
David Thornton
https://wiki.quadratic.net
https://github.com/drthornt/
https://twitter.com/northdot9/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20201120/ac0eee41/attachment.html>


More information about the talk mailing list