Shellshock Update 01-Oct-2014

(Follow-up to Shellshock1) With a pro-active response to the issue, Rocket Software has confirmed that their D3 and U2 products have been checked against vulnerabilities known to-date. But we need to take this a bit further.

First, thanks to Rocket for their investigation. I’m hoping to see more such confirmations from other MV DBMS providers.

Of course these companies should maintain a vigil in case new attack vectors are discovered. Statement updates may need to be issued. I’d recommend that this not be regarded as an event: we know the issue, we’re good, issue closed. I think the better approach would be to look at this like a short-term but ongoing situation : As of ‘this date’, we’ve checked the latest reports on the issue and we’ve re-affirmed our state of security. In other words, this is a war, it’s not a skirmish. Or think of it like those web pages that server hosts use to inform their clients about server status. They don’t issue a yearly status update. They monitor their systems, their status pages change every couple minutes, and icons go from green to red if there is a service interruption. I’m not suggesting daily updates but I do think the response to this should be more of a vigil than a ‘statement’.

And no doubt, the statement from Rocket was comforting, but in my opinion incomplete. Their statement is that their products are fine. And sure, per the above, that’s not likely to change. but what about all of the end-users who have deployed their products? Of course we can’t expect a software provider to accept responsibility for the security of those who purchase their products. I’m saying these products provide a vector into end-user environments, and I’m looking for a statement that will inform end-users about just how much they need to do on their side to protect themselves. That’s all. I’m not asking for a fix which isn’t possible. I’m also not asking these companies to make an announcement that their products are particularly vulnerable. I’m hoping people will put their sense of Marketing aside. Stop thinking that if you warn your clients about potential abuse of your products that you’re somehow accepting responsibility for the consequences. Focus more on a holistic approach for all of us to get through this problem. If you sell a product that can be abused by someone else, it’s not your fault, and you don’t need to accept responsibility. But if you don’t advise your customers that they have a potential problem if a component is abused in their environment, I believe you could be as at fault as anyone who abuses the technology. That goes for all of the MV DBMS providers and anyone who provides such a product.

If nothing else, look at this like an opportunity to do some positive Marketing: “Hey, we’re the folks who sold you that great software. We hope it’s been serving you well for all of these years. We wanted you to know that there’s a worldwide issue right now that affects companies like yours who are using similar technology. Just remember you heard about this from us, the company that provides great software where you might want to buy more in the future…” I strongly advise against anyone publishing that verbatim, but you get the idea…

So…

End-users – even if your upline providers certify that their products are secure, you still need to secure your environment! Look to your vendors to provide information about where your vulnerabilities might be and about what you need to do – aside from common securing of your systems using information found in the public domain.

VARs – I strongly encourage you to provide Value-Add to your end-users by offering advice and perhaps services to minimize server exposure. If you don’t know how, recommend someone to your clients, or at least tell them there is a potential problem and recommend that they find someone. But don’t sit back and do nothing.

While the internet is now buzzing with lots of information on this topic, the following is worth reading:
– Cloudflare: Inside Shellshock
– ZDNet.com Shellshock FAQ Includes patch info.

In the above links and many others you can see how easy it is for anyone to violate a system. This vulnerability requires no skill whatsoever, just a simple copy and paste into a command-line, and a change to the targeted URL. I mean a 12 year old can do it.

Just because you don’t see damage on your system now doesn’t mean your system is immune. Right now hackers are just using this to scope for target systems. Once they know you’re vulnerable, you get added to a list which may be sold later. Someone will then come back to that list later, recheck, and then start doing whatever they want.

Do Not think “I’ve loaded ‘the patch’, so we’re OK”. The first patches issued were incomplete. More patching is required as the issue gets more attention from both the good guys and the bad guys.

Do Not think “this is just another scare that will blow over in a few weeks”. If you do nothing to an internet-facing Unix server, that system is vulnerable.

Will automatic patches work? Only if you’re getting them. Some patches can’t be applied to older systems. You might need to completely re-install your system to a new version just to get properly patched. This is one of the reasons I’ve taken interest in this issue – a lot of Pick / MultiValue sites just install their software and then never patch it. Some companies think their exposure is limited because MV is so obscure. That’s not going to save you from this one.

To anyone who is reading this and does nothing – you have been warned.