search

haskell / security-advisories

https://haskell.github.io/security-advisories/
Other
46 stars 18 forks source link

HSEC-2024-0003: process: command injection on Windows #188

Closed TristanCacqueray closed 7 months ago

TristanCacqueray commented 7 months ago

Advisory

bgamari commented 7 months ago

process-1.6.19.0 has been released.

TristanCacqueray commented 7 months ago

Great, thank you @bgamari !

frasertweedale commented 7 months ago

Whoops, I typo'd the fix version as 1.16.19.0 instead of 1.6.19.0. I just pushed a commit to fix that, directly to main.

hasufell commented 7 months ago

process-1.6.19.0 has been released.

So this release violates PVP?

frasertweedale commented 7 months ago

@hasufell see discussion at https://github.com/haskell/security-advisories/blob/main/advisories/hackage/process/HSEC-2024-0003.md#fix-versions. The scope of behavioural change is as restricted as possible: https://github.com/haskell/process/commit/3c419f9eeedac024c9dccce544e5a6fb587179a5#diff-eca1a11435b6f39e5c276338597973782ee72e6d17d2aa429df113f817aa224a

hasufell commented 7 months ago

I find the reasoning questionable.

Did we just admit that PVP is a failure when it comes to security updates?

frasertweedale commented 7 months ago

@hasufell https://pvp.haskell.org/ doesn't even talk about behavioural changes, only API changes. But morally, I agree that potentially breaking behavioural changes would usually warrant a major release but...

A program (or user) may rely somehow on buggy behaviour. Can we never fix a bug without bumping the major version?

Especially when it comes to security issues, it is appropriate to balance the likelihood of a behavioural change breaking something, and the ease of adoption by users (major version bumps cause more pain or toil).

PVP is an important guideline and valuable tool. A carefully considered deviation from (some interpretation of) it does not mean it is a failure.

bgamari commented 7 months ago

@hasufell as far as I can tell the PVP does not give a definitive prescription here. The PVP's MUST prescriptions are all to do with the overall shape of the exposed declarations (that is, names, types, and children) and orphan instances.

However, my initial inclination was very similar to yours; it feels wrong to change the behavior of a function in a minor release. Despite this, after discussion @tomjaguarpaw and I came down on versioning the new release with a minor bump; this determination was made in light of the facts that:

These considerations were weighed against the fact that a major bump would have made it extremely difficult for us to ensure that this change can be distributed with future minor GHC releases. Afterall, we have historically maintained a policy of avoiding major version bumps in core libraries in such releases. This policy is what ensures that users can readily migrate to new minor GHC releases and benefit from the correctness and security fixes that they bring.

hasufell commented 7 months ago

These considerations were weighed against the fact that a major bump would have made it extremely difficult for us to ensure that this change can be distributed with future minor GHC releases. Afterall, we have historically maintained a policy of avoiding major version bumps in core libraries in such releases.

Sure. What I mean is this: what if the next time a security bugfix in a boot library requires changing types/exposed API?

Something doesn't seem right. Are we unable to ship such bugfixes swiftly across the Haskell ecosystem?

This seems like a far reaching problem:

I'm not so much arguing about the current decision, but it's an opportunity to open this discussion.

frasertweedale commented 7 months ago

Sure. What I mean is this: what if the next time a security bugfix in a boot library requires changing types/exposed API?

...

I'm not so much arguing about the current decision, but it's an opportunity to open this discussion.

Thank you for opening the discussion.

In my experience, security issues requiring a breaking API change are uncommon. What I have sometimes seen is an issue that prompts an API change (e.g. to ensure safer usage of the library) for the future release series, with the issue resolved in some other way that does not break API compatibility for existing supported release branches.

It would be worthwhile to consider what we could/should do in plausible "worst case scenarios", and write them down. Also to identify barriers that prevent or nullify the ideal or preferred response (you already pointed out some specific problems above).

hasufell commented 7 months ago

In my experience, security issues requiring a breaking API change are uncommon.

Well, I think that mostly applies to C. We don't have a lot of knowledge in Haskell about it.

The most prominent recent-ish security bugfix was aeson-2 and it did break API.

GHCup had a severe bug that could have qualified as a vulnerability (not code execution, but filesystem corruption) and fixed it through breaking API.

I think it's much more common in Haskell to fix unexpected computation through encoding more invariants in the type system.

It would be worthwhile to consider what we could/should do in plausible "worst case scenarios", and write them down.

Yes, the problem right now is that I as a core library maintainer rely on GHC HQ to sorta ship security bugfixes in time, which I don't feel is a good strategy.

frasertweedale commented 7 months ago

@hasufell thanks for reminding me of the aeson situation (and fix). Could you please point to more info about the GHC filesystem corruption bug? I wasn't aware of it.

hasufell commented 7 months ago

Could you please point to more info about the GHC filesystem corruption bug? I wasn't aware of it.

That was GHCup.