Re: [iwar] interesting piece

From: Tony Bartoletti (azb@llnl.gov)
Date: 2001-05-03 16:54:17

Next message: Glenn Williamson: "RE: [iwar] interesting piece"
Previous message: mo haitao: "[iwar] why my letter had been delayed"
In reply to: Fred Cohen: "[iwar] interesting piece"
Next in thread: St. Clair, James: "RE: [iwar] interesting piece"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Message-Id: <4.3.2.7.2.20010503162128.00c2a510@poptop.llnl.gov>
To: iwar@yahoogroups.com
In-Reply-To: <200105031450.HAA04491@all.net>
From: Tony Bartoletti <azb@llnl.gov>
Mailing-List: list iwar@yahoogroups.com; contact iwar-owner@yahoogroups.com
Precedence: bulk
Date: Thu, 03 May 2001 16:54:17 -0700
Reply-To: iwar@yahoogroups.com
Subject: Re: [iwar] interesting piece
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Regarding the piece by James Adams of iDefense:

The article is largely on-the-money in terms of the threat.  Overall, 
however, I would like to see more emphasis upon the 
hardening/bullet-proofing of systems in general, rather than the focus upon 
advances in "trace-back and retaliate".

Toward the end of the article, there is the mention of "software vetting" 
that could plausibly be employed to "trap" backdoors or other malicious 
codes hidden in "imported" software products, along with stiff penalties 
should such mal-wares be discovered.

It occurs to me how difficult this is in general, from a point of attribution.

Suppose a government coerced a software vendor to accept "modifications" to 
a product that would provide a secret control channel.  How might such a 
channel best be implemented, so as to allow "plausible deniability"?  The 
answer is simple.  Find some small corner of a particular protocol handler, 
and "accidently omit" a buffer-overflow check.  Since the existence and 
location of the crafted flaw (and its surrounding code) is known in 
advance, it is easy to have a predetermined string that can be employed to 
take advantage of the opening.  Without fore-knowledge, it is very 
difficult to detect that the flaw even exists.  If the flaw is ever 
discovered, then "Oops, honest software flaw, prove otherwise."  Plausible 
deniability.

I believe that current legislation, which supports the ubiquitous "software 
supplied as is, no implied or express warrantee for fitness of use," terms 
and conditions that accompany most all software products, needs to be 
dumped.  In its place, allow degrees of "shelter from liability" for 
vendors who provide their codes to one or more independent software vetting 
services and receive their respective "good housekeeping seals of 
approval".  The more independent "seals" that are garnered, the broader the 
shield from liability.

Finally, the article makes no mention of the cascade of "trust-failure" 
that can occur when a major certificate authority is "tricked" into issuing 
a bogus code-signing certificate in the name of a widely-employed software 
firm.  Current "single trust-chain" signature validation and key 
certification regimes need to give way to some form of independent "k-of-n" 
type regimes that provide honestly independent and parallel channels for 
trust determination.

____tony____

Tony Bartoletti 925-422-3881 <azb@llnl.gov>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

------------------
http://all.net/ 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Next message: Glenn Williamson: "RE: [iwar] interesting piece"
Previous message: mo haitao: "[iwar] why my letter had been delayed"
In reply to: Fred Cohen: "[iwar] interesting piece"
Next in thread: St. Clair, James: "RE: [iwar] interesting piece"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

This archive was generated by hypermail 2.1.2 : 2001-06-30 21:44:10 PDT