plugin-ext: validate path when unpacking archives

[paul-marechal]

What it does

Fix zip-slip by validating where a given file will be unpacked. If the
expected path is outside of the destination folder: log a warning and
ignore the file.

Fixes #7319

How to test

Tests should fail if you comment lines 32 to 44 in plugin-deployer-file-handler-context-impl.ts.

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[vince-fugnitto]

While I'm fine with having safety measures for zip-slip (arbitrary file-write) including the additional tests, I think we should still look for a replacement to decompress. The project is not actively maintained and will likely cause more issues going forward. In addition, since the flaw is not patched in decompress, the security vulnerability will still show up for @theia/plugin-ext. Also, if someone still happens to use decompress in another area of the code, it will not benefit from the same patching.

It looks like we only need a dependency capable of handling zip archives so it should be easy to find a maintained alternative.

cc @marcdumais-work

[paul-marechal]

TBH I don't really care. I like decompress because it handles several extensions at the time. The vulnerability only happens when you let the library unpack without validating anything on the user side, which this PR adds.

I'll still update this PR based on Anton's comment, feel free to open a separate PR that would replace the dependency by something else if this is an hard requirement.

[marcdumais-work]

Also, if someone still happens to use decompress in another area of the code, it will not benefit from the same patching.

I find this to be a compelling argument. If we keep decompress it will always show-up as a known vulnerability for the platform and applications that use plugin-ext. We'll need to explain that we took steps so that the vulnerability is not triggered for our use-case, and that it can be safely ignored. After a little while we will just ignore it, knowing that "it's ok in this case", which can lead to problems if the library gets used in other places without taking these protective steps.

[paul-marechal]

Preferred way is to change the dependency.