From coley at rcf-smtp.mitre.org  Wed Feb  1 11:48:22 2012
From: coley at rcf-smtp.mitre.org (Steven M. Christey)
Date: Wed, 1 Feb 2012 12:48:22 -0500 (EST)
Subject: [VIM] iDefense advisory location
Message-ID: <Pine.GSO.4.64.1202011247180.16245@faron.mitre.org>


For people like me who couldn't find an iDefense advisory index after the 
site got moved to Verisign, it looks like they can be found here:

http://www.verisigninc.com/en_US/products-and-services/network-intelligence-availability/idefense/public-vulnerability-reports/index.xhtml

- Steve

From coley at rcf-smtp.mitre.org  Thu Feb 16 11:26:30 2012
From: coley at rcf-smtp.mitre.org (Steven M. Christey)
Date: Thu, 16 Feb 2012 12:26:30 -0500 (EST)
Subject: [VIM] CVE-2011-3571 and CVE-2011-5035 - dual use
Message-ID: <Pine.GSO.4.64.1202161224390.8305@faron.mitre.org>


All,

CVE-2011-3571 and CVE-2011-5035 were listed in the Oracle February CPU for 
Java, but each of these CVEs were also used in their January CPU.  Many of 
the details don't align, so it's not clear if this is accidental dual-use, 
or the underlying vuln is really the same.  I have an inquiry to Oracle to 
figure out what's going on.

- Steve

From jericho at attrition.org  Sat Feb 25 22:21:11 2012
From: jericho at attrition.org (security curmudgeon)
Date: Sat, 25 Feb 2012 22:21:11 -0600 (CST)
Subject: [VIM] How things change..
Message-ID: <alpine.LNX.2.00.1202252219220.16200@forced.attrition.org>


Reading a report from 2004 about Diebold election machine vulnerabilities. 
This was interesting:

   While the system is implemented in an unsafe language6(C++), the code
   reflects an awareness of avoiding such common hazards as buffer
   overflows. Most string operations already use their safe equivalents,
   and there are comments, e.g., should really use snprintf, reminding the
   developers to change oth- ers. While we are not prepared to claim that
   there are no exploitable buffer overflows in the current code, there are
   at the very least no glaringly obvious ones. Of course, a better
   solution would have been to write the entire system in a safe language,
   such as Java or Cyclone [15]. In such a language we would be able to
   prove that large classes of attacks, including buffer overflows and
   type-confusion attacks, are impossible assuming a correct implementation
   of the compiler and runtime system.

While I am not familiar with Cyclone at all, a quick search of "java 
overflow" on osvdb.org suggests things have really changed, or perhaps 
these researchers weren't naieve in their belief of the security 
of Java.