glogow at fbihome.de
Mon Feb 22 00:25:20 UTC 2021
Am 21.02.21 um 23:08 schrieb Andrew Udvare:
> On 21/02/2021 16:43, Rene Engelhard wrote:
>> And LibreOffice Online *does* use npm.
>> So while LibreOffice itself shouldn't be affected, conceptually by using
>> npm LibreOffce Online is.
> I think if you use 'npm install' (or 'yarn install'), the manager should
> be pulling in the correct version and then hash checking based on the
> contents of the .lock file. Running `npm update`, `npm install <new
> package>` or similar may be affected.
It's not a bug in a package manager. It your insecure setup for internal
packages / repositories.
> The real issue is when a new dependency gets added or updated but
> everything seems normal, in that the replacement dependency has stubs to
> not make the code crash, but also does nefarious things in the
> background. There would be no way to know without deep inspection, and
> npm dependency trees are usually huge.
No. Hiding would be a bonus, but at this point the attacker already had
RCE, which would compromise you, even if you detect it.
This is all about hijacking (optional) known / public dependencies. But
there are mitigations available.
The attacked companies used some optional internal package. Normally
they get this from an internal repo, but now someone hijacked the name
in the official repo with a huge version number, so it would be
preferred over the internal package. Result: pwned.
is a good summary of mitigation strategies. But you need to provide a
That document omits Linux package managers and repositories, but the
same attack and mitigations would apply to them. But since you normally
can't just register a package in Linux distros, that risk is much lower.
OTOH just imagine a malicious postinst script in a deb in some PPA.
More information about the LibreOffice