runinpty.py triggers CrowdStrike security alerts on MacOS #480

Closed
opened 2024-08-20 20:21:04 +00:00 by codingkoi · 3 comments

Describe the bug

A recent change to remove a dependency on expect(1) added a Python script that seems to trigger CrowdStrike security checks when it runs. As a result I've had to revert to CppNix on my work MacOS machine.

This is mostly an FYI since I'm not sure how you'd fix it (aside from reverting), or if you want to.

Here's a redacted version of the report I received:

Escalation by Falcon Complete Team

An escalation has been raised that requires your action.

Actions Required

Validate Activity

Notes on Required Actions:

At Aug. 13, 2024 22:02:53 UTC, Falcon triggered a detection on the host <HOST_NAME_REDACTED> for activity assoicated with a potential remote access software.

The following instance of Python created what appears to be an interactive instance of BASH.

Command Line: /nix/store/dgky6xnjyxriicbk3rbqycfp05niqk0v-python3-3.11.9/bin/python3 /private/tmp/nix-build-lix-2.92.0-dev-pre20240813-b016eb0.drv-0/source/build/misc/runinpty.py sh -c stty rows 0 cols 0 TERM=xterm-256color NOCOLOR=1 nix flake show

The script runinpty.py was written to disk as the result of the execution of the following script:
File Path: /nix/store/v6x3cs394jgqfbi0a42pam708flxaphh-default-builder.sh
SHA256: 6ad51d3204d86970d472da2e39d6f7c73a578913ae689676e2770e162ed58743

This appears to be administrator resulting from the user <USERNAME_REDACTED> deploying packages using Nix, however similar activity has not previously been observed in your environment.

Please verify this activity was expected and approved.

Steps To Reproduce

Not sure how you'd test this without a system running CrowdStrike, so this is more of an FYI

Expected behavior

Ideally Nix/Lix shouldn't trigger security alerts.

nix --version output

nix (Lix, like Nix) 2.92.0-dev-pre20240813-b016eb0
## Describe the bug A recent [change to remove a dependency on `expect(1)`](https://git.lix.systems/lix-project/lix/commit/0c7619535112e19232384e15e82ffa6a5af7569d) added a Python script that seems to trigger CrowdStrike security checks when it runs. As a result I've had to revert to CppNix on my work MacOS machine. This is mostly an FYI since I'm not sure how you'd fix it (aside from reverting), or if you want to. Here's a redacted version of the report I received: > ## Escalation by Falcon Complete Team > An escalation has been raised that requires your action. > > ### Actions Required > Validate Activity > > ### Notes on Required Actions: > >At Aug. 13, 2024 22:02:53 UTC, Falcon triggered a detection on the host <HOST_NAME_REDACTED> for activity assoicated with a potential remote access software. > >The following instance of Python created what appears to be an interactive instance of BASH. > >Command Line: /nix/store/dgky6xnjyxriicbk3rbqycfp05niqk0v-python3-3.11.9/bin/python3 /private/tmp/nix-build-lix-2.92.0-dev-pre20240813-b016eb0.drv-0/source/build/misc/runinpty.py sh -c stty rows 0 cols 0 TERM=xterm-256color NOCOLOR=1 nix flake show > >The script runinpty.py was written to disk as the result of the execution of the following script: File Path: /nix/store/v6x3cs394jgqfbi0a42pam708flxaphh-default-builder.sh SHA256: 6ad51d3204d86970d472da2e39d6f7c73a578913ae689676e2770e162ed58743 > >This appears to be administrator resulting from the user <USERNAME_REDACTED> deploying packages using Nix, however similar activity has not previously been observed in your environment. > >Please verify this activity was expected and approved. ## Steps To Reproduce Not sure how you'd test this without a system running CrowdStrike, so this is more of an FYI ## Expected behavior Ideally Nix/Lix shouldn't trigger security alerts. ## `nix --version` output ``` nix (Lix, like Nix) 2.92.0-dev-pre20240813-b016eb0 ```
codingkoi added the
bug
label 2024-08-20 20:21:04 +00:00
Owner

Please get your corporate security team to hold CrowdStrike's feet to the fire on this one. The code in that script is copy pasted from the Python standard library and lightly modified, and does not perform any network access (although hm, I wonder if the Nix offline detection inside or something is what triggered their EDR by looking like network access).

It is impossible to test the code path in nix flake show without running an instance of Bash with a pseudoterminal attached, as it tests terminal size (you can see that from the stty command included in there), so we cannot remove it.

If you do feel like causing them an alert with just corporate-approved(tm) software literally included in macOS, try script -q /dev/null sh -c 'stty cols 0; nix flake show github:lix-project/lix'.

I don't know what to say, this is just your corporate security software breaking legitimate use cases. We would love to not need that python script, but if you read its sources, it exists because script(1) has inconsistent command line arguments across systems, and so it is most reasonable to write a custom wrapper.

If it is absolutely unacceptable that your system runs this code, consider writing a Nix overlay something like: final: prev: { lix = prev.lix.overrideAttrs { doInstallCheck = false; }; } and including it after the lix-overlay in your configuration. That would disable the testsuite that contains this code.

Please get your corporate security team to hold CrowdStrike's feet to the fire on this one. The code in that script is copy pasted from the Python standard library and lightly modified, and does not perform any network access (although hm, I wonder if the Nix offline detection inside or something is what triggered their EDR by looking like network access). It is impossible to test the code path in `nix flake show` without running an instance of Bash with a pseudoterminal attached, as it tests terminal size (you can see that from the stty command included in there), so we cannot remove it. If you do feel like causing them an alert with just corporate-approved(tm) software literally included in macOS, try `script -q /dev/null sh -c 'stty cols 0; nix flake show github:lix-project/lix'`. I don't know what to say, this is just your corporate security software breaking legitimate use cases. We would love to not need that python script, but if you read its sources, it exists because `script(1)` has inconsistent command line arguments across systems, and so it is most reasonable to write a custom wrapper. If it is absolutely unacceptable that your system runs this code, consider writing a Nix overlay something like: `final: prev: { lix = prev.lix.overrideAttrs { doInstallCheck = false; }; }` and including it after the lix-overlay in your configuration. That would disable the testsuite that contains this code.
jade closed this issue 2024-08-20 21:02:58 +00:00
jade added the
Status
invalid
label 2024-08-20 21:03:02 +00:00
Author

Thanks for the reply. Yeah it's not an ideal situation, and I didn't expect y'all to try to fix it. It's corporate BS that is causing the problem here.

Like I said, I opened this more as an FYI, and for anyone else who runs into this to find.

Thanks for the reply. Yeah it's not an ideal situation, and I didn't expect y'all to try to fix it. It's corporate BS that is causing the problem here. Like I said, I opened this more as an FYI, and for anyone else who runs into this to find.
Owner

I have given a workaround to stop Lix triggering it, but I would honestly recommend writing a strongly worded reply to your corporate security department that the alert is illegitimate and that you'll continue causing similar ones until they fix their EDR.

You can of course also use binary versions of Lix from nixpkgs, which will not have this problem.

I have given a workaround to stop Lix triggering it, but I would honestly recommend writing a strongly worded reply to your corporate security department that the alert is illegitimate and that you'll continue causing similar ones until they fix their EDR. You can of course also use binary versions of Lix from nixpkgs, which will not have this problem.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/lix#480
No description provided.