Re: [SC-L] darkreading: voting machines

2006-10-10 Thread Jeremy Epstein
Gary,

Interesting point.  I'm on the Virginia state commission charged with making
recommendations around voting systems, and we watched the Princeton video as
part of our most recent meeting.  The reaction from the election officials
was amusing and scary: "if this is so real, why don't you hack a real
election instead of this pretend stuff in the lab".  Pointing out that it
would (most likely) be a felony, and people like Rubin, Felten, and others
are trying to help security not go to jail didn't seem to impress them.
Also pointing out that the Rubin & Felten examples used out-of-date code
because vendors won't share anything up-to-date doesn't seem to impress
them.  [This in response to Diebold's claim that they were looking at old
code, and the problems are all "fixed".]

I frankly don't think anything is going to impress the election officials
(and some of the elected officials) short of incontrovertible evidence of a
DRE meltdown - and of course, we know that there could well be a failure
(and may have been failures) that are unproveable thanks to the nature of
software.

--Jeremy

P.S. One of the elected officials on the commision insisted that Felten
couldn't possibly have done his demo exploit without source code, because
"everyone" knows you can't do an exploit without the source.  Unfortunately,
the level of education that needs to be provided to someone like that is
more than I can provide in a Q&A format.  I tried giving as an example that
around 50% of the Microsoft updates are due to flaws found by people without
source, but he wouldn't buy it (he was using a Windows laptop, but
doesn't seem to understand where the fixes come from).

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Gary McGraw
> Sent: Monday, October 09, 2006 12:19 PM
> To: SC-L@securecoding.org
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [SC-L] darkreading: voting machines
> 
> Hi all,
> 
> I'm sure that many of you saw the "Ed Felten and friends 
> break Diebold machines" story a couple of weeks ago...maybe 
> in DDJ or on /..  I wrote a piece about the crack for 
> darkreading, which you can find here:
> 
> http://www.darkreading.com/document.asp?doc_id=105188&WT.svl=column1_1
> 
> The most interesting thing from an sc-l perspective about 
> this column is that it emphasizes a client need we're often 
> forced to address---the need for a demo exploit.  Sometimes 
> those on the receiving end of a software security 
> vulnerability don't believe that findings are real.
> An often-repeated excuse for doing nothing is "well, that's 
> just a theoretical attack and it's too academic to matter."  
> I can't tell you how many times I've heard that refrain.
> 
> When that happens, building an exploit is often the only 
> clear next step.  And yet we all know how expensive and hard 
> exploit development is.  
> 
> In this case, Diebold consistently downplay'ed Avi Rubin's 
> results as "academic" or "theoretical."  Ed upped the ante.  
> Think it'll work??
> 
> gem
> 
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> book www.swsec.com 
> 
> 
> --
> --
> This electronic message transmission contains information 
> that may be confidential or privileged.  The information 
> contained herein is intended solely for the recipient and use 
> by any other party is not authorized.  If you are not the 
> intended recipient (or otherwise authorized to receive this 
> message by the intended recipient), any disclosure, copying, 
> distribution or use of the contents of the information is 
> prohibited.  If you have received this electronic message 
> transmission in error, please contact the sender by reply 
> email and delete all copies of this message.  Cigital, Inc. 
> accepts no responsibility for any loss or damage resulting 
> directly or indirectly from the use of this email or its contents.
> Thank You.
> --
> --
> 
> ___
> Secure Coding mailing list (SC-L)
> SC-L@securecoding.org
> List information, subscriptions, etc - 
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - 
> http://www.securecoding.org/list/charter.php
> 
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


[SC-L] Insecurity in Open Source

2006-10-10 Thread Kenneth Van Wyk
FYI, there's an interesting opinion article in Business Week by Coverity's CTO, Ben Chelf (see link below).  In it, he discusses the results of their scanning of a significant sampling of both open- and closed-source projects.Chelf compares some special purpose proprietary software security/quality with the best of what's out in the open source world.  Further, he opines that the open source guys need to adopt far more rigorous QA testing in order to compete with the best of the proprietary source world.I'm passing this along not to launch into the invariable religious debates of closed- vs. open-source, but to encourage discussion about Chelf's claims with regards to rigorous QA testing.  Anyway, here's the article.http://www.businessweek.com/technology/content/oct2006/tc20061006_394140.htm?campaign_id=bier_tco.g3a.rss1007Cheers,Ken -Kenneth R. van WykKRvW Associates, LLChttp://www.KRvW.com 

PGP.sig
Description: This is a digitally signed message part
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


[SC-L] OWASP webappsec mailing list

2006-10-10 Thread Jeff Williams








Hi,

 

I’d like to invite you to join (or rejoin) the OWASP
webappsec mailing list. We started this mailing list almost 5 years ago and it
has spawned great discussion of application security issues. We’re moving
the list from its current home to a server controlled by OWASP. This will allow
us to provide the high quality moderation the list deserves.

 


 
  
  
  You can join (or rejoin) us on the webappsec list by clicking here…
   
  
  http://lists.owasp.org/mailman/listinfo/webappsec
   
  
 


 

If you haven’t visited OWASP in a while, please come
check out what’s going on. The OWASP standard tools, like WebScarab and WebGoat have all been improving
steadily over time.  And we have tons of new projects, content, and tools,
including:

 

- 
OWASP AJAX Security Project - investigating
security of AJAX
enabled applications 

- 
OWASP CAL9000 Project - a _javascript_
based web application security testing suite 

- 
OWASP Code Review Project - a
new project to capture best practices for reviewing code 

- 
OWASP Honeycomb Project - a guide
to the building blocks of application security 

- 
OWASP LAPSE Project - an Eclipse-based
source static analysis tool for Java 

- 
OWASP Live CD Project - a CD will
application security analysis and testing tools 

- 
OWASP Orizon Project - a flexible
code review engine 

- 
OWASP Pantera Web
Assessment Studio Project - a hybrid testing approach 

- 
OWASP PHP Project - helping PHP
developers build secure applications 

- 
OWASP Java Project - helping Java and
J2EE developers build secure applications 

- 
OWASP SQLiX Project - a full
perl-based SQL scanner 

- 
OWASP Testing Project - application
security testing procedures and checklists 

- 
OWASP Validation Project - a
project that provides guidance and tools related to validation.

 

As always, OWASP is free and open for everyone.  Please
forward this message to anyone who is interested in application security.
Thanks for your support.

 

--Jeff

 

Jeff Williams, Chair

The OWASP Foundation

 

"Dedicated to finding and fighting the causes of
insecure software"

 






___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php