search

ossf / malicious-packages

A repository of reports of malicious packages identified in Open Source package repositories, consumable via the Open Source Vulnerability (OSV) format.
Apache License 2.0
230 stars 20 forks source link

NPM packages with namespaces from ReversingLabs don't have namespace in name. #555

Open calebbrown opened 3 months ago

calebbrown commented 3 months ago

As at the time of reporting the number is 232 in NPM.

For example @zettle-bo/react is listed as react.

calebbrown commented 3 months ago

I will pause the reversing labs ingestion to ensure no new data is ingested until we have confirmed a fix.

Errant reports can either be corrected (moved to the correct location) in the case that the report doesn't yet exist, or withdrawn if the do.

calebbrown commented 3 months ago

@rhalar

G-Rath commented 3 months ago

fwiw it looks like https://osv.dev/vulnerability/MAL-2024-3239 is also a result of this which is a version that actually overlaps with a valid used version - it would be good to know how we can get these invalid advisories cleared since they're being flagged by the scanner.

I also wonder if osv.dev should be doing some validation around the PURLs as it sounds like they're invalid so maybe the affected field or the whole advisory be rejected rather than ingested?

calebbrown commented 3 months ago

False positives and data problems have been resolved. Some Reversing Labs reports need to be re-added, but that is less urgent.

rhalar commented 3 months ago

Hey,

to clarify for anyone affected or following this issue, I work for ReversingLabs and am 'in charge' for exposing our advisories, and as such responsible for this mess :) I contacted Caleb and we will resolve the source of the problem very soon, to avoid any further problems with the data we expose.

I'd like to apologize for any alarms this may have triggered, it was a dumb oversight we should have caught, and I take the full blame for it. A huge shutout and thanks to @calebbrown for doing damage control and reacting so quickly.

Our security researchers work hard and do a great job at finding malicious packages across multiple ecosystems, I hate to see their work besmirched by what is essentially a conversion error by my side; we'll make sure this doesn't happen again.

It's not the best first impression but we are very excited by this collaboration, and hope to continually contribute to the OSSF going forward.

calebbrown commented 3 months ago

The data fixing is now complete. I will close this issue once I have un-paused the reversing-labs source in the config.

lujunsan commented 2 months ago

Hi @calebbrown . It looks like some packages are missing from the "withdrawn" list, such as NPM qs (osv) or NPM angular (osv). Both of these were reverted because of this issue but they were not added to the withdrawn directory, which is causing some inconsistencies in our systems.

calebbrown commented 2 months ago

@lujunsan I have fixed the summaries as well. Those reports are now clearly for @ozon-shared-deps/qs and @maia-web/angular.

Is your issue that the OSV files now point to different packages, despite previously pointing at angular and qs?

lujunsan commented 2 months ago

Hi @calebbrown . I was under the impression that these packages that were at some point marked as malicious but later fixed should also be added to the "withdrawn" list, same as what was done for react: https://github.com/ossf/malicious-packages/blob/main/osv/withdrawn/npm/react/MAL-2024-2929.json

Is this not accurate? Like you say, the reports for those packages are correct now (and thanks for regenerating the summaries!), nothing to change there; I was just expecting to also find those fixed packages with entries in the withdrawn list, but I may have misunderstood the process.

calebbrown commented 2 months ago

Hi @lujunsan, the problem that was corrected was that the purl field differed to the name of the package for NPM packages with a namespace.

Since it was ambiguous which package was being reported as malicious, for packages which did not have an existing report, it was decided to fix the ambiguity and move the report into the correct path, rather than withdrawing the report.

This means the MAL-* IDs are now pointing to the correct package so it is not possible to add a withdrawn report for the same IDs.

As far as I'm aware (and I plan to confirm this with the OSV team) OSV reports are designed to be mutable so they can be extended and corrected as needed. This should mean that this type of change should be okay to make.