Re: [iwar] interesting piece

From: Tony Bartoletti (
Date: 2001-05-03 16:54:17

Return-Path: <>
Received: from by localhost with POP3 (fetchmail-5.1.0) for fc@localhost (single-drop); Thu, 03 May 2001 16:54:07 -0700 (PDT)
Received: (qmail 26053 invoked by uid 510); 3 May 2001 22:54:03 -0000
Received: from ( by with SMTP; 3 May 2001 22:54:03 -0000
Received: from [] by with NNFMP; 03 May 2001 23:52:45 -0000
Received: (EGP: mail-7_1_2); 3 May 2001 23:49:36 -0000
Received: (qmail 11910 invoked from network); 3 May 2001 23:49:36 -0000
Received: from unknown ( by with QMQP; 3 May 2001 23:49:36 -0000
Received: from unknown (HELO ( by mta3 with SMTP; 3 May 2001 23:49:36 -0000
Received: from (localhost []) by (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id QAA09066 for <>; Thu, 3 May 2001 16:49:35 -0700 (PDT)
Received: from ( []) by (8.8.8/LLNL-3.0.2/ with ESMTP id QAA19675 for <>; Thu, 3 May 2001 16:49:35 -0700 (PDT)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
In-Reply-To: <>
From: Tony Bartoletti <>
Mailing-List: list; contact
Delivered-To: mailing list
Precedence: bulk
List-Unsubscribe: <>
Date: Thu, 03 May 2001 16:54:17 -0700
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 

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 Bartoletti 925-422-3881 <>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900


Your use of Yahoo! Groups is subject to 

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