19

Since this bug affects so many platforms, we might learn something from the process by which this vulnerability was found: was it an εὕρηκα (eureka) moment or the result of a security check?

Since we know Stéphane found the Shellshock bug, and others may know the process as well, we would be interested in the story of how he came to find the bug.

  • 5
    Related: his answer to "When was the shellshock (CVE-2014-6271/7169) bug introduced, and what is the patch that fully fixes it?". – Cristian Ciupitu Oct 15 '14 at 15:56
  • This question appears to be off-topic because it is about a particular person's thought process and not any specific *nix issue. – terdon Oct 25 '14 at 13:08
  • @Anthon why does this have to be about Linux? Why approve an edit that brings in someone's opinion as though it were OP's? – muru Dec 12 '14 at 12:12
  • @muru I found this an improvement, luckily it takes more than one person to approve a suggested edit. But I have to admit I missed that the question was already closed, otherwise I might not have left it Linux, Unix, I don't care to much, otherwise we need BSD etc in the title of the site as well. – Anthon Dec 12 '14 at 12:21
  • 1
    Don't assume I read each and every question on this site. See thread.gmane.org/gmane.comp.security.oss.general/14177/… for a short answer. – Stéphane Chazelas Dec 12 '14 at 17:19
23

To reassure a few, I didn't find the bug by observing exploits, I have no reason to believe it's been exploited before being disclosed (though of course I can't rule it out). I did not find it by looking at bash's code either.

I can't say I remember exactly my train of thoughts at the time.

That more or less came from some reflection on some behaviours of some software I find dangerous (the behaviours, not the software). The kind of behaviour that makes you think: that doesn't sound like a good idea.

In this case, I was reflecting on the common configuration of ssh that allows passing environment variables unsanitised from the client provided their name starts with LC_. The idea is so that people can keep using their own language when sshing into other machines. A good idea until you start to consider how complex localisation handling is especially when UTF-8 is brought into the equation (and seeing how badly it's handled by many applications).

Back in July 2014, I had already reported a vulnerability in glibc localisation handling which combined with that sshd config, and two other dangerous behaviours of the bash shell allowed (authenticated) attackers to hack into git servers provided they were able to upload files there and bash was used as the login shell of the git unix user (CVE-2014-0475).

I was thinking it was probably a bad idea to use bash as the login shell of users offering services over ssh, given that it's quite a complex shell (when all you need is just parsing a very simple command line) and has inherited most of the misdesigns of ksh. Since I had already identified a few problems with bash being used in that context (to interpret ssh ForceCommands), I was wondering if there were potentially more there.

AcceptEnv LC_* allows any variable whose name starts with LC_ and I had the vague recollection that bash exported functions (a dangerous albeit at time useful feature) were using environment variables whose name was something like myfunction() and was wondering if there was not something interesting to look at there.

I was about to dismiss it on the ground that the worst thing one could do would be to redefine a command called LC_something which could not really be a problem as those are not existing command names, but then I started to wonder how bash imported those environment variables.

What if the variables were called LC_foo;echo test; f() for instance? So I decided to have a closer look.

A:

$ env -i bash -c 'zzz() { :;}; export -f zzz; env'
[...]
zzz=() {  :
}

revealed that my recollection was wrong in that the variables were not called myfunction() but myfunction (and it's the value that starts with ()).

And a quick test:

$ env 'true;echo test; f=() { :;}' bash -c :
test
bash: error importing function definition for `true;echo test; f'

confirmed my suspicion that the variable name was not sanitized, and the code was evaluated upon startup.

Worse, a lot worse, the value was not sanitized either:

$ env 'foo=() { :;}; echo test' bash -c :
test

That meant that any environment variable could be a vector.

That's when I realised the extent of the problem, confirmed that it was exploitable over HTTP as well (HTTP_xxx/QUERYSTRING... env vars), other ones like mail processing services, later DHCP (and probably a long list) and reported it (carefully).

  • 4
    Interesting reading! Although the comments on the questions make it clear that this might be a bit off-topic for this site, I think that a small amount of Q/A:s like this (with answers written as well and cleanly as this) really is an asset for the site! – Johan E Dec 20 '14 at 4:43

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.