Wednesday, July 9, 2014

Security FUBARs with Long Histories

Back in the hazy mists of time, “Smart Documents” were all the rage in the IT trade press. You could embed a button (or whatever) in a document, and It Would Do Stuff. At that point, data became mingled with executable code on a widespread basis, and the world changed. The consequences included everything from exploits against Adobe products (including an attack based on a capability to interact with wire-frame graphics, which I understand was quite popular with architects) to the huge flight of problems with Microsoft's Visual Basic for Applications (VBA) vulnerabilities.

Neither of these has ever really gone away. Vulnerabilities in Adobe products continue to be amongst the most widely exploits in the history of computing. Shipping Shockwave players with very old, but still unpatched vulnerabilities (May, 2014), a data breach affecting 38 million users (October, 2013), etc. supply all the evidence needed to support either of two conclusions: that they simply do not care, or that they are wonderfully incompetent.

The security train-wreck that Adobe has always been is truly fascinating, and I can't help but think that there is a Masters thesis or two in there.

Microsoft, on the other hand, has cleaned up their act enormously. They more or less had to; it was once highly unlikely that you could deploy a fully patched Microsoft server before it was compromised. This was one cause of the rise of Linux, and made everyone from the IT department, to C-suite executives, to shareholders greatly unhappy; their largest customers were howling. There is probably a thesis or two in there as well, and I suspect that any such thesis would point up the historic importance of howling.

But leaving the proprietary, closed-source world, it is important to recognize another widespread problem: open source (or other Unix-y OS) fanbois-isms. Inherently secure, yada yada yada whatever. We have all heard it. For the record, I do consider Linux (and the BSD Unix variants) to be stronger operating systems, though for reasons that would probably surprise many people that don't know me rather well.

CVE-2014-0247 is something that some might consider unimportant, compared to, say the train-wreck that is OpenSSL. It is not.

Vulnerability Summary for CVE-2014-0247
Original release date: 07/03/2014
Last revised: 07/07/2014

LibreOffice 4.2.4 executes unspecified VBA macros automatically, which has unspecified impact and attack vectors, possibly related to doc/docmacromode.cxx.
CVSS Severity (version 2.0):
CVSS v2 Base Score: 10.0 (HIGH) (AV:N/AC:L/Au:N/C:C/I:C/A:C)
Impact Subscore: 10.0
Exploitability Subscore: 10.0
CVSS Version 2 Metrics:
Access Vector: Network exploitable
Access Complexity: Low
Authentication: Not required to exploit
Impact Type: Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service

So, it's quite serious, in and of itself.

CVE-2014-0247 exists because the issues with VBA macros have been directly transferred into an Open Source environment, including the old security flaw of automatically executing VBA macros. It happened because that age-old Intelligent Document press was not hype. It represented a competitive advantage for adopters over non-adopters, and business advantage wins. In a business context, I am not aware of any evidence of a business advantage ever being refused due to security concerns. One could certainly argue that this is simply because had the advantage been refused, the product or technique would never have become widespread. However, my personal experience, and that of others that I trust, while admittedly anecdotal, is that it happens rarely, at best.

Furthermore, weighting return on investment above all else (and basing that calculation on flawed data) seems to apply to even the vaunted NSA, despite their largely hidden, but undoubtedly enormous, budget. The Snowden leaks would not have been possible if NSA had deployed technologies that they directly funded. Consider the case of root powers being controllable by SELinux, whereas much of the leakage was seemingly made possible by attacks against flawed Microsoft SharePoint configurations.

It seems clear to me that the majority of people working in anything that touches security would be well advised to be thinking about metrics, and assigning better numbers during risk analysis than is commonly done today. Assuming risk analysis is done at all; it is clearly not a sufficiently widespread practice. Without that, ROI calculations will remain hopelessly in error.

Furthermore, it seems likely that the best prospects for improvement in the current abysmal state of affairs would occur if this were done by the consumers of IT. Only then can sufficient howling at the suppliers (whether open- or closed-source), backed by real data, occur.

No comments:

Post a Comment

Thanks for your comment; communities are not built without you.

But note than comments on older posts usually go into a modertion queue. It keeps out a lot of blog spam. Weird links to Web sites hosting malware, marketing nonsense, etc.

I really want to be quick about approving comments in the moderation queue. When I think I won't manage that, I will turn moderation off, and sweep up the mess as soon as possible.

If you find comments that look like blog spam, they likely are. As always, be careful of what you click on. I may have had moderation off, and not yet swept up the mess.