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

[TristanCacqueray]

Advisory

• It's not duplicated
• All fields are filled
• It is validated by hsec-tools

[bgamari]

process-1.6.19.0 has been released.

[TristanCacqueray]

Great, thank you @bgamari !

[frasertweedale]

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]

process-1.6.19.0 has been released.

So this release violates PVP?

[frasertweedale]

@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: haskell/process@3c419f9#diff-eca1a11435b6f39e5c276338597973782ee72e6d17d2aa429df113f817aa224a

[hasufell]

I find the reasoning questionable.

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

[frasertweedale]

@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]

@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:

• the change affects only a small number of cases (.bat and .cmd files on Windows)
• the new behavior should be functionally equivalent to the old behavior in all but a very small number of cases

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]

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:

• users depending on ghc the library get locked in (it should be reinstallable)
• cabal users don't get the security update by default: Special treatment of pre-installed packages by the solver cabal#9669
• no defacto standard yet to audit your dependencies
• what about stackage?

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

[frasertweedale]

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]

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]

@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]

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

That was GHCup.

• https://gitlab.haskell.org/haskell/ghcup-hs/-/merge_requests/253
• https://github.com/haskell/ghcup-hs/blob/master/CHANGELOG.md#01178----2022-05-11
• haskell/ghcup-hs@991e540
• https://discourse.haskell.org/t/ann-ghcup-0-1-17-8-bugfix-release/4510