ghc 9.8 support / process vulnerability on Windows ?

[simonmichael]

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

• [x] fix a hfsevents build error blocking hledger-ui, https://github.com/luite/hfsevents/issues/16
• [x] drop allow-newer after https://github.com/stackbuilders/cassava-megaparsec/issues/39
• [x] re-enable the partial function warnings and fix them all
• [x] test/benchmark
• [x] release
• [ ] re-enter stackage nightly (https://github.com/commercialhaskell/stackage/issues/7215, https://github.com/commercialhaskell/stackage/pull/7405)

[blackgnezdo]

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

[simonmichael]

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

https://github.com/commercialhaskell/stackage/pull/7405

[simonmichael]

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

[simonmichael]

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]

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]

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]

1.33.1 released with relaxed process bound.

[simonmichael]

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