Hi @ManuelLerchnerQC, thanks for opening an issue.

Could you elaborate a bit on the security relevance of an audit here? In my experience unquoted shell variables don't generally result in security problems, although they are a code smell and do sometimes cause reliability problems.

Given that, I'm generally inclined to not support this kind of check in zizmor, and instead point people to actionlint for it (IIUC they wrap shellcheck to provide this check). However, if curious to hear arguments for it having more security salience and therefore being a good candidate for zizmor 🙂

Hi! Joining the discussion as @ManuelLerchnerQC pointed me to it.

The biggest risk with unquoted variables is that they allow an attacker to pass multiple arguments to a single command when only one is expected. This Stack Exchange answer provides an example:

awk -v foo=$external_input '$2 == foo'

If external_input is attacker-controlled, they can execute arbitrary commands:

$ external_input='x BEGIN{system("uname")}'
$ awk -v foo=$external_input '$2 == foo'
Linux

So, unlike template-injection issues, the command that is used with the unquoted$external_input must have some kind of dangerous argument that the attacker can exploit. I think this is quite often the case in practice and thus relevant for zizmor.

The answer above also references other issues that are less critical, IMO, but should still be considered.

Yeah, there's something secondary here: a lot of tools (like awk, xargs, and others) exhibit code execution via arguments. However, quoting itself doesn't fully mitigate this: "${foo[@]}" for example is correctly quoted, but can still result in code execution if it's being expanded into the arguments of a susceptible tool. That in turn generalizes to a ShellCheck-sized problem, i.e. something that actionlint and ShellCheck are better equipped to support than zizmor itself.

Have you all tried actionlint for this purpose? To my understanding a lot of zizmor users combine the two effectively, with zizmor providing security checks and actionlint providing general quality and correctness checks.

We will have a look into actionlint, thanks!

However, quoting itself doesn't fully mitigate this: "${foo[@]}" for example is correctly quoted, but can still result in code execution if it's being expanded into the arguments of a susceptible tool.

Of course. You could argue, though, that this is much less of an issue because you explicitly opted into passing everything as separate arguments with the [@] syntax. This is much less likely to be unintended compared to just forgetting quotes. Nevertheless, I see your point in drawing a line to actionlint here.