Download, comment and like it here: https://github.com/jackbezalel/patchme
I think you should like this new Shell-Shock Auto-Patcher I created (“PatchMe“). It should serve you well for future and past similar “noisy” vulnerabilities, specially if you have a lab or site with many types of “loosely” managed operating systems. This tends to happen within development labs, where you have license for every machine, but do not necessarily set or maintain them through a central patch repository.
It is also good for cases where patching is not straight-forward as it is in Ubuntu, Debian or similar free open source operating system.
I believe you will find PatchMe is simple to deploy and use. You don’t have to go through a complex massive patching, testing and mass-deploying, just to get rid of one hot vulnerability.
It is a right-to-the-point vulnerability patcher, for what is in the news, and allows you to automatically dry-test the patch, if successful run the patch live, get a central repository dynamically created during the patch process, so you have full audit of what is going on.
Here it is for use “as is” (don’t complain if it breaks anything). It may have bugs, but was tested and seems to work just fine on dozens of machines. It currently patches Red Hat 5, 6, 7 and should work well for release 4 as well. I am adding support for Solaris, including Solaris Zones scenarios and will be taking care of CentOS, HP-UX and AIX as well other Linux distributions.
Download, comment and like it here: https://github.com/jackbezalel/patchme
PatchMe uses the “patchme.sh” script which works has an NFS based repository.
All one need to do is mount the PatchMe NFS tree (directory structure in the PatchMe readme file) and run the patchme.sh script from the bin directory, followed by a vulnerability name. You could basically schedule it to run at once for all your machines or just a few of them.
You have to get the patches for the vulnerability on your own, provided your license allows it, and PatchMe will take care of installing the right patch on each machine and operating system.
Why not use your Unix or Linux distribution software update mechanism? Well, because each vendor has a different mechanism and requirements, while PatchMe is meant to reduce the time and effort, and focus on just one vulnerability each time. It allows you, the system administrator save time and effort, and keep management off your back.
Once activated, PatchMe will create a specific directory in the central repository for review and analysis, with those files for each machine and vulnerability as well as patch cycle run for it:
– Software installed on the system, pre-patching
– State of patching dry-run (will only test if patch can be deployed fine, but will not install it)
– Dry Run log
– Software packages installed on the system post patching (in case you want to consider roll back of the patch)
– State of update live-run (patched or not)
– Live patching log
Download, comment and like it here: https://github.com/jackbezalel/patchme
I am not going to work on roll-back of patches – it seems too sensitive and problematic, while we are aiming here at a simple short process.
Future planned updates:
I will work on trying to avoid using NFS.
Instead you would use a single “Patcher” machine where the NFS repository exists, (I used Red Hat 7.0) and from there use a “dropper” script that will try to login to the target machine we want to patch, via ssh, using root passwords you provide the “Dropper” with. The “Patcher” will copy a zip file with the relevant script, run it and then get the results back to the patcher repository.
The next step (maybe for Thu) could be to run a scan from the patcher machine, producing a list of Linux/Unix machines (nmap, etc) and feed this to the Dropper and PatchMe to logon to those machines and patch them.
Feel free to comment and/or advise…