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]
Message-ID: <44E0DBD0.8090401@utdallas.edu>
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ