4 ms·
Recently, I found a privilege escalation vulnerability in a shell script as a result of arithmetic expansion (similar to the one described at https://research.n
by ovex 3y ago
Recently, I found a privilege escalation vulnerability in a shell script as a result of arithmetic expansion (similar to the one described at https://research.nccgroup.com/2020/05/12/shell-arithmetic-expansion-and-evaluation-abuse/ https://research.nccgroup.com/2020/05/12/shell-arithmetic-ex...). For example, $((1 + ENV_VAR)) allows you to inject code if you can control $ENV_VAR.
Unfortunately, shellcheck did not catch that. At least not with the default settings. But if you are implementing anything remotely security-critical, you should not be using shell anyway.
- reidjs 3y agoWhat should we use for more security?
- l0b0 3y agoBasically anything where it's difficult to treat variable values as code. Python, Ruby, Java, and even PHP are much better at this.
- LelouBil 3y agoI have flashbacks of when my PHP teacher showed us how to turn query parameters into their own variables by using PHP's dynamic variables feature. He waited a bit, and promptly said to never do that and started to explain the security risks.
- stevekemp 3y agoPerl is probably worthy of a mention there, with it's taint-mode you're explicitly forced to test externally-influenced variables before using them.
- zimmund 3y agoI've seen `eval()` in production code of several applications. The biggest vulnerability is more often than not the programmer :)
- ovex 3y agoBut `eval()` does not violate a programmer's intuition as easily as an arithmetic expression resulting in code execution.