bugtraq - Re: [Full-disclosure] RE: when will AV vendors fix this???

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 14 Aug 2006 15:23:44 -0500
From: Paul Schmehl <pauls@...allas.edu>
To: "Dmitry Yu. Bolkhovityanov" <D.Yu.Bolkhovityanov@....nsk.su>
Cc: "Thomas D." <whistl0r@...glemail.com>,
	full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re: [Full-disclosure] RE: when will AV vendors fix this???

Dmitry Yu. Bolkhovityanov wrote:
> 
> 	Any type of data/file hiding (of course, alternate data streams in 
> the first place) can become the last brick required for some new attack 
> vector.
> 
> 	So, while currently I can't present any workable scenario, I 
> wouldn't consider such type of data hiding as "not a security-relate 
> problem".
>
*Of course* it's a "security-related" problem.  The solution to that 
problem is what is being discussed.

When data is at rest, it presents no threat to the OS (AFAIK).  It's 
just electrons aligned in a certain, specific way on media.  It's only 
when data enters memory and becomes part of the stream that the 
processor(s) have to act upon that the threat becomes "real".  For data 
to enter memory it must be accessed in some way.  If that access process 
is being monitored and *if* the exploit is known, it will be detected 
and whatever action is specified by the protective software will be taken.

To put it another way, what risk do bombs stored in a concrete bunker 
present?  None, unless they are accessed somehow.  If proper monitoring 
is in place, that will never happen without being detected and prevented.

-- 
Paul Schmehl (pauls@...allas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5268 bytes)