The shellshock bug, and the underlying feature allowing Function Import from the Environment (I'm calling it FIE), have been in bash since at least 1993, before the rise of CGI.

At that time, the rest of the Unix/Linux/GNU environment was very different.

So at that time in history:

  • Were setuid scripts allowed at that time?
  • Were setuid scripts part of default configuration at that time?
  • Were the system(3) and popen(3) calls used routinely by setuid binaries at that time?
    • common uses are for expanding shell globs (less appears to use it for this, but is not setuid) and executing external commands
  • was it common at that time to inherit the environment when su-ing?
  • Could the environment be propagated by things like rlogin etc? (I think telnet propagated DISPLAY by default).
  • Are there any features which would make the FIE bug more problematic back then?

So how bad was this privilege escalation and code execution bug, which has been hiding in plain sight for over twenty years, when it was originally introduced?

  • 1
    Probably not that bad for a very simple reason: at that time bash wasn't used much
    – paj28
    Sep 30, 2014 at 11:12
  • 1
    @paj28, it was still the default shell for Linux, no?
    – Ben
    Sep 30, 2014 at 11:35
  • 1
    Linux is a kernel, and cares not what shell you use (or even if you use a shell). Sep 30, 2014 at 21:41
  • 1
    @StephenTouset, alright snarky. It was the default shell for many linux distributions, yes?
    – Ben
    Oct 1, 2014 at 8:23
  • 1
    As was found later, the FIE was added in 1.03 in August 1989, so before the web. Oct 3, 2014 at 21:44

1 Answer 1


How bad? Not very.

None of the common remote attack vectors existed when the bug was introduced: the "shellshock" parsing bug pre-dates CGI and DHCP by about a year, and pre-dates SSH by two to three years. Remote-access programs such as telnet and rsh don't have the command restriction ability that SSH does, so although a "shellshock" attack could probably be mounted against them, it wouldn't gain an attacker anything they couldn't get just by logging in normally.

As for local privilege-escalation attacks, as far as I can tell, Linux has never supported setuid scripts. There aren't very many setuid programs: at the time, they would have been what are now the "util-linux" and "shadow" packages. These programs are part of the POSIX specification, and haven't changed in their fundamental operation in the past 20 years. Of them, only su, mount, and umount are setuid and call other programs, and all of them do it through exec*(). su did and still does pass the environment through if invoked without -, but it's not an easy attack vector to use: you need to get your target to execute it with an environment under your control, and invoking it as su - (which cleans the environment) is second nature to many sysadmins.

The big wildcard is other *nix-like systems. The GNU userland was a popular replacement for low-quality vendor programs, and some of the *nix-like OSs supported setuid scripts.

  • "There aren't very many setuid programs, and none of the ones in my system's /bin and /usr/bin directories looks like it would make a system() call." The question was about what they were like then, not what they are like now. Would they have called system(3) or popen(3) back then rather than execvpe? Were there more setuid programs to exploit?
    – Ben
    Sep 30, 2014 at 13:44
  • @Ben, I've added more detail to my answer.
    – Mark
    Sep 30, 2014 at 20:54
  • 1
    Some Unices still support setuid scripts. telnet, rlogin or rsh could and still can get you to a restricted command (and TERM is passed): the login shell of the target user. It's not unheard of to have public services exposed that way (even without authentication) Oct 3, 2014 at 16:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .