dependency-confusion

[Jan-Marek Glogowski]

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.

The linked 
https://azure.microsoft.com/de-de/resources/3-ways-to-mitigate-risk-using-private-package-feeds/ 
is a good summary of mitigation strategies. But you need to provide a 
secure setup.

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.