Defense in depth was - RE: iframe tag attack

Sorry again, knew about that, though I replaced it.

What is the downside to provide additional tools and services to create
a safe mode. IDS such as tripwire or the Cisco product, Av, rootkits
detectors and such. Include them, bundle them into any service that is
considered safe and really providing some level of protection. It would
cost more, be more administrative work but it would have what is called
"defense in depth". It is not a stack of cards that can just fall apart
when one thing goes wrong.

The environment can be made to be reasonably safe. Although out of
scope for WSC, does it mean that these tools can't be part of a
recommendation.

Thx
Bill D.


-----Original Message-----
From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org] On Behalf Of Dan Schutzer
Sent: Friday, June 22, 2007 3:52 PM
To: public-wsc-wg@w3.org
Subject: FW: iframe tag attack




-----Original Message-----
From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org] On
Behalf Of Thomas Roessler
Sent: Friday, June 22, 2007 3:49 PM
To: Doyle, Bill
Cc: Dan Schutzer; Mike Beltzner; Rachna Dhamija; public-wsc-wg@w3.org
Subject: Re: iframe tag attack


redirecting again.  Please make sure you copy public-wsc-wg@w3.org.

DO NOT copy public-wsc-wg-request@w3.org.

Thanks all,
-- 
Thomas Roessler, W3C  <tlr@w3.org>








On 2007-06-22 19:47:16 +0000, Doyle, Bill wrote:
> From: "Doyle, Bill" <wdoyle@mitre.org>
> To: Dan Schutzer <dan.schutzer@fstc.org>,
> 	Mike Beltzner <beltzner@mozilla.com>,
> 	Rachna Dhamija <rachna.w3c@gmail.com>
> Cc: public-wsc-wg-request@w3.org
> Date: Fri, 22 Jun 2007 19:47:16 +0000
> Subject: RE: iframe tag attack
> X-Spam-Level: 
> Old-Date: Fri, 22 Jun 2007 15:47:08 -0400
> X-Diagnostic: Already on the subscriber list
> X-Diagnostic:  38 wdoyle@mitre.org                   32760
wdoyle@mitre.org
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5
> 
> Understand current environment and that OS, network is out and
> compromise of user agent is out for normal tasks.
>  
> I would like to see additional user agent checks and controls when a
> user agent task is declared "safe" given that user agents operate in
a
> less than secure environment.
>  
> Stated as safe, user expects safe.
>  
> B
>  
>  
>  
> 
> 
> ________________________________
> 
> 	From: Dan Schutzer [mailto:dan.schutzer@fstc.org] 
> 	Sent: Friday, June 22, 2007 3:34 PM
> 	To: Doyle, Bill; 'Mike Beltzner'; 'Rachna Dhamija';
> dan.schutzer@fstc.org
> 	Cc: public-wsc-wg-request@w3.org
> 	Subject: RE: iframe tag attack
> 	
> 	
> 
> 	Per my draft. This is an issue, but keeping a PC clean of bots
> and other malware is out-of-scope, although I provided some examples
of
> things we could do to help defeat this use case.
> 
> 	 
> 
> 	
> ________________________________
> 
> 
> 	From: Doyle, Bill [mailto:wdoyle@mitre.org] 
> 	Sent: Wednesday, June 20, 2007 4:10 PM
> 	To: Dan Schutzer; Mike Beltzner; Rachna Dhamija
> 	Cc: public-wsc-wg-request@w3.org
> 	Subject: RE: iframe tag attack
> 
> 	 
> 
> 	More thoughts.
> 
> 	 
> 
> 	"However if a user only downloaded from trusted sites when in
> safe mode (a big if, probably not realistic), then the scenario would
> be defeated"
> 
> 	 
> 
> 	User goes out, compromises browser, goes into safe mode, thinks
> they are secure and gives up the farm.
> 
> 	 
> 
> 	Looks like it gets back to the expectations that the user agent
> is functioning correctly and not compromised.
> 
> 	 
> 
> 	Does "safe" mode also need a user agent provided by a trusted
> source that is restricted to only go to sites that are "trusted"
> 
> 	 
> 
> 	Bill 
> 
> 	 
> 
> 	 
> 
> 	 
> 
> 	 
> 
> 	 
> 
> 	 
> 
> 	 
> 
> 		 
> 
> 		
> ________________________________
> 
> 
> 		From: Dan Schutzer [mailto:dan.schutzer@fstc.org] 
> 		Sent: Wednesday, June 20, 2007 9:24 AM
> 		To: Doyle, Bill; 'Mike Beltzner'; 'Rachna Dhamija'
> 		Cc: public-wsc-wg@w3.org
> 		Subject: RE: iframe tag attack
> 
> 		When in safe mode, this threat scenario should be
> defeated. The untrusted site would be rejected; the trusted site
would
> be audited to ensure there is sufficient security built-in that their
> web site is unlikely to be compromised. However, when not in the safe
> mode a user would be vulnerable as they can access any site. However
if
> a user only downloaded from trusted sites when in safe mode (a big
if,
> probably not realistic), then the scenario would be defeated.
> 
> 		 
> 
> 		Dan 
> 
> 		 
> 
> 		
> ________________________________
> 
> 
> 		From: public-wsc-wg-request@w3.org
> [mailto:public-wsc-wg-request@w3.org] On Behalf Of Doyle, Bill
> 		Sent: Wednesday, June 20, 2007 7:15 AM
> 		To: Mike Beltzner; Rachna Dhamija
> 		Cc: public-wsc-wg@w3.org
> 		Subject: RE: iframe tag attack
> 
> 		 
> 
> 		Thanks -- I pulled out part of your text that I want to
> review against the "safe" browsing modes are being discussed
> 
> 		 
> 
> 		iframe is doing things where a site which is
> trusted/identified in one way is loading content form a site that is
> not trusted
> 
> 		 
> 
> 		Bill D.
> 
> 		
> 		 
> 
> 			
> ________________________________
> 
> 
> 			From: Mike Beltzner
> [mailto:beltzner@mozilla.com] 
> 			Sent: Wednesday, June 20, 2007 1:54 AM
> 			To: Rachna Dhamija
> 			Cc: public-wsc-wg@w3.org; Doyle, Bill
> 			Subject: Re: iframe tag attack
> 
> 			Using Rachna's unpack (thanks for that!) the
> way I see it ...
> 			
> 			1. is definitely out of scope.
> 			
> 			2. is strange - the fact that the site is
> compromised makes me think this is out of scope, but must any
identity
> mechanisms that we do accept as in scope protect users from these
types
> of problems?
> 			
> 			3. feels in scope to me, especially if the
> iframe is doing things where a site which is trusted/identified in
one
> way is loading content form a site that is not trusted, and then
> presenting it as part of the trusted site. I understand that this is
a
> common practice amongst websites, but we need some mechanisms for
> enabling it without enabling this type of compromise as a side
effect,
> IMO. Also, we need a pony.
> 			
> 			4. the browser exploits that result in
> downloaded and installed malware are in scope, but once infected, the
> effects of that malware are totally out of scope.
> 			
> 			imo, fwiw, etc.
> 			
> 			cheers,
> 			mike
> 			----- Original Message -----
> 			From: "Rachna Dhamija" <rachna.w3c@gmail.com>
> 			To: "Bill Doyle" <wdoyle@mitre.org>
> 			Cc: public-wsc-wg@w3.org
> 			Sent: Tuesday, June 19, 2007 6:21:18 PM
> (GMT-0500) America/New_York
> 			Subject: Re: iframe tag attack
> 			
> 			On 6/19/07, Doyle, Bill <wdoyle@mitre.org>
> wrote: 
> 
> 				This enterprising company seems to have
> improved productivity.
> 
> 				 
> 
> 				New Web Exploit at 10,000 Machines and
> Growing, Security Company Warns
> 
> 				 
> 
> 				Seems to be a user agent issue, is this
> in or out of scope?
> 
> 			
> 			If we unpack the attack, this question might be
> easier to answer:
> 			1) Attacker compromises a web server using
> malware
> 
> 			2) User visits a legitimate, but compromised,
> website that includes malicious iframe 
> 			3) iframe causes browser to be redirected to a
> site with malicious javascript
> 			4) malicious javascript detects the browser
> type and exploits browser vulnerabilities to download code, which
then
> downloads other code (keyloggers, proxy, etc...) 
> 			
> 			We have ruled 1 out of scope.  How about the
> rest?  
> 			
> 			I am hoping that we can use our list of attacks
> (i.e., the threat trees) to come to a better understanding on what is
> in and out of scope.
> 			
> 			Rachna
> 
> 			 
>

Received on Sunday, 24 June 2007 23:32:10 UTC