Bogus CVE

[mrocklin]

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]

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]

If it's a good idea then I don't mind anyone doing it. I don't think we need to do anything in response to this particular CVE though (except complain about it). I don't think this event should sway us meaningfully.

…

On Fri, Mar 21, 2025 at 11:44 AM Jacob Tomlinson ***@***.***> wrote: 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 <https://distributed.dask.org/en/stable/limitations.html?highlight=host#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. — Reply to this email directly, view it on GitHub <#415 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACKZTDOVU53TWPIILYZNRT2VQ6XZAVCNFSM6AAAAABZQDEYUWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBTHEYTGMBYGA> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: jacobtomlinson]*jacobtomlinson* left a comment (dask/community#415) <#415 (comment)> 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 <https://distributed.dask.org/en/stable/limitations.html?highlight=host#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. — Reply to this email directly, view it on GitHub <#415 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACKZTDOVU53TWPIILYZNRT2VQ6XZAVCNFSM6AAAAABZQDEYUWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBTHEYTGMBYGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[TomAugspurger]

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]

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]

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

[TomAugspurger]

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]

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

[lesteve]

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.

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

[adam-nygate]

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]

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

[lesteve]

@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 😉.