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.
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
