On 09/25/2014 05:37 PM, Greg Freemyer wrote:

On Thu, Sep 25, 2014 at 9:48 AM, Christopher Myers cmyers@mail.millikin.edu wrote:

...

I have a quick question for folks who run old versions of oS. I know that there are a lot of folks (myself included) who are running older versions of oS, because they don't really have a reason to upgrade - everything is working properly and has been configured over the course of many months to run smoothly and exactly the way we want/need it to.

My question is - how do other folks handle security vulnerabilities like this current bash vulnerability? Since oS isn't releasing patches for 11.4, 12.2, etc. anymore, how do you get around that? Just leave your machines vulnerable? Or compile your own patches?

Chris

For bash / shellshock, why do you think you're vulnerable?

AIUI, it's not an escalation vulnerability, it just allows apps to get out of a sandbox.

Perhaps into another, enclosing sandbox.

Thus if you have a webserver on your machine, it might let a webclient get out of the apache setup and into machine proper. They would still only have the privileges of Apache (or whatever user you run your webserver as.)

And if you run the Apache server chroot'd then even that is just in another sandbox. If you've taken care with the setup there is going to be a very limited set of executables and libraries available.

The main problem with chroot'ing is that it does little to nothing for the network side of things. If your chroot'd space has a PHP or Perl executable to support the CGI then the hacker could use those make a network move.

Of course the server could be running on a very stripped down virtual host with a virtual IP address and very aggressive fire-walling.

But the major problem is the database. Most web based applications are backed by a database. Perhaps it runs on another machine and access via network connection. After the hack it can still be accessed.

But please do run the server chroot'd or in a FM as a baseline measure. It may not be absolute security but it is another layer. There's no point in making things easy for the hackers.

Are you running any services on those old machines that serve the Internet?

If the only service is ssh, then the user has to log into ssh before trying anything. If you let those ssh users have an unlimited shell already, I don't think the vulnerability will give them any new way to penetrate your machine.

Indeed. SSH penetration is another, quite different, can of worms.

Am 26.09.2014 um 15:41 schrieb Christopher Myers:

All true, and good points :) I wasn't thinking so much specifically regarding this particular bash bug, but the broader issue of patches in general (heartbleed, et al.)

I'd considered going with 11.4 evergreen when I did the server build, but at the time couldn't get it to work on my box for whatever reason; it would make it about halfway through booting off of the media (dvd|network|flash all the same) and then the box would totally freeze regardless of what fixes I attempted from Google, what hardware was/wasn't installed, etc., so I had to do 12.2 (which worked fine.) I've done a ton of customization to the box and have it running very sweetly now, and don't have a compelling reason to upgrade it to the new evergreen.

It is mostly secured away from the nastier parts of the internet, so most patches aren't really necessary on it, but I was just curious what others were doing when they were in situations similar to mine.

Honestly? I would build the required patches in OBS for myself. I started that back in 11.1 and let other's get it as well and ooops, it was called Evergreen.

But actually. Not sure what the nastier parts of the Internet are. So it is a case by case decision. If you cannot fix it yourself and cannot make sure to avoid the possibility in the first place you are in trouble and really should update. At some point you'll have the pain anyway.

Wolfgang