31–40 of 51 posts
So many footguns in bash. When do we finally get serious about ditching this language as an industry in the same way we are about memory safety?
Serious, please view the curled file from a link before piping it to bash/sh.
if you try to evaluate this kind of things as an arithmetic expression directly, it will fail with an error of a bad subscript (mind you, the attack will still work though).
So many footguns in bash. When do we finally get serious about ditching this language as an industry in the same way we are about memory safety?
We all want bash gone, but it is an essential piece of infrastructure. The introduction of dash was a huge step in this direction (of ditching bash).
Do you want to help? Try to remove bash from the toolchain bootstrap. It is one of the lowest hanging fruits right now.
Earlier quoted context omitted.
The first function one is not particularly well-written, but harmless. The quoting of ${num} is completely useless. Inside [[ bash does not do any word splitting after variable expansion. Double quotes never prevent variable expansion. I am not sure what the author is talking about. Shellcheck is correct to not complain. I stopped reading there.
> Double quotes never prevent variable expansion. I am not sure what the author is talking about. Shellcheck is correct to not complain. I stopped reading there. I think it would behoove you to read the rest of the post. The double quotes are not the operative part of example there; they're only there to demonstrate that the code execution doesn't come from splatting or word splitting. The actual code execution in Ca…
Showing -eq is not the best example, it can just be replaced by = and the problem goes away.
But if you need -gt or similar there is no replacement. So one should stick to [.
If I follow correctly the dangerous combination is [[ and arithmetic comparisons?
My first insinct would be to remove the bashisms first: https://gist.github.com/alganet/a4198158651f3b2dc43ce658052e... Then, if we run it: "line 3: test: a[$(cat /etc/passwd > /tmp/pwned)] + 42: integer expression expected"
(Author of the post.) Yep, this is specifically a bashism (by way of being a kshism). However, it's worth noting that the second variant (`type -v`) will work in `[` and `test`. (It's also a still a bashism, but IME people don't realize how little of `type` is actually POSIX.)
Yes, you can do dangerous things in bash scripts. This might be one of them. Not at my computer now and no time to experiment.
So many footguns in bash. When do we finally get serious about ditching this language as an industry in the same way we are about memory safety?
Question: why does the evaluation inside a[] (which does not produce a value) not result in a bad array subscript error in this case? if you try to evaluate this kind of things as an arithmetic expression directly, it will fail with an error of a bad subscript (mind you, the attack will still work though).
Earlier quoted context omitted.
> Double quotes never prevent variable expansion. I am not sure what the author is talking about. Shellcheck is correct to not complain. I stopped reading there. I think it would behoove you to read the rest of the post. The double quotes are not the operative part of example there; they're only there to demonstrate that the code execution doesn't come from splatting or word splitting. The actual code execution in Ca…
So -eq triggers evaluation? Sounds like typical bash magic. I would use [ an the problem goes away. Showing -eq is not the best example, it can just be replaced by = and the problem goes away. But if you need -gt or similar there is no replacement. So one should stick to [. If I follow correctly the dangerous combination is [[ and arithmetic comparisons?
The dangerous thing here is that an undefined number of contexts exist where Bash treats strings as arithmetic expressions, which can contain arbitrary code despite not being quoted for expansion. `-eq` is just one example of that; others have linked other examples.
(This is all for case #1. With case #2, `[` and `test` are also susceptible so long as their builtin variants are used.)
So many footguns in bash. When do we finally get serious about ditching this language as an industry in the same way we are about memory safety?
Curious what you use instead of bash? When you spin up a server somewhere, what's the first thing you like to install that replaces what we typically use bash for?
xonsh is neat in principle, but painful in actual usage ime. And I suspect vulnerable to similar issues around the Python-bash interop.
Honestly I just don't write shell scripts anymore, bash or otherwise. By the time any system I use is up, Python is available. I don't know if I've found a true need for shell in anything application level. I'll even fire up a Python shell for something simple like mass renaming files, simply because the string manipulation is so much easier.
As a less joke but also more joke: https://www.gnu.org/software/emacs/manual/html_mono/eshell.h...
1: it was going to be much funnier if I could have found the link where someone used emacs as Xsession or similar but this one will do