Re: [SystemSafety] OpenSSL Bug

From: Steve Tockey < >
Date: Sun, 13 Apr 2014 23:54:32 +0000

Patrick Graydon wrote:
"The real questions, I think, are (a) why do we put up with such disclaimers on software that is part of a commercial offering?, and (b) what can be done to make vendors take responsibility for their software?"

(a) At least in the US, the answer is that software sellers can get away with putting it into the license agreement thus making software buyers assume that it is true. What might help would be an industry-wide campaign about the truth of the Uniform Commercial Code and how it takes precedence over any EULA.

(b) Again, in the US, UCC offers legal recourse on any product or service that was offered for sale. They already HAVE the responsibility, the issue is really only holding them actually accountable for it. Anyone up for a class action suit? :^)

"What kind of engineering did the people who developed this code and the people who put it into service do?!?"
Don't sully the word by implying that what those bozos did had anything at all to do with engineering. They hacked something together that appeared to work (at least given the brain-dead level of testing they subjected it to) so they shipped it. That's NOT engineering. Period.

-----Original Message-----
From: Patrick Graydon <patrick.graydon_at_xxxxxx Date: Friday, April 11, 2014 8:36 AM
To: Mike Rothon <mike.rothon_at_xxxxxx Cc: "systemsafety_at_xxxxxx <systemsafety_at_xxxxxx Subject: Re: [SystemSafety] OpenSSL Bug

On 11 Apr 2014, at 16:38, Mike Rothon <mike.rothon_at_xxxxxx

> 1) How did we arrive at a situation where a large proportion of
>seemingly mission / financially critical infrastructure relies on
>software whose licence clearly states " This software is provided by the
>openSSL project ``as is`` and any expressed or implied warranties,
>including, but not limited to, the implied warranties of merchantability
>and fitness for a particular purpose are disclaimed."?

I donıt know the history about which you ask. But it seems inevitable to me that gratis software would not be warranted fit for any purpose: how could a loose collection of unpaid volunteer developers possibly underwrite such a warranty?

I donıt have too much of a problem with gratis software being offered as-is. I doubt most people are capable of judging the fitness of software. (Even if they are experts, how much can one person check?) But I donıt see why such software shouldnıt be sold by a vendor who charges for the value-add of verifying, validating, and warranting it.

The real questions, I think, are (a) why do we put up with such disclaimers on software that is part of a commercial offering?, and (b) what can be done to make vendors take responsibility for their software? I realise that each of us as individuals has Hobsonıs choice with respect to (a), but if enough people demanded it, the situation might be different. Chrisıs paper explores some of the options for addressing (b).

> 2) Is it implicit that FOSS is less secure than proprietary software
>because exploits can be found by both analysis and experimentation rather
>than just experimentation? Or will this start a gold rush analysis of
>FOSS by security organisations resulting in security levels that are
>close to or better than proprietary software?

There are people who claim the opposite actually: the thinking is that more eyeballs make software more secure. Iıve heard rhetoric from both sides, but if there is solid empirical evidence either way, I am not aware of it.

Weıve discussed programming languages, but what this episode makes me wonder more about is basic engineering in the form of architecture, verification, and validation.

Iıve read a couple of articles about this that mentioned the idea that this particular code wasnıt considered critical because the heartbeat function has no particular security implications. (Sorry, the citations escape me at the moment.) That worries me because it displays a misunderstanding of partitioning and isolation, a topic that DO-178B addressed two decades ago.

I also wonder about how this code was tested before being put into service. Static analysis might have been a good idea, but shouldnıt basic robustness testing as per DO-178B §6.4.2.2ıs two-decade-old advice have caught this? I suppose that one could submit a heartbeat length greater than the actual request data sent, get back a response longer than what was sent, and not think that this is a problem. But that seems a bit doubtful to me.

What kind of engineering did the people who developed this code and the people who put it into service do?!?

> Just in case anyone missed the news, the original source code for MS-DOS
>and Word for Windows 1.1a is available online from the Computer History
>Museum (http://www.computerhistory.org).

Might be worth revisiting the bad old days days of LPARAMs, HANDLEs, LocalAlloc, GetProcAddress, GetProfileString, InvalidateRect, CreateWindow, MessageBox, and thousands-of-lines-long wndprc functions. :)

‹ Patrick



The System Safety Mailing List
systemsafety_at_xxxxxx

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Mon Apr 14 2014 - 01:54:44 CEST

This archive was generated by hypermail 2.3.0 : Fri Feb 22 2019 - 04:17:07 CET