Skip to content
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

ghc 9.8 support / process vulnerability on Windows ? #2149

Closed
6 tasks done
simonmichael opened this issue Jan 4, 2024 · 9 comments
Closed
6 tasks done

ghc 9.8 support / process vulnerability on Windows ? #2149

simonmichael opened this issue Jan 4, 2024 · 9 comments
Labels
A-WISH Some kind of improvement request, hare-brained proposal, or plea. packaging Dependencies, version constraints, packaging..

Comments

@simonmichael
Copy link
Owner

simonmichael commented Jan 4, 2024

I've updated stack9.8.yaml to make most packages build with GHC 9.8 and stackage nightly. Still to do:

@simonmichael simonmichael added A-WISH Some kind of improvement request, hare-brained proposal, or plea. packaging Dependencies, version constraints, packaging.. labels Jan 4, 2024
@simonmichael simonmichael added the needs:other-task To unblock: needs some other issue/task/event, possibly outside our project label Feb 16, 2024
@simonmichael simonmichael added needs:code To unblock: needs code/code updates needs:testing To unblock: needs more developer testing or general usage and removed needs:code To unblock: needs code/code updates needs:other-task To unblock: needs some other issue/task/event, possibly outside our project needs:testing To unblock: needs more developer testing or general usage labels Feb 24, 2024
@blackgnezdo
Copy link

FWIW, ghc-9.8.2 ships with process-1.6.18.0 which is incompatible with hledger-1.33 requiring a newer version.

@simonmichael
Copy link
Owner Author

simonmichael commented May 2, 2024

@blackgnezdo indeed. This is keeping hledger 1.33 out of stackage at the moment. I made 1.33 require process >=1.6.19.0 because it fixes a command injection vulnerability on Windows (HSEC-2024-0003, CERT CC VU#123335).

But I seem to be ahead of the ecosystem here, and the advisory says:

When executing .bat or .cmd files, CreateProcess implicitly spawns cmd.exe. The System.Process command line construction does not escape characters with special meaning to cmd.exe. As a consequence, a command injection vulnerability arises when the following conditions are satisfied:

  • Program running on Windows
  • Program executes a .bat or .cmd file
  • The argument values include or are influenced by program input

So it's not obvious how this could cause a vulnerability in the hledger tools, and perhaps it's ok to relax our process lower bound.

@simonmichael
Copy link
Owner Author

@simonmichael
Copy link
Owner Author

hledger-web is also blocked by depending on base64 <1, and will need a minor release.

@simonmichael
Copy link
Owner Author

simonmichael commented May 2, 2024

When executing .bat or .cmd files, CreateProcess implicitly spawns cmd.exe. The System.Process command line construction does not escape characters with special meaning to cmd.exe. As a consequence, a command injection vulnerability arises when the following conditions are satisfied:

  • Program running on Windows
  • Program executes a .bat or .cmd file
  • The argument values include or are influenced by program input

So it's not obvious how this could cause a vulnerability in the hledger tools

Well on the other hand..

  • hledger runs on Windows
  • the hledger CLI can execute a .bat or .cmd file (.bat I'm sure of) if it is considered an add-on (named hledger-*, in PATH)
  • The argument values are influenced by program input, since on the command line you can provide any arguments you like for the add-on command

So, is it in fact possible to do something bad by having a hledger-foo.bat in PATH and then running hledger.exe foo bad args on Windows ?

@simonmichael
Copy link
Owner Author

simonmichael commented May 2, 2024

https://github.com/haskell/security-advisories/blob/main/advisories/hackage/process/HSEC-2024-0003.md#demonstration seems to show how you could cause hledger to execute commands other than hledger addons, eg a command something like hledger foo "\"&calc.exe" could execute calc.exe. It's not clear if there's any escalation of privilege - I am guessing that anything you could run this way, you could easily run yourself at the command prompt directly, and anything you're not permitted to run, can't be run by this method either. Any Windows user who could test that ?

@simonmichael
Copy link
Owner Author

simonmichael commented May 2, 2024

I found a Windows VM. Yes, you can reproduce this issue very easily with hledger-1.33 in Powershell like so -
this runs hledger-foo.bat and also starts notepad:

PS C:\Users\Simon Michael> hledger foo "&notepad"

But a command requiring admin privilege remains unrunnable:

PS C:\Users\Simon Michael> hledger foo "&chkdsk"
hledger-foo: running
Access Denied as you do not have sufficient privileges or
the disk may be locked by another process.
You have to invoke this utility running in elevated mode
and make sure the disk is unlocked.

So I am once again thinking this vulnerability is harmless as far as the hledger tools are concerned.

@simonmichael simonmichael changed the title ghc 9.8 support ghc 9.8 support / process vulnerability on Windows May 2, 2024
@simonmichael
Copy link
Owner Author

1.33.1 released with relaxed process bound.

@simonmichael simonmichael changed the title ghc 9.8 support / process vulnerability on Windows ghc 9.8 support / process vulnerability on Windows ? May 2, 2024
@simonmichael
Copy link
Owner Author

And finally: hledger is back in stackage nightly as of nightly-2024-05-10.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-WISH Some kind of improvement request, hare-brained proposal, or plea. packaging Dependencies, version constraints, packaging..
Projects
None yet
Development

No branches or pull requests

2 participants