6

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 '14 at 11:12
  • 1
    @paj28, it was still the default shell for Linux, no? – Ben Sep 30 '14 at 11:35
  • 1
    Linux is a kernel, and cares not what shell you use (or even if you use a shell). – Stephen Touset Sep 30 '14 at 21:41
  • 1
    @StephenTouset, alright snarky. It was the default shell for many linux distributions, yes? – Ben Oct 1 '14 at 8:23
  • 1
    As was found later, the FIE was added in 1.03 in August 1989, so before the web. – Stéphane Chazelas Oct 3 '14 at 21:44
5

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 '14 at 13:44
  • @Ben, I've added more detail to my answer. – Mark Sep 30 '14 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) – Stéphane Chazelas Oct 3 '14 at 16:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.