Skip to content

Bogus CVE #415

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mrocklin opened this issue Mar 21, 2025 · 11 comments
Open

Bogus CVE #415

mrocklin opened this issue Mar 21, 2025 · 11 comments

Comments

@mrocklin
Copy link
Member

There was a Bogus CVE published about Dask yesterday (apparently it's possible for a Dask user to run arbitrary Python code on a Dask server)

I wrote a small response on HN here: https://news.ycombinator.com/item?id=43435855

@jacobtomlinson
Copy link
Member

Whenever this kind of thing comes up it makes me wonder "should Dask require some kind of authentication to connect to the scheduler by default?". But realistically you're not exposing your scheduler to the internet, so your security is done at the network level.

I wonder if we should expand the docs about security to explain in more depth that Dask doesn't have authentication, and if you want authentication then you should use an external auth layer to provide it.

@mrocklin
Copy link
Member Author

mrocklin commented Mar 21, 2025 via email

@TomAugspurger
Copy link
Member

We had a similar report for pandas (pandas-dev/pandas#60602 (comment)).

@AfterSnows, @ethansilvas, @huntr-helper I see your handles on https://huntr.com/bounties/a4be847b-a52d-42cc-9e78-3299e2d30ab2 (same folks as from pandas-dev/pandas#60602 (comment). Hi again!) could you retract that report / CVE? And maybe adjust something about your workflow so that this doesn't keep happening?

For pandas we did try to head this off by putting a list of things we don't consider to be vulnerabilities at https://github.com/pandas-dev/pandas/security/policy. I'm pessimistic that it'll have an impact.

@TomAugspurger
Copy link
Member

For those wondering, I think trying to get the CVE retracted is worth a few minutes of effort. Some companies actually do put weight on these CVE reports so having a bogus one floating out there can cause headaches for our users.

@jacobtomlinson
Copy link
Member

@TomAugspurger yeah I agree, do you know what the process is for doing this?

@TomAugspurger
Copy link
Member

The only thing that's worked in the past has been the original reporter retracing the reported vulnerability, so hopefully @AfterSnows or @ethansilvas can take care of that.

I've never had luck trying to work directly with a CVE authority directly.

@mrocklin
Copy link
Member Author

I've pinged @ethansilvas by e-mail. Tom and Jacob, you're cc'ed. (@AfterSnows didn't have a listed e-mail)

@lesteve
Copy link
Member

lesteve commented Mar 25, 2025

FWIW Huntr has not been very useful for us (scikit-learn + joblib), i.e. most reports are slop that take time to process and the Huntr interface is not great ...

Too late for this particular CVE, but my understanding of Huntr is that if you had "resolved" the report as one of "Informative" (thanks for the info but not a real security issue), "Duplicate", "Not Applicable" or "Waste of time" a CVE would not have been opened.

Image

Once you resolved it, the report is made public e.g. here is an old scikit-learn report.

@adam-nygate
Copy link

Hi - Adam here from the huntr team.

TL;DR: we're withdrawing the CVE and updating our process to ensure we don't issue them without maintainer agreement.

Whilst we think the underlying vulnerability is valid, as a policy, we want to align ourselves with project maintainers and so if they don't want a CVE being issued, there shouldn't be one.

We're also updating our OSV program's processes to ensure we don't issue CVEs unless a maintainer agrees with it.

On a side note, I appreciate the feedback on this thread. We're heads down at the moment working on some big changes to the program and the feedback here allows us to better prioritize and ensure that we work in a direction that benefits the OSS community the most.

If anyone has any other feedback or would like to get in touch with me directly - feel free to ping me an email: adam (at) huntr (dot) com

@mrocklin
Copy link
Member Author

Thanks @adam-nygate ! That's great to hear, both on our specific case, and on reviewing current processes.

@lesteve
Copy link
Member

lesteve commented Mar 27, 2025

@adam-nygate my main wish would be for Huntr to be integrated into GitHub security advisories so that the conversation (plus possible private PR) happens inside GitHub which is an interface we are all familiar with. I am guessing this is a lot of work and there may be tricky permission aspects to sort out.

I also sent you a few smaller/lower-priority annoying Huntr quirks by email 😉.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants