DJofSD
06-06-2014, 11:14 AM
I have long had a gut level feeling there are problems in and with the cloud. Any one that has worked in any part of IT knows things are never perfect. That includes security.
So after reading the articles I'll cite in the next paragraph, I believe my gut level instinct has been validated.
Starts here: http://threatpost.com/vulnerabilities-in-ipmi-protocol-have-long-shelf-life/106480 and has a link: http://fish2.com/ipmi/river.pdf .
So, what does it mean?
It means that a vital link in the security chain is hugely deficient.
One of the fundamental assumptions about cloud computing is both the network and the diverse platforms are secured.
Well, we know the network is not secured. And, to add insult to injury, yet another and different OpenSSL bug was found. Here's an article written by the person that discovered it: http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html . And, here is an interesting quotation from it:
When Heartbleed arose, everyone talked about how to prevent similar bugs. Unit tests, code analyzers, fork and rewrite cleanly, improve API, not to reinvent malloc, use other language than C, etc. etc. [bold font for emphasis is mine]
One of the favored candidate for such a language was ATS. I thought how it would be to write TLS/SSL in Coq, which I am more familiar with. Proving the protocol safety is a huge job, while it would not contribute to implementation safety. I try to create something that can show the correctness of the implementation at a glance.
And, another security hole, the IPMI hole, means access to and control of the remote servers is open and vulnerable -- on multiple levels.
At least large enterprises like AT&T and IBM have mitigated a key source of the problem: they have their own private networks and do not necessarily use the public internet. This is not to say they are completely isolated. They are not, or, in other words, there are parts of the private networks which have openings or bridges to the open internet. That's how people can work remotely and support the systems which are running on the internal or private network.
The big problem is going to be finding and fixing the problems. It's a different animal than say the OpenSSL/heart beat problem. It will not be quick and it will not be cheap.
So after reading the articles I'll cite in the next paragraph, I believe my gut level instinct has been validated.
Starts here: http://threatpost.com/vulnerabilities-in-ipmi-protocol-have-long-shelf-life/106480 and has a link: http://fish2.com/ipmi/river.pdf .
So, what does it mean?
It means that a vital link in the security chain is hugely deficient.
One of the fundamental assumptions about cloud computing is both the network and the diverse platforms are secured.
Well, we know the network is not secured. And, to add insult to injury, yet another and different OpenSSL bug was found. Here's an article written by the person that discovered it: http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html . And, here is an interesting quotation from it:
When Heartbleed arose, everyone talked about how to prevent similar bugs. Unit tests, code analyzers, fork and rewrite cleanly, improve API, not to reinvent malloc, use other language than C, etc. etc. [bold font for emphasis is mine]
One of the favored candidate for such a language was ATS. I thought how it would be to write TLS/SSL in Coq, which I am more familiar with. Proving the protocol safety is a huge job, while it would not contribute to implementation safety. I try to create something that can show the correctness of the implementation at a glance.
And, another security hole, the IPMI hole, means access to and control of the remote servers is open and vulnerable -- on multiple levels.
At least large enterprises like AT&T and IBM have mitigated a key source of the problem: they have their own private networks and do not necessarily use the public internet. This is not to say they are completely isolated. They are not, or, in other words, there are parts of the private networks which have openings or bridges to the open internet. That's how people can work remotely and support the systems which are running on the internal or private network.
The big problem is going to be finding and fixing the problems. It's a different animal than say the OpenSSL/heart beat problem. It will not be quick and it will not be cheap.