I take some of this back, I was thinking of a non-unix system that had problem. Most real unixes have a hard coded /bin/sh, and most do not arbitrarily execute code if in non-interactive mode (except for BASH_ENV).

On the other hand it's a very straight forward and not too large function to do exactly the same thing as system() for an absolute path name with fixed arguments.

Ya you're right for the most part. I was confused by the : const char *argp[] = {"sh", "-c", NULL, NULL};
Except that the first arg there is just the name being used, not the actual file to be executed, which was my mistake.

However I do recall some unixlike-but-not-unix systems that used other methods to find the shell because is wasn't always in a fixed location.

I don't think the early people did think it out, however even if they had some security expert thinking of all the ways it could go wrong I'm not sure it would stick out as a hole. After all nothing as far as they knew executed the contents of arbitrary environment variables especially not ones with names that they controlled. Even if they were really paranoid and decided not to use system(), or didn't use it for performance reasons, there were still perl scripts underneath that went and called system() behind the scenes...

I bet if you took a time machine to last week that many web security experts if asked if passing data in an environment variable is safe or not would think it was insecure, assuming the program that parsed the data took care.

You also need some form of data originating outside of the system that gets shoved into an environment variable. That's why CGI was the first obvious suspect for being exploited.

Most embedded systems aren't using bash though, not the small ones like routers anyway. If they're unix based they'll probably have ash or busybox. For ultrasound machines, which I've worked on, if they're linux they might have bash but I would think they'd use something else to save space. Even if bash they'd still need some other local program that uses system() or the like, plus an environment variable based on data from the outside world.

Is it just /bin/sh? A lot of systems use just "sh" and so will use PATH to find the correct shell to use, so you have to watch out for /usr/local/bin, /opt/local/bin, and other things that are often earlier in the PATH search.

This is not the whole thing. The bug is there even if you're passing known constant strings to system(), ie, there is no input to sanitize.
I do agree though that the fault is not only with bash, but from using system() as well. I've seen problems with it before, though stuff any good CGI design would avoid.

(For example, what happens if you make sure /bin/sh is a good patched bash, or it's dash instead, but then /usr/local/bin shows up first in PATH and contains an old crusty version of bash and sh, which one does system() use? So a good system needs to make sure PATH is set to a known and valid value.)

Although this vulnerability has been there for two decades...

However this does not mean that all other shells are perfectly safe or that there's not some other way to exploit them in the future. Basically using system("somestuff") is not the fastest or safest way to execute a command, though it is the most convenient way.

If a setuid program is dumb enough to use system() you can do a lot of nasty stuff if you're on the local machine. Setting SHELL to something other than the default, using BASH_ENV, stuff like that. In other words, people have known that system() is not necessarily safe for a long time.

I agree that it was unexpected that a static call to system() using a constant known string would have a vulnerability. However some people have also advised against using system() directly for a long time. Definitely I've seen bugs before that were traced back to someone having something unusual stuck in their .profile, or things work ok when the dev's shell was csh but then broke when run in production, etc.

Definitely for a very long time I have seen some people write simple functions to get a replacement for system() that's faster to start or more consistent in usage.

Nokia workers are a large chunk of those laid off, but still only a fraction of the workers laid off. They laid off a very large number of non-Nokia Microsoft employees as well.

And "products people wanted to buy" is irrelevant. If you're a good coder, then you can code regardless of the popularity of the product with the fan base. Anyone who hires employees based upon the successfulness of their previous companies is very short sighted. They don't even do that for hiring CEOs where having run a failed company and extracted all resources from it is not considered a black mark at all.

The reason Nokia made products that people didn't want to buy is because Microsoft's Elop took over and trashed it.

Note that if you use "bash -r -c" instead that you get a restricted shell (ie, more secure) and you don't get the vulnerability.
Although I don't think there's a portable way to get a restricted shell with all shells out there (dash doesn't seem to have that ability), so things that want to execute a subshell to execute commands are in a pickle, either use the default shell with no restricted option or know which type of shell is being used underneath the hood.

Nothing I hope uses csh or tcsh as the default shell for scripts. They may use it as a default user shell, but those are too broken for use as a scripting shell.

Not sure why there's all this bash bashing. It's a great shell, and now it has an exploit but it's being patched. Why did the bashing occur before this exploit was found, and will the apologies come out when these other shells turn out to have some exploits?

Is this because the shell scripts were using incompatible features, or that they mistakenly used "#!/bin/bash" instead of "#!/bin/sh"? If you link bash to /bin/sh then you get a reasonably compatible shell version. But I have seen people things like "#!/bin/dash" which is just as misguided.