Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 10 Oct 2014 10:02:13 +0200
From: ┼╣micier Januszkiewicz <gauri@....by>
To: oss-security@...ts.openwall.com
Subject: Re: liability (was: Re: Thoughts on Shellshock and beyond)

Just my 2 cents here as for marketing software known to be vulnerable.
This is not exactly open source, but something spotted today in [1]:

"Revision 1.25
2014-October-09
Listed the newly released Cisco Unified Communications Domain Manager
version 10.1(1) as vulnerable."

Makes you think... either this is horrible wording or...

[1] http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed

2014-10-09 22:12 GMT+02:00 Solar Designer <solar@...nwall.com>:
> I ended up writing a lengthy message (this one), but I am unsure if it's
> a good idea to have this topic discussed once again (such discussions
> had already occurred on other mailing lists years ago).  In fact, that's
> the main point I am making - while I've just spent/wasted some time on
> writing the below, maybe we should stop right here?  So if anyone has
> something new or some important historical references to add, please feel
> free to post, but I'd rather not see us digress into (I think) mostly
> irrelevant analogies in financial markets, with even more irrelevant
> detail on the French trader (referring to Sven's other posting here).
>
> I mention some paywalled articles below.  If anyone has URLs to free
> copies of those, please post.
>
> On Thu, Oct 09, 2014 at 11:11:34AM +0200, Sven Kieske wrote:
>> so at least when you're making money of software you should
>> be responsible for this software.
>
> That's tricky.  Is an Open Source project that accepts donations, sells
> CDs/DVDs, or/and runs ads on the website "making money"?  What if they
> also offer related paid services or even occasionally sell commercial
> licenses to the same software?  Would they be liable e.g. for up to all
> payments they ever received (or more?), even if 99.9% of the users never
> paid anything?  That may easily put them "out of business", or
> discourage them from starting the project in the first place.
>
> Of course, you can hope to reduce undesired effects of a new law by
> careful wording, listing categories of software it does or/and does not
> apply to, etc.  However, getting the legal system involved at all is a
> huge risk... yet you'd like to use it to reduce risk elsewhere?  The
> legal system is already akin to an over-engineered software program, and
> you're proposing to make it even more complex (more buggy, and requiring
> more resources to run).  What's worse, you don't get to write that
> "program", and you can't replace it on your "computer" with some
> alternative (short of moving to another jurisdiction, and even that
> option might disappear if the law becomes universally accepted).  You
> can request a "feature", and if the powers that be listen, they'll
> implement that "feature" in some arbitrary way that you might not like,
> yet all of us would be stuck with it.  In my opinion, this is extreme
> danger, possibly way beyond the risk from software vulnerabilities (to
> the extent that risk could be reduced by such measures).  Indeed, these
> are different types of risks, so a direct comparison of this sort may
> only make sense in specific contexts (e.g., effect on a country's
> economy or on people's quality of life analyzed in some specific way).
>
> I am not saying I am strictly against this approach, although that is my
> current stance given the (frankly) rather limited impact that software
> vulnerabilities actually have on us so far despite of being widespread.
> (I think the negative impact of introducing liability for software
> vulnerabilities might well be broader.)  What I am saying is that it's a
> really tough tradeoff, and that in my opinion anyone who feels confident
> about it is either wrong in being so confident or has values different
> from mine.
>
>> that's also not just my opinion (and I didn't invent these
>> thoughts), some credit has to go out to mr Schneier who
>> you might happen to know ;)
>>
>> see:
>>
>> https://www.schneier.com/essays/archives/2003/11/liability_changes_ev.html
>
> Oh, this is definitely an old topic, much older than 2003, although that
> was a year when it was discussed more.
>
> There were two related articles published in IEEE Security & Privacy,
> 2003 vol.1, Issue 1 - January-February:
>
> http://www.computer.org/csdl/mags/sp/2003/01/index.html
>
> Two Views on Security Software Liability: Let the Legal System Decide
> Daniel J. Ryan , Law Offices of Daniel J. Ryan
> pp. 70-72
>
> Two Views on Security Software Liability: Using the Right Legal Tools
> Carey Heckman , Darthmouth College
> pp. 73-75
>
> Here's the abstract for the first one of these:
>
> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=1176999
>
> "Rather than use the product liability screwdriver as a chisel, why not
> consider a package of more effective tools. Corporations and individuals
> that market software despite knowledge of software security flaws should
> face criminal prosecution as well as civil lawsuits with punitive
> damages. Perhaps bounties should be available for the first to discover
> and establish the existence of a security flaw. Publishers should be
> required to post to the Web and otherwise publicize promptly patch
> availability. The software equivalent of an Underwriters Laboratories
> should establish and constantly improve security-related standards and
> testing protocols. It should be made readily apparent whether a program
> has passed and at what level. Prospective customers should be educated
> and encouraged to insist on software that has passed. Stronger software
> security is important. Software developers and publishers must do
> better. But product liability is not the right legal tool for the job."
>
> To me, this suggests a much more limited use of the legal system: with
> liability only for continued marketing of software with security flaws
> already known to the vendors.  Even that, though, is incompatible even
> with current best practices, where vendors of any large piece of
> software almost constantly have some vulnerabilities (and fixes for
> them) in the pipeline, yet they don't stop marketing the software during
> those periods (which would be almost all the time, and would ruin their
> businesses).
>
> I haven't read the actual articles.  Anyone found them non-paywalled?
>
> This presentation appears to argue in favor of strict liability and
> backs this up with some theory:
>
> http://www.slideshare.net/aliasnetwork/software-liability
>
> Open Source is briefly mentioned on slide 10.  I think it fails to
> consider (at least) the negative impact extra regulation will have on
> innovation.  To limit liability risks, a software product would need to
> be compliant with current best practices, not with potentially better
> practices that are not yet widely accepted and would necessarily be
> considered at least good by courts.
>
> [ While we're at it, I think the same problem - negative impact on
> innovation - applies to another old idea, insurance for IT-related risks
> including security compromises:
>
> http://fearlesssecurity.com/cyber-whatever-that-is-insurance-yet-again/
>
> Worse, besides innovation this would also discourage diverse setups -
> e.g., use of less popular operating systems, which insurers have no
> statistics on and don't want to bother with - even though these setups
> might actually be safer from actually occurring attacks (at least the
> non-targeted ones) precisely due to the diversity. ]
>
> Some maybe-relevant historical publications:
>
> http://link.springer.com/chapter/10.1007/3-540-58618-0_67
>
> Liability and computer security: Nine principles
> Ross J. Anderson
> Proceedings of Third European Symposium on Research in Computer Security
> Brighton, United Kingdom
> November 7-9, 1994
> pp. 231-245
>
> Here's the abstract:
>
> "The conventional wisdom is that security priorities should be set by
> risk analysis. However, reality is subtly different: many computer
> security systems are at least as much about shedding liability as about
> minimising risk. Banks use computer security mechanisms to transfer
> liability to their customers; companies use them to transfer liability
> to their insurers, or (via the public prosecutor) to the taxpayer; and
> they are also used to shift the blame to other departments (we did
> everything that GCHQ/the internal auditors told us to). We derive nine
> principles which might help designers avoid the most common pitfalls."
>
> A related thought is that if vendors would be liable for software
> vulnerabilities, they'd want to proactively turn those into
> non-vulnerabilities as far as the law is concerned, by proactively
> transferring liability onto other parties (their customers, etc.)
> Right now, they can do it in EULA.  If they would be legally barred from
> that, they might find other ways.  For example, rather than say "We
> disclaim all liability" in the EULA, the program could have e.g.
> execution of arbitrary code from e-mail messages described as intended
> behavior that the user authorizes.  OK, perhaps that would impact the
> vendor's sales, if their competitors don't do the same.  But possibly
> they'll find smarter ways, including those that would use "computer
> security mechanisms" (as the above abstract says) - just not those
> protecting the users, but rather those helping transfer liability away
> from the vendor.
>
> Some older publications I happened to find, apparently by lawyers:
>
> http://heinonline.org/HOL/LandingPage?handle=hein.journals/rutcomt8&div=16
>
> Product Liability and Software
> Michael C. Gemignani
> Rutgers Computer & Tech. L.J.
> 1980-1981
> p. 173
>
> http://www.jstor.org/discover/10.2307/40684795
>
> LIABILITY FOR COMPUTER SOFTWARE
> BRUCE DUCKER
> The Business Lawyer
> Vol. 26, No. 4 (April 1971)
> pp. 1081-1094
>
> Unfortunately, these are also paywalled.
>
> Most discussion on infosec mailing lists that I can find now is from the
> period 2000 to 2005, although I vaguely recall seeing this topic brought
> up in 1990s as well.
>
> Alexander

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ