[SystemSafety] OpenSSL Bug

[Steve Tockey]

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.


-- steve



-----Original Message-----
From: Patrick Graydon <patrick.graydon at gmail.com>
Date: Friday, April 11, 2014 8:36 AM
To: Mike Rothon <mike.rothon at certisa.com>
Cc: "systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] OpenSSL Bug


On 11 Apr 2014, at 16:38, Mike Rothon <mike.rothon at certisa.com> wrote:

> 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 TechFak.Uni-Bielefeld.DE