In the wake of Shellshock, any service, process, daemon, app etc which passes strings to the shell (and if your default shell is bash) is a likely attack vector for Shellshock. Immediately after the bug was disclosed, thoughts began to drift towards DHCP, and specifically dhclient on linux systems.
Dhclient will pass a set of values to bash to write to system variables, as well as noting them down in resolv.conf, from parameters in the BOOTP unicast DHCP OFFER packet offered up by a DHCP server, following the discover and request packets:
We all knew that anyway, right? And that's an pretty obvious vector for a Shellshock attack:
Which works pretty well against dhclient 3.0.4 in Fedora 6 (and probably RHEL4, CentOS4 etc...):
Now, in dhclient 4.1, it looks like those variables, prior to being passed to bash and written to resolv.conf are validated by code in dhclient, and the attack fails (bash is still unpatched on the target system, and is still vulnerable):
Right. So what? Well... Clearly, someone has implemented this string validity check into dhclient to prevent malicious strings being passed to bash as system variables (or other nefarious reasons) (4.3 source):
This is the interesting bit, as it points towards an early missed opportunity to discover Shellshock.
Looking through the release notes, it seems that the change in question to bring in the validation was introduced to close CVE-2011-0997: https://kb.isc.org/article/AA-00455/0/CVE-2011-0997%3A-dhclient-Does-Not-Strip-or-Escape-Shell-Meta-characters.html
How close did we come then to discovering Shellshock? I don't know. The good news is that any dhclient patched up against CVE-2011-0997 is seemingly protected against Shellshock delivered via the DHCP route, but its frustrating that perhaps with a little more digging, we could have uncovered a fundamental flaw in bash a little earlier.
**Update**
The diff for adding a validation check in 3.0.5 to close CVE-2011-0997 can be found here,: http://sophie.aero.jussieu.fr/distrib/Scientific%20Linux/5x/x86_64/by-pkgid/0546855d7431d3fdfce69d4cced3d294/files/1
You can see most non-alphanumerics being nuked half way down.
Dhclient will pass a set of values to bash to write to system variables, as well as noting them down in resolv.conf, from parameters in the BOOTP unicast DHCP OFFER packet offered up by a DHCP server, following the discover and request packets:
We all knew that anyway, right? And that's an pretty obvious vector for a Shellshock attack:
Which works pretty well against dhclient 3.0.4 in Fedora 6 (and probably RHEL4, CentOS4 etc...):
Now, in dhclient 4.1, it looks like those variables, prior to being passed to bash and written to resolv.conf are validated by code in dhclient, and the attack fails (bash is still unpatched on the target system, and is still vulnerable):
Right. So what? Well... Clearly, someone has implemented this string validity check into dhclient to prevent malicious strings being passed to bash as system variables (or other nefarious reasons) (4.3 source):
This is the interesting bit, as it points towards an early missed opportunity to discover Shellshock.
Looking through the release notes, it seems that the change in question to bring in the validation was introduced to close CVE-2011-0997: https://kb.isc.org/article/AA-00455/0/CVE-2011-0997%3A-dhclient-Does-Not-Strip-or-Escape-Shell-Meta-characters.html
How close did we come then to discovering Shellshock? I don't know. The good news is that any dhclient patched up against CVE-2011-0997 is seemingly protected against Shellshock delivered via the DHCP route, but its frustrating that perhaps with a little more digging, we could have uncovered a fundamental flaw in bash a little earlier.
**Update**
The diff for adding a validation check in 3.0.5 to close CVE-2011-0997 can be found here,: http://sophie.aero.jussieu.fr/distrib/Scientific%20Linux/5x/x86_64/by-pkgid/0546855d7431d3fdfce69d4cced3d294/files/1
You can see most non-alphanumerics being nuked half way down.
Comments
Post a Comment