Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pwning the Nix ecosystem

ptrpa.ws

Post reply on HN
Print view View original

21–30 of 69 posts

Re: Pwning the Nix ecosystem

#21

Post by stonogo »

hombre_fatal wrote: post #14
ishouldbework wrote: post #10

> It is not possible for xargs to be used securely Eh... That is taken out of context quite a bit, that sentence does continue. Just do `cat "$HOME/changed_files" | xargs -r editorconfig-checker --` and this specific problem is fixed.

Though that's like adding ` {escapeHtml(value)} ` everywhere you ever display a value in html to avoid xss. If you have to opt in to safe usage at every turn, then it's an unsafe way of doing things.

I don't disagree but "it's not possible for xxx to be used securely" is a long way from "it's cumbersome and tedious to use xxx securely"

Re: Pwning the Nix ecosystem

#22

Post by ishouldbework »

woodruffw wrote: post #11
ishouldbework wrote: post #10

> It is not possible for xargs to be used securely Eh... That is taken out of context quite a bit, that sentence does continue. Just do `cat "$HOME/changed_files" | xargs -r editorconfig-checker --` and this specific problem is fixed.

Yeah, I don't think the specific reason for that sentence in the manpage applies here. But the general sentiment is correct: not all programs support `--` as a delimiter between arguments and inputs, so many xargs invocations are one argument injection away from arbitrary code execution. (This is traditionally a non-issue, since the whole point is to execute code. So this isn't xargs' fault so much as it's the undyin…

Well, anything POSIX or GNU does support the --. I think most golang libraries as well? And if the program does not, you can always pass the files as relative paths (./--help) to work around that.

For sure though, this can get tricky, but I am not really aware of an alternative. :/ Since the calling convention is just an array of strings, there is no generic way to handle this without knowing what program you are calling and how it handles command line. This is not specific to xargs...

Well, I guess FFI would be a way, but it seems like a major PITA to have to figure out how to call a golang function from bash shell just to "call" a program.

Re: Pwning the Nix ecosystem

#23

Post by lijok »

woodruffw wrote: post #3

This is a great example of why `pull_request_target` is fundamentally insecure, and why GitHub should (IMO) probably just remove it outright: conventional wisdom dictates that `pull_request_target` is "safe" as long as branch-controlled code is never executed in the context of the job, but these kinds of argument injections/local file inclusion vectors demonstrate that the vulnerability surface is significantly large…

Inside private repos we use pull_request_target because 1. it runs the workflow as it exists on main and therefore provides a surface where untampered with test suites can run, and 2. provides a deterministic job_workflow_ref in the sub claim in the jwt that can be used for highly fine grained access control in OIDC enabled systems from the workflow

Re: Pwning the Nix ecosystem

#24

Post by woodruffw »

lijok wrote: post #23
woodruffw wrote: post #3

This is a great example of why `pull_request_target` is fundamentally insecure, and why GitHub should (IMO) probably just remove it outright: conventional wisdom dictates that `pull_request_target` is "safe" as long as branch-controlled code is never executed in the context of the job, but these kinds of argument injections/local file inclusion vectors demonstrate that the vulnerability surface is significantly large…

Inside private repos we use pull_request_target because 1. it runs the workflow as it exists on main and therefore provides a surface where untampered with test suites can run, and 2. provides a deterministic job_workflow_ref in the sub claim in the jwt that can be used for highly fine grained access control in OIDC enabled systems from the workflow

Private repos aren't as much of a concern, for obvious reasons.

However, it's worth noting that you don't (necessarily) need `pull_request_target` for the OIDC credential in a private repo: all first-party PRs will get it with the `pull_request` event. You can configure the subject for that credential with whatever components you want to make it deterministic.

Re: Pwning the Nix ecosystem

#25

Post by woodruffw »

ishouldbework wrote: post #22
woodruffw wrote: post #11

Earlier quoted context omitted.

Yeah, I don't think the specific reason for that sentence in the manpage applies here. But the general sentiment is correct: not all programs support `--` as a delimiter between arguments and inputs, so many xargs invocations are one argument injection away from arbitrary code execution. (This is traditionally a non-issue, since the whole point is to execute code. So this isn't xargs' fault so much as it's the undyin…

Well, anything POSIX or GNU does support the --. I think most golang libraries as well? And if the program does not, you can always pass the files as relative paths (./--help) to work around that. For sure though, this can get tricky, but I am not really aware of an alternative. :/ Since the calling convention is just an array of strings, there is no generic way to handle this without knowing what program you are cal…

> This is not specific to xargs...

Right, it's just that xargs surfaces it easily. I suspect most people don't realize that they're fanning arbitrary arguments into programs when they use xargs to fan input files.

Re: Pwning the Nix ecosystem

#26

Post by immibis »

> If you’ve read the man page for xargs, you’ll see this warning:

>> It is not possible for xargs to be used securely

However, the security issue this warning relates to is not the one that's applicable here. The one here is possible to avoid by using -- at the end of the command.

Re: Pwning the Nix ecosystem

#27

Post by Thom2000 »

amluto wrote: post #13

I find it rather embarrassing that, after all these years of trying to design computer systems, modern workflows are still designed so that bearer tokens, even short-lived, are issued to trusted programs. If the GitHub action framework gave a privileged Unix socket or ssh-agent access instead, then this type of vulnerability would be quite a lot harder to exploit.

Exactly!

Bearer tokens should be replaced with schemes based on signing and the private keys should never be directly exposed (if they are there's no difference between them and a bearer token). Signing agents do just that. Github's API is based on HTTP but mutual TLS authentication with a signing agent should be sufficient.

Re: Pwning the Nix ecosystem

#28

Post by lijok »

woodruffw wrote: post #24
lijok wrote: post #23

Earlier quoted context omitted.

Inside private repos we use pull_request_target because 1. it runs the workflow as it exists on main and therefore provides a surface where untampered with test suites can run, and 2. provides a deterministic job_workflow_ref in the sub claim in the jwt that can be used for highly fine grained access control in OIDC enabled systems from the workflow

Private repos aren't as much of a concern, for obvious reasons. However, it's worth noting that you don't (necessarily) need `pull_request_target` for the OIDC credential in a private repo: all first-party PRs will get it with the `pull_request` event. You can configure the subject for that credential with whatever components you want to make it deterministic.

You’re right! I edited my comment to clarify I was talking about good ole job_workflow_ref.

Re: Pwning the Nix ecosystem

#29

Post by otabdeveloper4 »

amluto wrote: post #13

I find it rather embarrassing that, after all these years of trying to design computer systems, modern workflows are still designed so that bearer tokens, even short-lived, are issued to trusted programs. If the GitHub action framework gave a privileged Unix socket or ssh-agent access instead, then this type of vulnerability would be quite a lot harder to exploit.

The SPIFFE standard does something like this.

It's not used by anyone because nobody actually gives a shit about security, the entire industry is basically a grift.

Re: Pwning the Nix ecosystem

#30

Post by aftergibson »

As time goes on, I find myself increasingly worried about supply chain attacks—not from a “this could cost me my job” or “NixOS, CI/CD, Node, etc. are introducing new attack vectors” perspective, but from a more philosophical one.

The more I rely on, the more problems I’ll inevitably have to deal with.

I’m not thinking about anything particularly complex—just using things like VSCode, Emacs, Nix, Vim, Firefox, JavaScript, Node, and their endless plugins and dependencies already feels like a tangled mess.

Embarrassingly, this has been pushing me toward using paper and the simplest, dumbest tech possible—no extensions, no plugins—just to feel some sense of control or security. I know it’s not entirely rational, but I can’t shake this growing disillusionment with modern technology. There’s only so much complexity I can tolerate anymore.

Post reply on HN