By now, I hope you are well on your way to patch your Linux systems for the bash code injection vulnerabilities. At this point, you should probably dig a bit deeper and try to find more "hidden" places that may be vulnerable. First of all, a quick list of things that are not vulnerable:
Now which are the systems you may have missed in your first quick survey? First of all, vulnerability scanners will only find the low hanging fruit for this one, in particular earlier on. There are many larger web applications that have a couple of small cgi-bin scripts that are easily missed.
And some good news: The signature "() {" for the exploit is actually better then I thought originally. Turns out that added spaces or other modifications to this string will break the exploit. So in short, your priority list should look like:
Moving forward: The idea of writing web applications in bash (or other shell scripting langagues) is pretty dangerous in the first place. It should be done with care, and if possible, try to use a different languages (perl, php, python) as they provide better input validation libraries. SELinux was mentioned as a counter measure, but in this case, it may not work quite as well as hoped. Regardless, learn how to use it and don't just turn it off the first time it gets in the way. Systems like web application firewall and IPSs are very useful in a case like this for virtual patching. Make sure you have these systems in place, even if for the most part, you use them just to alert and log and less to block. Fellow handler Rob put together this list of "likely to be missed" machines:
--- |
Johannes 4479 Posts ISC Handler Sep 29th 2014 |
Thread locked Subscribe |
Sep 29th 2014 7 years ago |
Windows machines running cygwin I believe are vulnerable as well.
|
James 35 Posts |
Quote |
Sep 29th 2014 7 years ago |
Courier email server (default install):
/etc/courier/courierd:SHELL=/bin/bash /etc/courier/esmtpd:SHELL=/bin/bash Unclear whether any user-supplied data is injected into the env before running a courier script. CUPS: /usr/lib/cups/filter/textonly:#!/bin/bash CUPS sets a bunch of env variables prior to running the filter, but it's unclear whether any are injected from the print request. The MIME type and device URI probably originate from the job, but you can only get the textonly filter to run if it's set up to process a particular MIME type, typically text. Don't know what filtering might be done with the device URI. Of course, it's possible other filters or things that other filters run (has anyone looked at ghostscript?) to trigger a call to bash. |
Pat Wood 3 Posts |
Quote |
Sep 29th 2014 7 years ago |
Sign Up for Free or Log In to start participating in the conversation!