Re: [SC-L] SearchSecurity: Medical Devices and Software Security

[Jeremy Epstein]

Agree with you - there's nothing new in the article.  I gave a talk a
couple years ago at a conference on biomedical engineering, and there was
one person in the room (out of a few hundred) who had heard of Therac-25.
(Which I assume is what you were referring to with 1985.)

If the article were instead published in a medical device or biomedical
engineering journal, that would be something different.  But as you say,
putting it in on SearchSecurity is just the echo chamber of security folks.

IMHO, anyone who builds medical devices that use software and hasn't read
about Therac-25 should be considered as unqualified.  (And if that gets
anyone on the list to pull out Google, who didn't recognize the reference
to 1985, so much the better!)





On Sun, Jul 6, 2014 at 1:21 AM, security curmudgeon 
wrote:

>
> On Mon, 30 Jun 2014, Gary McGraw wrote:
>
> : Chandu Ketkar and I wrote an article about medical device security based
> : on a talk Chandu gave at Kevin Fu?s Archimedes conference in Ann Arbor.
> : In the article, we discuss six categories of security defects that
> : Cigital discovers again and again when analyzing medical devices for our
> : customers.  Have a look and pass it on:
> :
> : http://bit.ly/1pPH56p
> :
> : As always, your feedback is welcome.
>
> Per your request, my feedback:
>
> Why do so many security professionals think we need yet another article on
> medical devices that give a high-level overview, that ultimately boils
> down to "medical devices are not secure"?
>
> We see these every month or three, and have for a long time. Other than
> medical vendors who are very resistent to the idea that their devices have
> issues, who is this written for? Who exactly outside medical vendors think
> that those devices are secure?
>
> These articles do nothing.. absolutely nothing, to fix problems. They are
> bandwagon articles jumping on the 'medical security' wave that has some
> attention right now. Everyone writing these articles seems to be
> completely new to the medical arena. Most that write this crap that I have
> talked to can't speak to any of the history of medical disclosures. Names
> like Fu and Halperin are foreign to them, and the importance of 1985 in
> the timeline of medical issues is lost on them. If you find yourself
> Googling any of those, thanks for proving my point.
>
> This shit is not new. These articles are NOT advancing our field or the
> medical field. Sure, you are getting a slice of attention for the issue,
> but mostly in our echo chamber.
>
> Finally, your intro. "Since 1996 my company has analyzed hundreds of
> systems..." Really? Hundreds? You might want to fix that, else you come
> across as complete n00bz in the industry. I've done single engagements
> that involved tends of thousands of machines. Perhaps you want to qualify
> that to mean hundreds of vendors? Hundreds per months/year?
>
> To illustrate I am not the only one who feels this way:
> https://twitter.com/attritionorg/status/485652525589086209
>
> 1 minute later:
> https://twitter.com/SteveSyfuhs/status/485652988044656640
>
> Seriously, dare to evolve.
>
> .b
> ___
> 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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
> ___
>
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] US DoD RFI on software assurance

[Jeremy Epstein]

All,

This may be of interest - an RFI is a way to both provide information and
influence future procurements by pointing out areas that need to be
emphasized.

https://www.fbo.gov/index?s=opportunity&mode=form&id=3c867a45671f0cde56fca2bf81bdaf44&tab=documents&tabmode=list

--Jeremy
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] informIT: Building versus Breaking

[Jeremy Epstein]

The HOST program is about building open source security products,
evangelizing open source security, helping with government
certifications, etc.  It's not fundamentally about secure coding or
software assurance.

--Jeremy

On Thu, Sep 1, 2011 at 1:37 PM, Jeffrey Walton  wrote:
> Hi Steve,
>
> On Wed, Aug 31, 2011 at 4:45 PM, Steven M. Christey
>  wrote:
>>
>> While I'd like to see Black Hat add some more defensive-minded tracks, I
>> just realized that this desire might a symptom of a larger problem: there
>> aren't really any large-scale conferences dedicated to defense / software
>> assurance.  (The OWASP conferences are heavily web-focused;
> I believe OWASP is moving towards Application Security in general. At
> the chapter meetings I attend, we were told the acronym is probably
> going to be changed to "Open Web and Application Security Project".
>
>> Dept. of Homeland Security has its software assurance forum and working
>> groups, but those are relatively small.)
> Homeland Security also has the HOST program, which partners with
> industry, http://www.cyber.st.dhs.gov/host/. I'm just mentioning it
> because its seems to be a bit more than a [low volume] forum.
>
>> If somebody built it, would anybody come?
> If the prices is right ;)
>
> Jeff
>
> ___
> 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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
> ___
>

___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] Cybersecurity competitions - seeking input

[Jeremy Epstein]

Greetings,

I'm putting together a catalog of cybersecurity competitions, and
would appreciate any that you're aware of that I may have missed.  I'm
particularly interested in those that are (1) aimed at high school or
college students and (2) are recurring.  I know there have been some
CTF activities that aren't on my list, mostly because I couldn't find
much information about them.

I'm also particularly interested in any that relate to the
preventative aspect of cybersecurity (e.g., secure coding), but I
haven't located any competitions that have that focus.

My current list; some of these do not meet the above criteria, but
I've included them for other reasons:

Cyber Collegiate Defense Competition
International Capture the Flag
Russian Capture the Flag
CodeGate
CyberPatriot
DC3
OWASP Secure the Flag
UK Cyber Security Challenge
Cyber Defense Exercise
NetWars
Cyber Security Competition
CYB3R BATTL3GROUND
High School Forensics Challenge

Thanks in advance!
--Jeremy
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] Backdoors in custom software applications

[Jeremy Epstein]

There was an interesting example in a NPS thesis about a decade ago
introducing a back door into a device driver.  I can't remember the
student's name, unfortunately.  Phil something-or-other.

On Thu, Dec 16, 2010 at 3:18 PM, Sebastian Schinzel  wrote:
> Hi all,
>
> I am looking for ideas how intentional backdoors in real software 
> applications may look like.
>
> Wikipedia already provides a good list of backdoors that were found in 
> software applications: http://en.wikipedia.org/wiki/Backdoor_(computing)
>
> Has anyone encountered backdoors during code audits, penetration tests, data 
> breaches?
> Could you share some details of how the backdoor looked like? I am really 
> interested in
> a technical and abstract description of the backdoor (e.g. informal 
> descriptions or pseudo-code).
> Anonymized and off-list replies are also very welcome.
>
> Thanks,
> Sebastian
> ___
> 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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
> ___
>
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] informIT: Technology transfer

[Jeremy Epstein]

The ITS4 article can be found at
http://www.acsac.org/2000/abstracts/78.html - it won the best paper
award when it was presented in 2000.  (I don't think SLINT was every
presented at a professional conference.)

And since I'm mentioning ACSAC, the deadline for early registration is
coming up on Nov 11 - some really fascinating papers this year, that
maybe you'll be discussing 10 years from now ;-).  It's at the Four
Seasons in Austin Dec 6-10 (and hotel rooms are only $104!)

--Jeremy

On Thu, Oct 28, 2010 at 3:04 PM, Chris Wysopal  wrote:
>
> Nice article.  There is a piece of this history that predated ITS4 which is 
> L0pht's SLINT which was in 1998 and demoed to you and John Viega.
>
> Here was our original description:
>
> http://web.archive.org/web/19990209122838/http://www.l0pht.com/slint.html
>
> >From the Feb, 1999 web page:
>
> 
>
> Source code security analyzers are publicly available in the black hat 
> community and are being used to scan for exploitable code. SLINT will help 
> you render the PD wares obsolete."
>
> What is it?
> SLINT is a core product to be sold into an existing GUI development package.
>         - Helps people be proactive while writing secure code by highlighting 
> positional hot spots of exploitable routines and poor memory allocations.
>         - Identifies suspect blocks of code.
>         - Makes the task of security review more palatable so you don't need 
> a team of high-level experts to go through megabytes of code.
>         - Supplies solutions and/or alternatives to problem areas.
>         - Most security problems could have been fixed at the beginning of 
> development. Secure applications must start with a secure base. The Best 
> *BANG* for the buck is to be proactive at the start of program creation
>         - Easy to implement into existing Y2K code review packages
>
>  What will it examine and on what platforms?
>
>         - Unix/NT
>         - C, C++ (JAVA in the future)
>         - elf-32 binaries
>         - a.out files
>         - buffer overflows
>         - improper SetUID of files
>         - randomness code faults
>         - race conditions
>         - incorrect access of memory
>         - improper flags on critical system calls
>         - more?
>
> 
>
> Sounds very familiar. It is almost hard to believe that was 12 years ago.
>
> SLINT in turn grew out of the black hat community so I won't claim that L0pht 
> had this idea first, just that we took it to the "consultingware" level.  I 
> like that term because I lived it with SLINT at L0pht and then UnDeveloper 
> Studio at @stake which has become the commercial static code analysis service 
> at Veracode.  Our technology at Veracode followed a similar track that the 
> Cigital to Fortify to HP technology has.
>
> -Chris
>
> -Original Message-
> From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On 
> Behalf Of Gary McGraw
> Sent: Tuesday, October 26, 2010 10:14 AM
> To: Secure Code Mailing List
> Subject: [SC-L] informIT: Technology transfer
>
> hi sc-l,
>
> >From time to time a thread or two has popped up on this list discussing how 
> >we get software security into the main stream.  One obvious way to do this 
> >is through technology transfer.  I am particularly proud of the role that 
> >Cigital has played getting security-focused static analysis out into the 
> >"main stream."  Now that IBM owns Ounce and HP owns Fortify we should see 
> >significant uptake of the technology worldwide.
>
> My informIT column this month is a case study that follows a technology from 
> Cigital Labs, through Kleiner Perkins and Fortify to the mainstream.  As you 
> will see, technology transfer is hard and it takes serious time and effort.  
> In the case of code scanning technology, the effort took two companies, 
> millions of dollars, serious silicon valley engineering and ten years.
>
> Read all about it here: 
> 
>
> Your comments and feedback are welcome.
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> blog www.cigital.com/justiceleague
> book www.swsec.com
>
> ___
> 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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
> ___
>
> ___
> 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 is hosted and moderated by KRv

[SC-L] DC voting experiment hacked

[Jeremy Epstein]

As many of you know, DC is doing an Internet voting pilot - original
plan was to allow voters to download blank ballots as PDF, mark them,
and submit them (*).  They set up a test server and encouraged anyone
interested to take a whack - which promptly happened.  A team from
Univ of Michigan led by Prof Alex Halderman completely compromised the
system within 36 hours, using a shell injection vulnerability.  They
were able to modify every ballot submitted, as well as other changes
that they haven't described yet.

This is relevant for readers of this list because voting is one of
those cases where software security has a direct impact on your
government (whether you live in the US or another country)!

(*) After it became obvious that the system was completely hacked, DC
Board of Elections and Ethics backed off, and are now allowing
download of blank ballots, but ballots must be returned by paper mail,
email, or FAX.  Of course that's a mixed blessing - all three of these
have significant issues of their own - especially tampering and
privacy issues with email voting!


Explanation of the technical stuff at
http://www.freedom-to-tinker.com/blog/jhalderm/hacking-dc-internet-voting-pilot

Here's an excellent analysis of the impact by David Jefferson of
Verified Voting.

-

University of Michigan Prof. Alex Halderman has now released some
details about his successful attack on the District of Columbia's
proposed Internet voting system which has been under test for the last
week.  (See www.freedom-to-tinker.com.)  It is now clear that
Halderman and his team were able to completely subvert the entire DC
Internet voting system remotely, gaining complete control over it and
substituting fake votes of their choice for the votes that were
actually cast by the test voters.  What is worse, they did so without
the officials even noticing for several days.

Let there be no mistake about it: this is a major achievement, and
supports in every detail the warnings that security community have
been giving about Internet voting for over a decade now.  After this
there can be no doubt that the burden of proof in the argument over
the security of Internet voting systems has definitely shifted to
those who claim that the systems can be made secure.

Computer security and election experts have been saying for over 10
years that the transmission of voted ballots over the Internet cannot
be made safe with any currently envisioned technology.  We have been
arguing mostly in vain that:

1) Remote attack: Internet voting systems can be attacked remotely by
any government, any criminal syndicate, or any self aggrandizing
individual in the world.

2) Effective defense virtually impossible: There are innumerable modes
of attack, from very easy to very sophisticated, and if anyone
seriously tried to attack an Internet election the election officials
would have essentially no chance at successfully defending.  The
election would be compromised

3) Attackers may change votes arbitrarily: An attack need not just
prevent people from voting (bad as that would be), but could actually
change large numbers of votes, allowing the attackers to determine the
winner.

4) Attacks may be undetected: An attack might go completely
undetected.  The wrong people could be elected and no one would ever
know.

Prof. Halderman demonstrated all of these points:

1) Remote attack: His team of four conducted their attack remotely,
from Michigan, via the Internet, without ever getting near Washington,
D.C.

2) Effective defense virtually impossible: Although they were
restricted from most modes of attack (which would be illegal even in
this test situation), they still succeeded in completely owning
(controlling) the voting system within about 36 hours after it was
brought up, even though they had only 3 days of notice of when it
would start.  They happened to use one particular small vulnerability
that they identified, but they are quite confident that they could
have penetrated in other ways as well.  Most likely they were the only
team to even attempt to attack the system seriously; yet in a real
election with something important at stake multiple teams might
attack.  The fact that the only team that even tried succeeded so
quickly is a demonstration lots of other groups from around the world
could also have done it.

3) Attackers may change votes arbitrarily:They not only changed some
of the votes, they changed them all, both those cast before they took
control of the system and those cast afterward.  There is no way that
officials can restore the original votes without the attackers' help.

4) Attacks may be undetected:The attack was not detected by the
officials for several days, despite the fact that they were looking
for such attacks (having invited all comers to try) and despite the
fact that the attackers left a "signature" by playing the Michigan
Fight song after every vote was cast!

This successful demonstration of the danger of Internet voting is 

[SC-L] Wanna analyze a real voting system? Open season on DC's Internet pilot system

[Jeremy Epstein]

All,

For a VERY short window (Sep 24-30), the DC Board of Elections and
Ethics is opening up their system for review - documents, source code,
and a live system to hack.  I think it's probably a well-designed
system (the folks doing it are knowledgeable), but it's of course
completely vulnerable to any sort of client-side attacks, as well as
anything in the network (e.g., DNS spoofing, BGP rerouting), even if
the server-side implementation is secure.  They're offering a
get-out-of-jail-free card

If anyone is interested in working with me, please contact me ASAP.

Press release at http://www.dcboee.org/popup.asp?url=/pdf_files/nr_588.pdf

---Jeremy
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] Solution for man-in-the-browser

[Jeremy Epstein]

Just to echo the other comments - there's already malware out there
that handles per-transaction authorization codes and substitutes in
its fraudulent transaction for the real one.  (If you look at some of
the banking thefts against small & medium businesses, that's what's
happening.)  So this scheme wouldn't even address existing threats,
much less new ones.

Having said that, if the organization being defended is obscure enough
and/or the potential transaction value is low enough, there may be
little enough value to an attacker that even an easily bypassed
mechanism such as that proposed might have a deterrent effect.  Just
as a lock on the front door is no protection against even a moderately
sophisticated thief (who knows how to lock-bump, for example) doesn't
mean that there's no value in keeping the door locked.  It's just
adding a measure of obscurity.  The question is whether the additional
obscurity increases the work factor for a potential attacker enough to
compensate for the additional effort to the user.  Since in this case
it looks like the user would have to enter a one-time transaction
code, the answer is almost certainly "no".

--Jeremy
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] One day software security awareness training?

[Jeremy Epstein]

All,

I'm looking for a one day software security awareness training class for a
client.  Yes, I know one day isn't enough to teach what people need to know,
but I'll be lucky if I can get them to spend that long.  (The initial
reaction to my recommendation was "no way".)

My goal is for them to learn basics like:
- How adversaries work
- Types of tools (static analysis, dynamic analysis, fuzzing)
- Architectural concerns (e.g., don't implement security in an uncontrolled
client)
- Basic code dos & don't - OWASP top 10 / SANS top 25 types of things

System they're building is in Java & Flex.

If you sell such training, please contact me OFF list so this doesn't become
an advertisement.  If you have a recommendation for a course you've taken,
I'd definitely like to hear about it!

Thanks,
--Jeremy

P.S. If geography matters, the client has distributed development between a
US east coast location and a US mountain location.  Open to whether training
would be at one of their locations or bring their people to a site.  It's
only about 15 developers, so definitely not worth a custom course.
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] seeking hard numbers of bug fixes...

[Jeremy Epstein]

Take a look at Mary Ann Davidson's keynote at ACSAC in Dec 2009.
http://www.acsac.org/2009/program/keynotes/davidson.pdf

On Mon, Feb 22, 2010 at 9:17 AM, Benjamin Tomhave
 wrote:
> Howdy,
>
> This request is a bit time critical as it's supporting a colleague's
> upsell up the food chain tomorrow... we're looking for hard research or
> numbers that covers the cost to catch bugs in code pre-launch and
> post-launch. The notion being that the organization saves itself money
> if it does a reasonable amount of QA (and security testing) up front vs
> trying to chase things down after they've been identified (and possibly
> exploited).
>
> Any help?
>
> Thank you,
>
> -ben
>
> --
> Benjamin Tomhave, MS, CISSP
> tomh...@secureconsulting.net
> Blog: http://www.secureconsulting.net/
> Twitter: http://twitter.com/falconsview
> LI: http://www.linkedin.com/in/btomhave
>
> [ Random Quote: ]
> "Imagination is everything. It is the preview of life's coming attractions."
> Albert Einstein
> ___
> 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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> ___
>
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

[SC-L] A massive change at DARPA

[Jeremy Epstein]

OK, many of you don't care about DARPA, but here's something that
happened there you *should* care about.  DARPA funds research, and has
historically drawn its program managers from the ranks of academia and
occasionally the military.  This is a massive change in outlook


http://news.cnet.com/8301-27080_3-10450552-245.html

 Peiter Zatko--a respected hacker known as "Mudge"--has been tapped to
be a program manager at DARPA, where he will be in charge of funding
research designed to help give the U.S. government tools needed to
protect against cyberattacks, CNET has learned.

Zatko will become a program manager in mid-March within the Strategic
Technologies Office at DARPA (Defense Advanced Research Projects
Agency), which is the research and development office for the
Department of Defense. His focus will be cybersecurity, he said in an
interview with CNET on Tuesday.

One of his main goals will be to fund researchers at hacker spaces,
start-ups, and boutiques who are most likely to develop technologies
that can leapfrog what comes out of large corporations. "I want
revolutionary changes. I don't want evolutionary ones," he said.

He's also hoping that giving a big push to research and development
will do more to advance the progress of cybersecurity than public
policy decisions have been able to do over the past few decades.

[...]
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

[SC-L] "Checklist Manifesto" applicability to software security

[Jeremy Epstein]

Greetings,

I was listening yesterday to an interview [1] on NPR with Dr. Atul
Gawande, author of "Checklist Manifesto" [2].  He describes the
problem that medical procedures (e.g., surgery) tend to have lots of
mistakes, mostly caused because of leaving out important steps.  He
claims that 2/3 of medical - or maybe surgical - errors can be avoided
by use of checklists.  Checklists aren't very popular among doctors,
because they don't like to see themselves as factory workers following
a procedure, because the human body is extremely complex, and because
every patient is unique.

So as I was listening, I was thinking that many of the same things
could be said about software developers and problems with software
security - every piece of software is unique, any non-trivial piece of
software is amazingly complex, developers tend to consider themselves
as artists creating unique works, etc.

Has anyone looked into the parallelisms before?  If so, I'd be
interested in chatting (probably offlist) about your thoughts.

--Jeremy

[1] Listen to the interview at http://wamu.org/programs/dr/10/01/06.php#29280
[2] "The Checklist Manifesto: How to Get Things Right", Atul Gawande,
Metropolitan Books.
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Provably correct microkernel (seL4)

[Jeremy Epstein]

Caveats on the proofs, as I recall.  I'll try to dig up the details.
It's been pretty extensively discussed elsewhere...

On Fri, Oct 2, 2009 at 12:54 PM, Dimitri DeFigueiredo
 wrote:
> There is a proof for a whole kernel I can use today. How's that not 
> practically useful? Is it not practically useful because there are caveats on 
> the proof? I don't we can just dismiss this one without further reasoning or 
> because we don't know how to apply it to our own problems.
>
> Dimitri
>
> -Original Message-
> From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On 
> Behalf Of Jeremy Epstein
> Sent: Friday, October 02, 2009 6:38 AM
> To: Wall, Kevin
> Cc: Secure Code Mailing List
> Subject: Re: [SC-L] Provably correct microkernel (seL4)
>
> This was discussed a few months ago on several other lists I read.
> The consensus is that it's interesting, and is further than anyone
> else has gone in recent years to do proofs, but not practically
> useful.  Additionally, there are a lot of caveats on the proof (which
> I don't recall, but are well documented on their web site) that make
> it clear it's not really as useful as it might sound.
>
> --Jeremy
>
> On Thu, Oct 1, 2009 at 5:33 PM, Wall, Kevin  wrote:
>> Thought there might be several on this list who might appreciate
>> this, at least from a theoretical perspective but had not seen
>> it. (Especially Larry Kilgallen, although he's probably already seen it. :)
>>
>> In 
>> http://www.unsw.edu.au/news/pad/articles/2009/sep/microkernel_breakthrough.html,
>>
>>    "Professor Gernot Heiser, the John Lions Chair in Computer Science in
>>    the School of Computer Science and Engineering and a senior principal
>>    researcher with NICTA, said for the first time a team had been able to
>>    prove with mathematical rigour that an operating-system kernel -- the
>>    code at the heart of any computer or microprocessor -- was 100 per cent
>>    bug-free and therefore immune to crashes and failures."
>>
>> In a new item at NICTA
>> <http://nicta.com.au/news/current/world-first_research_breakthrough_promises_safety-critical_software_of_unprecedented_reliability>
>>
>> it mentions this proof was the effort of 6 people over 5 years (not quite
>> sure if it was full-time) and that "They have successfully verified 7,500
>> lines of C code [there's the problem! -kww] and proved over 10,000
>> intermediate theorems in over 200,000 lines of formal proof". The proof is
>> "machine-checked using the interactive theorem-proving program Isabelle".
>>
>> Also the same site mentions:
>>    The scientific paper describing this research will appear in the 22nd
>>    ACM Symposium on Operating Systems Principles (SOSP)
>>        http://www.sigops.org/sosp/sosp09/.
>>    Further details about NICTA's L4.verified research project can be found
>>    at http://ertos.nicta.com.au/research/l4.verified/.
>>
>> My $.02... I don't think this approach is going to catch on anytime soon.
>> Spending 30 or so staff years verifying a 7500 line C program is not going
>> to be seen as cost effective by most real-world managers. But interesting
>> research nonetheless.
>>
>> -kevin
>> ---
>> Kevin W. Wall           Qwest Information Technology, Inc.
>> kevin.w...@qwest.com    Phone: 614.215.4788
>> "It is practically impossible to teach good programming to students
>>  that have had a prior exposure to BASIC: as potential programmers
>>  they are mentally mutilated beyond hope of regeneration"
>>    - Edsger Dijkstra, How do we tell truths that matter?
>>      http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html
>>
>> ___
>> 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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
>> as a free, non-commercial service to the software security community.
>> ___
>>
>
> ___
> 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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> ___
>

___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Provably correct microkernel (seL4)

[Jeremy Epstein]

This was discussed a few months ago on several other lists I read.
The consensus is that it's interesting, and is further than anyone
else has gone in recent years to do proofs, but not practically
useful.  Additionally, there are a lot of caveats on the proof (which
I don't recall, but are well documented on their web site) that make
it clear it's not really as useful as it might sound.

--Jeremy

On Thu, Oct 1, 2009 at 5:33 PM, Wall, Kevin  wrote:
> Thought there might be several on this list who might appreciate
> this, at least from a theoretical perspective but had not seen
> it. (Especially Larry Kilgallen, although he's probably already seen it. :)
>
> In 
> http://www.unsw.edu.au/news/pad/articles/2009/sep/microkernel_breakthrough.html,
>
>    "Professor Gernot Heiser, the John Lions Chair in Computer Science in
>    the School of Computer Science and Engineering and a senior principal
>    researcher with NICTA, said for the first time a team had been able to
>    prove with mathematical rigour that an operating-system kernel -- the
>    code at the heart of any computer or microprocessor -- was 100 per cent
>    bug-free and therefore immune to crashes and failures."
>
> In a new item at NICTA
> 
>
> it mentions this proof was the effort of 6 people over 5 years (not quite
> sure if it was full-time) and that "They have successfully verified 7,500
> lines of C code [there's the problem! -kww] and proved over 10,000
> intermediate theorems in over 200,000 lines of formal proof". The proof is
> "machine-checked using the interactive theorem-proving program Isabelle".
>
> Also the same site mentions:
>    The scientific paper describing this research will appear in the 22nd
>    ACM Symposium on Operating Systems Principles (SOSP)
>        http://www.sigops.org/sosp/sosp09/.
>    Further details about NICTA's L4.verified research project can be found
>    at http://ertos.nicta.com.au/research/l4.verified/.
>
> My $.02... I don't think this approach is going to catch on anytime soon.
> Spending 30 or so staff years verifying a 7500 line C program is not going
> to be seen as cost effective by most real-world managers. But interesting
> research nonetheless.
>
> -kevin
> ---
> Kevin W. Wall           Qwest Information Technology, Inc.
> kevin.w...@qwest.com    Phone: 614.215.4788
> "It is practically impossible to teach good programming to students
>  that have had a prior exposure to BASIC: as potential programmers
>  they are mentally mutilated beyond hope of regeneration"
>    - Edsger Dijkstra, How do we tell truths that matter?
>      http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html
>
> ___
> 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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> ___
>

___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

[SC-L] NSA comparison of source code analysis tools

[Jeremy Epstein]

(Apologies if I already sent this to the group; I don't think I did.)

There's an interesting presentation at
http://www.iarpa.gov/stonesoup_Merced_DHSAWGbrief.pdf about a study
done by the US NSA (National Security Agency) of C and Java source
code analysis tools.  They developed a synthetic test suite, and then
ran six tools against the Java version and five tools against the C
version (the specific tools and versions used are identified in the
presentation).  None of the tools found all of the problems, and 40%
of the problems weren't found by any of the tools.  Even where the
problems were found, there was a surprising level of inconsistency
among the tools.

Unfortunately, there's not much detail in the presentation.  There's a
report that's been written, but so far not approved for release (or so
I'm told).  I don't know whether the issue is classification (they
don't want the bad guys to know what sort of things can sneak past
their detectors), or proprietary information, or just bureaucracy.

It would be interesting to hear comments from vendors on the list as
to the limitations on such a test (certainly using synthetic programs
isn't realistic), as well as whether they've adapted the tools to find
more of these types of problems.

--Jeremy

P.S. The report is undated, but I believe it's fairly recent.
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] embedded systems security analysis

[Jeremy Epstein]

I spent a fair bit of time doing stuff relating to voting systems,
which all have embedded systems.  (I am not one of the experts who
pulls them apart, lest anyone think I'm claiming credit for them.)
They are supposedly closed systems, but every time someone competent
has tried to attack them, they've been successful - even if there are
no published APIs or documents, all of them have attack surfaces.  It
might be something like the ability to insert a card in a PC slot (as
in the Princeton attack on Diebold touchscreen systems), a USB stick
(some of the UC Santa Barbara attacks - I think that was ES&S
touchscreen machines), Harri Hursti's attacks via a memory card on
Diebold optical scanners, Princeton's attacks via a proprietary memory
card on Sequoia systems, etc.  (There are others too - the machines in
my county use USB sticks and run Windows CE, so I believe they're
susceptible to even trivial attacks via an autorun.)  I also worked
with a team that did some attacks on another embedded system in a
voting machine, although we didn't get far enough to publish results
before we ran out of students to do the grunt work.

So I'd 1000% agree with Arian - not only is assuming you're safe
dangerous, but it's also wrong.

There's lots of attacks on other types of embedded systems - there
have been a few against electric power control systems, water control
systems, etc.  And there are more that haven't seen the light of
day I just heard about a very serious attack the other day that
hasn't ever made it into the news.

--Jeremy

On Thu, Aug 20, 2009 at 2:09 PM, Arian J.
Evans wrote:
> Rafael -- to clarify concretely:
>
> There are quite a few researchers that attack/exploit embedded
> systems. Some google searches will probably provide you with names.
>
> None of the folks I know of that actively work on exploiting embedded
> systems are on this listbut I figure if I know a handful of them
> in my small circle of software security folks - there have to be many
> more out there.
>
> Assuming you are safe is not just a dangerous assumption: but wrong.
>
> Specifically -
>
> One researcher I know pulls boards & system components apart and finds
> out who the source IC and component makers are.
>
> Then they contact the component and IC makers and pretends to be the
> board or system vendor who purchased the components, and asks for
> documentation, debuggers, magic access codes hidden in firmware (if he
> cannot reverse them).
>
> If this fails, the researcher has also befriended people at companies
> who do work with the IC or board maker, traded them information, in
> exchange for debuggers and the like.
>
> This particular researcher does not publish any of their research in
> this area. They do it mainly (I think) to help build better tools and
> as a hobby. (Several of you on this list probably know exactly whom
> I'm talking about. This person would prefer privacy, and I think the
> person's employer demands it, unless you get him in person and feed
> him enough beer.)
>
> If I were a bettin' man I'd figure if I know a few person doing this
> type of thing for quite a few years now -- there are bound to be many,
> many more
>
> Not sure what list to go to for talks on that type of thing.
> Blackhat.com has some older presentations on this subject.
>
> --
> Arian Evans
>
>
>
> On Wed, Aug 19, 2009 at 8:36 AM, Rafael Ruiz wrote:
>> Hi people,
>>
>> I am a lurker (I think), I am an embedded programmer and work at
>> Lowrance (a brand of the Navico company), and I don't think I can't
>> provide too much to security because embedded software is closed per se.
>> Or maybe I am wrong, is there a way to grab the source code from an
>> electronic equipment? That would be the only concern for embedded
>> programmers like me, but I just like to learn about the thinks you talk.
>>
>> Thank you.
>>
>> Greetings from Mexico.
>>
>> ___
>> 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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
>> as a free, non-commercial service to the software security community.
>> ___
>>
> ___
> 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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> ___
>
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/

[SC-L] Seeking vulnerable server-side scripts

[Jeremy Epstein]

Greetings,

I'm experimenting (on paper initially) with a technique for improving
resiliency of web applications, and to do so am looking for examples
of server side scripts (PHP, Perl, whatever) that have security
vulnerabilities, to see if the technique would work.  If you have
scripts you'd be willing to share, please contact me off-list.  The
scripts don't have to be open source; I'm happy to take scripts that
are not for redistribution (but I can't sign formal NDAs).  The ideal
scenario would include enough of the infrastructure (scripts,
descriptions of the environment) and a description of the
vulnerability... but again, I'll take what I can get for now.  The
important thing is that the scripts be server-side and written in an
interpreted scripting language; I'm not looking for server-side C or
Java programs.

If there are repositories of such things, please excuse the newbie
question and point me in the right direction!

Thanks,
--Jeremy
703-989-8907 (mobile)
jeremy.j.epst...@gmail.com

P.S. Yes, you may forward this message to other people, but I'd
appreciate not sending it to other lists without checking with me
first.
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] RSA panel

[Jeremy Epstein]

RSA records all the sessions and makes the recordings available for
purchase at some exorbitant fee.



On 4/15/09, Brad Andrews  wrote:
>
> Are any of these going to be recorded?  That would help those of us
> with no travel budget or time.  :)
>
> Brad
>
> Quoting Gary McGraw :
>
>> hi sc-l,
>>
>> Presumably some of you will be at RSA this year.  I'm doing three
>> panels and a talk (with Brian Chess) on the BSIMM.
> ___
> 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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> ___
>

-- 
Sent from my mobile device
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] RSA panel

[Jeremy Epstein]

I'm also doing a panel on security in voting systems.  Podcast at
https://365.rsaconference.com/blogs/podcast_series_rsa_conference_2009/2009/04/15/jeremy-epstein-rr-107-technology-lessons-learned-from-election-2008

Hope to see many of you at the panel - Tue @ 410pm.

--Jeremy

On Wed, Apr 15, 2009 at 3:47 PM, Gary McGraw  wrote:
> hi sc-l,
>
> Presumably some of you will be at RSA this year.  I'm doing three panels and 
> a talk (with Brian Chess) on the BSIMM.  One of the panels (the one on 
> surveillance) has already generated some press interest:
> http://searchsecurity.techtarget.com/news/interview/0,289202,sid14_gci1353725,00.html
>
> My favorite question in the short Q&A is, "why should a software security guy 
> care about privacy and surveillance?"  Uh, yeah.  Do YOU guys care?  I do.
>
> The panel is sponsored by IEEE Security & Privacy magazine, and a reception 
> will follow the panel.  Come see us.
>
> Hope to see some of you at RSA.
>
> gem
>
> http://www.cigital.com/~gem
>
> ___
> 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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> ___
>

___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Certified Application Security Specialists

[Jeremy Epstein]

The cat's out of the bag.  LAMN is being acquired by ASSCERT we
decided that some certifications *are* valid.

On Wed, Apr 1, 2009 at 11:25 AM, SC-L Reader Dave Aronson
 wrote:
> Y'all-
>
> I think I've finally found the right certification for me!  Check out
> the Institute for
> Certified Application Security Specialists, at http://www.asscert.com/ today!
>
> -Dave
>
> --
> Dave Aronson: Have Pun, Will Babble | Work: davearonson.com | /\ ASCII
> | Play: davearonson.net | \/ Ribbon
> "Specialization is for insects."| Life: dare2xl.com | /\ Campaign
> -Robert A. Heinlein | Wife: nasjleti.net| Email<>Web
> ___
> 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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> ___
>
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] The Importance of Type Safety

[Jeremy Epstein]

This is kind of a funny discussion, to those of us over a "certain
age".  When I was a young-un :-), the argument was that you couldn't
write real software in a "high level" language like C because it was
too inefficient compared to assembly language, and you lost
flexibility since you didn't have direct hardware access.  Then
someone actually measured it, and discovered that writing in a higher
level language yielded more efficient programs, because programmers
could focus on the bigger picture.  Plus, optimizing compilers helped
reduce the difference through better optimization than most
programmers could do by hand.  And the very small portion that needed
the hardware access could be handled specially.

A decade or so ago, we heard the same thing about Java - can't write
"real" code in it because it's too inefficient.  But Java compilers
have gotten better, and the high level abstractions allow programmers
to focus on the important stuff, and not on some of the details (like
bounds checking).  My bet is that if someone repeated the assembly vs.
C experiment, they'd find that writing in Java is (for most people)
more efficient than writing in C.  Yes, there are some C programmers
who can write more efficient code - but not most.  Similarly for
flexibility - yes, there are things you can't do in Java, but most of
them are things you shouldn't be doing anyway...

--Jeremy
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs

[Jeremy Epstein]

On Thu, Mar 19, 2009 at 11:14 AM, Benjamin Tomhave <
list-s...@secureconsulting.net> wrote:

> gee whiz, what if you have letters after your name that aren't
> meaningless certifications (like MS or PhD)? :)
>

Paragraph 13.4 subsection (B)(iv) of the LAMN bylaws allows earned degrees,
but only if you had to take at least one really boneheaded class.  You get
to define boneheaded.


> also, what if you have meaningless cert letters after your name, but
> only because of peer pressure? are we still allowed to join? :)
>

That's between you and the deity or non-deity of your choice :-)

--Jeremy
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

[SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs

[Jeremy Epstein]

Colleagues,

I'm pleased to announce the creation of LAMN, the Legion Against Meaningless
certificatioNs.  If you don't have a CISSP, CISM, MCSE, or EIEIO - and
you're proud of it - this group is for you.

You can join LAMN on LinkedIn by searching in the "groups" area.  Unlike so
many other certifications, LAMN doesn't charge fees, require outrageously
overpriced exams, or demand check-the-box continuing education.

Hope to see many people joining this group - and feel free to pass this
along!
--Jeremy

P.S. After you join the group, you can proudly write your name ,
LAMN - which conveniently also stands for Letters After My Name.  I can't
recall who suggested the term to me, but would be happy to give credit if
someone wants to step forward and claim credit.
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

[SC-L] Goodbye to faulty software?

[Jeremy Epstein]

Saw this article:
http://cordis.europa.eu/ictresults/popup.cfm?section=news&tpl=article&ID=89864&AutoPrint=True,
and was wondering if anyone on this list knows anything about the
project
or Dr Bengt Nordström at Chalmers University in Göteborg Sweden.  Sounds to
me like they're reinventing all the old formal methods / provable code stuff
- but perhaps I'm wrong.  Thoughts?

--Jeremy
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

[SC-L] Catching up, and some retrospective thoughts

[Jeremy Epstein]

I've just caught up with 6 weeks of backlogged messages in this group,
and wanted to offer some thoughts on topics that have been hashed out,
but haven't seen these points made.

(1) SOX is a waste, as several people said, because it's just a way to
give auditors more ways to demand irrelevant things on checklists - but
not to pay attention to actual security.  I've had customers demand that
I support AES because their auditors says "SOX requires it", while
meanwhile having unchanged default passwords.  Another customer demanded
that we support 6144 bit RSA keys (no, that's not a typo) because "SOX
requires it".  Neither customer asked anything about software security -
just about the check boxes on the auditor's list.  Ask people to go
*read* SOX, and they'll be surprised what it actually says (or more
accurately, doesn't say).

(2) PCI, by contrast, is dramatically better, because it's got actual
things you can measure, and some of them have some relevance to software
security.  However, it's having an effect that I think was unintended by
the folks who wrote it (or at least the ones I met at a recent
conference) - merchants are pushing the requirements down to all of
their suppliers, regardless of whether they're applicable.  So, for
example, we have to certify that we treat all credit card information in
the required way - even though we don't ever get credit card numbers.
[This is a requirement that might make sense for a merchant to push to
an outsourced processor, but not to a software supplier.  Can you
certify that Windows or Linux handles credit card numbers correctly?]

(3) Vendors do what their customers ask for.  If my customers ask for
better security, we'll put our engineering resources into improving
security - just as Microsoft has done.  If our customers ask for more
whizbang cool GUIs, that's where we'll put our effort.  We *know* that
the products aren't as secure as they could be (and perhaps should be) -
but as a business, we respond to our customers.  I hear what customers
are asking for, and when it comes to enterprise software, the top three
priorities are features, more features, and yet more features.  And we
actually have a metric for whether we're investing in the right places:
how often do we lose deals because of missing features (security or
otherwise) vs. security assurance (i.e., software security).  [Of course
there are other reasons for losing deals too, like price, long term
vision, company reputation, etc., but I'm focusing on the software
ones.]  When the balance of where we lose deals changes, we change our
investments.

As always, my opinions, which don't necessarily represent the views of
my employer, or Alberto Gonzales or anyone else tapping my phone.

--Jeremy

Jeremy Epstein
Senior Director, Product Security & Performance
P 703.460.5852 | C 703.989.8907 | F 703.460.2599 | W 202.456.
AIM jeremyepstein | Skype jjepstein
www.webMethods.com

___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] FW: Good Magazines and Books

[Jeremy Epstein]

Having lurked on this list for a while, I'll chime in.

The answer depends on what you're trying to learn.  If your goal is latest
thinking, concepts, etc., I agree with GEM that IEEE S&P is best.  If you
want to know about the latest products, what's going on in the market, try
Information Security magazine (infosecuritymag.techtarget.com).  If you want
to know what CSOs are worrying about (not just computer/network security,
but also physical security, personnel security, etc.) see CSO Magazine
(www.csoonline.com).  I'm sure there are other "bests" depending on what
your goal is.

So the answer is: it depends.

As for books (the second part of the question), again, it depends on what
you're interested in.  As a selection, I like Ross Anderson's "Security
Engineering" as a basic text that covers a bit of everything, and Matt
Bishop's text is encyclopedic.  Of course GEM's books are excellent choices
for understanding software aspects of security.  Chris Wysopal's new testing
book is excellent.  And Ken van Wyk has a great handbook on secure coding
practices.  [Kudos to GEM, Chris, and Ken for not flogging their own books -
since I don't have a book, I'll feel free to flog theirs.]  There are many
other great books, but you've got to narrow the topic a bit!

--Jeremy
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] darkreading: voting machines

[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

Re: [SC-L] "Bumper sticker" definition of secure software

[Jeremy Epstein]

I like the idea of a bumper sticker slogan for the same reason as "elevator
pitches" are useful - they don't cover everything, and they don't try to be
precise - just give enough information to whet the reader's/listener's
appetite.

And with that, I offer the following:

"Software Security Keeps the Bad Guys Out"

No, it's not precise - it doesn't define bad guys, doesn't say anything
about intent, etc.  But it's something people (even CEOs) can understand,
and it provides the motivation for a potential purchaser of software
security technology.

--Jeremy
___
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

RE: [SC-L] RE: Comparing Scanning Tools

[Jeremy Epstein]

Title: Re: [SC-L] RE: Comparing Scanning Tools



At the RSA Conference in February, I went to a reception 
hosted by a group called "Secure Software Forum" (not to be confused with 
the company Secure Software Inc, which offers a product competitive to 
Fortify).  They had a panel session where representatives from a couple of 
companies not in the software/technology business claimed that they're making 
contractual requirements in this area (i.e., that vendors are required to assert 
as part of the contract what measures they use to assure their code).  So I 
guess there's proof by construction that companies other than Microsoft & 
Oracle care.
 
Having said that, it's completely at odds compared to what 
I see working for an ISV of a non-security product.  That is, I almost 
never have prospects/customers ask me what we do to assure our software. If it 
happened more often, I'd be able to get more budget to do the analysis that I 
think all vendors should do :-(
 
--Jeremy
 
P.S. Since Brian provided a link to a press release about 
Oracle using Fortify, I'll offer a link about a financial services company using 
Secure Software: http://www.securesoftware.com/news/releases/20050725.html

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James F 
  (HTSC, IT)Sent: Friday, June 09, 2006 12:10 PMTo: Secure 
  Mailing ListSubject: RE: [SC-L] RE: Comparing Scanning 
  Tools
  
  I 
  think I should have been more specific in my first post. I should have phrased 
  it as I have yet to find a large enterprise whose primary business isn't 
  software or technology that has made a significant investment in such 
  tools.
   
  Likewise, a lot of large enteprrises are shifting 
  away from building inhouse to either outsourcing and/or buying which means 
  that secure coding practices should also be enforced via procurement 
  agreements. Has anyone here ran across contract clauses that assist in this 
  regard?
  
-Original Message-From: Gunnar Peterson 
[mailto:[EMAIL PROTECTED]Sent: Friday, June 09, 2006 8:48 
AMTo: Brian Chess; Secure Mailing List; McGovern, James F (HTSC, 
IT)Subject: Re: [SC-L] RE: Comparing Scanning 
ToolsRight, because their customers (are starting to) 
demand more secure code from their technology. In the enterprise space the 
financial, insurance, healthcare companies who routinely lose their 
customer’s data and provide their customers with vulnerability-laden apps 
have not yet seen the same amount of customer demand for this, but 84 
million public lost records later ( http://www.privacyrights.org/ar/ChronDataBreaches.htm) 
this may begin to change.-gpOn 6/9/06 1:45 AM, "Brian 
Chess" <[EMAIL PROTECTED]> wrote:
McGovern, James F wrote:> I have yet to 
  find a large enterprise that has made a significant investment in such 
  tools. I’ll give you pointers to two.  They’re two of the 
  three largest software companies in the world.http://news.com.com/2100-1002_3-5220488.htmlhttp://news.zdnet.com/2100-3513_22-6002747.htmlBrian
  
  ___Secure 
  Coding mailing list (SC-L)SC-L@securecoding.orgList information, 
  subscriptions, etc - http://krvw.com/mailman/listinfo/sc-lList 
  charter available at - http://www.securecoding.org/list/charter.php*This 
  communication, including attachments, isfor the exclusive use of addressee 
  and may contain proprietary,confidential and/or privileged information. If 
  you are not the intendedrecipient, any use, copying, disclosure, 
  dissemination or distribution isstrictly prohibited. If you are not the 
  intended recipient, please notifythe sender immediately by return e-mail, 
  delete this communication anddestroy all 
  copies.*
___
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

RE: [SC-L] ZDNET: LAMP lights the way in open-source security

[Jeremy Epstein]

All of which proves that there are lies, damn lies, and statistics (the
statistic being the lower bug density, which ignores the most potentially
vulnerable parts of the system). 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Gavin, Michael
> Sent: Tuesday, March 07, 2006 11:49 AM
> To: Kenneth R. van Wyk; Secure Coding Mailing List
> Subject: RE: [SC-L] ZDNET: LAMP lights the way in open-source 
> security 
> 
> The Coverity product (Coverity Prevent) is a static source 
> code analysis tool for C and C++, see 
> http://www.coverity.com/library/pdf/coverity_prevent.pdf.
> 
> It isn't actually scanning (or if it is, it isn't analyzing) 
> any of the scripting code, as far I as can tell.
> 
> Michael
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth R. van Wyk
> Sent: Tuesday, March 07, 2006 10:56 AM
> To: Secure Coding Mailing List
> Subject: [SC-L] ZDNET: LAMP lights the way in open-source security 
> 
> Interesting article out on ZDNet today:
> 
> http://www.zdnetasia.com/news/security/0,39044215,39315781,00.htm
> 
> The article refers to the US government sponsored study being 
> done by Stanford University, Symantec, and Coverity.  It 
> says, "The so-called LAMP stack of open-source software has a 
> lower bug density--the number of bugs per thousand lines of 
> code--than a baseline of 32 open-source projects analyzed, 
> Coverity, a maker of code analysis tools, announced Monday."
> 
> This surprised me quite a bit, especially given LAMP's 
> popular reliance on scripting languages PHP, Perl, and/or 
> Python.  Still, the article doesn't discuss any of the root 
> causes of the claimed security strengths in LAMP-based code.  
> Perhaps it's because the scripting languages tend to make 
> things less complex for the coders (as opposed to more 
> complex higher level languages like Java and C#/.NET)?  Opinions?
> 
> Cheers,
> 
> Ken
> --
> Kenneth R. van Wyk
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> 
> ___
> 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
> 
___
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

RE: [SC-L] Question about the terms "encypt" and "secure"

[Jeremy Epstein]

Encryption is one way to secure the *transport* on the network (subject to
various caveats about appropriate use of crypto, trust issues, etc.).  I'd
strongly disagree with anyone who says that encryption "makes a network
secure" - because people interpret that to mean "if I encrypt the network, I
don't need to do anything else".  In fact, there's lots of other things you
need to do, such as authenticating the actions, ensuring you have adequate
audit trails, ensuring that there are no security vulnerabilities, etc.
Some people consider that to be host security as a separate topic, and so
for them, encryption *does* secure the network.  But I get nervous when
someone says encryption secures the network, lest it be considered as an
excuse to ignore all the other problems.

WRT the Marine Guards approach, years ago another approach was to run cables
through pressurized conduits with sensors to detect if anyone tampered with
the conduit before they could tap into the line.  No idea if this is still
done, or if there are new attacks possible (e.g., measuring the power
leakage from the conduits).  At that time, "Orange Book" evaluations weren't
allowed to rely on cryptography as a security measure, so a network
evaluation I worked on suggested using the Marine Guards approach.  Not that
we expected anyone to do it, but it was the only way to get past the
ridiculous requirement...

--Jeremy

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of ljknews
> Sent: Monday, March 06, 2006 8:00 AM
> To: Secure Coding Mailing List
> Subject: Re: [SC-L] Question about the terms "encypt" and "secure"
> 
> At 12:35 PM -0500 3/5/06, William L. Anderson wrote:
> 
> > My question is whether it's more accurate to say "secure 
> their network"
> > rather than "encrypt". I'm not clear myself about the 
> meaning of these 
> > terms; I think of encryption as being one way to make a 
> network secure.
> 
> Another way that was described some years ago was Marine 
> Guards every 5 feet down the Thick Ethernet cable to prevent 
> unauthorized taps.  Of course that was by someone in the 
> cryptographic business :-)
> --
> Larry Kilgallen
> ___
> 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

RE: [SC-L] Managing the insider threat through code obfuscation

[Jeremy Epstein]

Ken,

I looked into this a couple of years ago to protect against intellectual
property theft (e.g., reverse engineering) and to make it harder to bypass
software licensing techniques.  My conclusion at that point was that the
obfuscation didn't actually do much good (it was still fairly easy to figure
out what was going on).  It introduced an extra risky step - our developers
want to do their debugging/QA on unobfuscated versions so they can figure
out what goes wrong, but you then have to replicate all of your QA on the
obfuscated version to make sure that the obfuscator didn't break anything.
[I hope that no one would test one version and release another!]  And if
there was a discrepancy, it was likely to be difficult to find what went
wrong.

Most importantly for us, it made support a royal pain - stack traces no
longer meant anything.  And we had to be *very* careful not to obfuscate any
published or undocumented-but-known interfaces.

My conclusion is that it's better than just marketing hooey - there is some
technical advantage - but that if you have an extensible product and/or you
have to provide support, the pain is worse than the advantage.

--Jeremy

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth R. van Wyk
> Sent: Thursday, December 15, 2005 8:59 AM
> To: Secure Coding Mailing List
> Subject: [SC-L] Managing the insider threat through code obfuscation
> 
> This morning, an article caught my attention -- "Managing the 
> insider threat through code obfuscation",
> http://www.itmanagersjournal.com/article.pl?sid=05/12/13/1736253
> 
> The article's premise is that, because attackers can find out 
> a great deal about the internals of databases and such by 
> decompiling bytecode (in Java and .NET), bytecode should be 
> obfuscated to hide its internal details.  The article points 
> to several commercial bytecode obfuscation products: 
> http://www.devdirect.com/ALL/OBFUSCATIORS_PCAT_2014.aspx
> 
> I hadn't heard of this approach before, although I'm quite 
> familiar with how easy it is to decompile Java bytecode.  My 
> questions for the group are:
> 
> o Anyone here have any good/bad experiences with bytecode obfuscation?
> o What is the impact on performance of the bytecode?
> o How about compatibility with various JVMs?
> o How much protection do these obfuscators really provide?
> o Is this all just a bunch of product marketing hooey?
> 
> Well, at least the article uses the term "threat" correctly...
> 
> Cheers,
> 
> Ken van Wyk
> ---
> KRvW Associates, LLC
> http://www.KRvW.com
> ___
> 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

RE: [SC-L] ZDNet: Attackers switching to applications, media play ers

[Jeremy Epstein]

Also reported in the Washington Post today:
http://www.washingtonpost.com/wp-dyn/content/article/2005/11/21/AR2005112101
424.html?sub=AR (regisration required).  The Post isn't known for their
technology coverage; perhaps it's because SANS is local.

--Jeremy 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth R. van Wyk
> Sent: Tuesday, November 22, 2005 11:06 AM
> To: Secure Coding Mailing List
> Subject: [SC-L] ZDNet: Attackers switching to applications, 
> media players
> 
> FYI, interesting article on ZDNet today citing a SANS study.  
> The article says, among other things, "Online criminals 
> shifted their attacks in 2005 from operating systems such as 
> Windows to media players and software programs, according to 
> a study released Tuesday."
> 
> If the study's findings are correct, then it places an 
> emphasis on organizations' software security efforts.  IMHO, 
> it's certainly not about "the perimeter" anymore (if it ever 
> really was).
> 
> Cheers,
> 
> Ken
> 
> P.S. On a list administrative front, it appears that the 
> Mailman list manager seems to be working pretty well for us.  
> One significant change that could impact you subscribers is 
> that I've configured Mailman to discard incoming messages 
> from anyone that is not subscribed to SC-L.  So, if you use a 
> local mail alias to read your SC-L, you might have 
> difficulties submitting messages to the group. If that's the 
> case, just drop me a note and I'll step you through setting 
> things up so that your submissions don't get discarded.  (The 
> discarding has done wonders for reducing the amount of spam 
> in my life.)
> 
> --
> Kenneth R. van Wyk
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> 
> ___
> 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

RE: [SC-L] certification for engineers/developers?

[Jeremy Epstein]

The Great Australian Ice Creamery might be as effective as CISSP for
software engineers.  I was wondering whether it was accidental or
intentional that Ed Rohwer suggested "defiantly" looking at CISSP.
Defiantly: "in a rebellious manner" or "boldly resisting".

[Ed. Thanks for the laugh, Jeremy! KRvW]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Rucker Jones
> Sent: Tuesday, March 22, 2005 11:11 PM
> To: sc-l@securecoding.org
> Subject: RE: [SC-L] certification for engineers/developers?
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> You mean of course GIAC (www.giac.org and www.sans.org), not 
> GAIC. That is, unless You really want a security 
> certification from the Great Australian Ice Creamery 
> (www.gaic.com.au).
> 
>   -&
> 
> 
> -  Original Message 
> Subject: RE: [SC-L] certification for engineers/developers?
> Date: Tue, 22 Mar 2005 13:43:54 -0700
> From: Edward Rohwer <[EMAIL PROTECTED]>
> Reply-To: Edward Rohwer <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>, 
> 
> Depending on where you want to go, defiantly look at the 
> CISSP, or one of the GAIC cert.'s Software "engineering" is 
> another subject entirely. Some people (a lot actually) would 
> argue that SE's are not engineers at all, since they are not 
> licensed by states or other governmental agencies like EE's 
> or other professional engineers.
> 
> Ed. Rohwer CISSP
> 
> - -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of j eric townsend
> Sent: Tuesday, March 22, 2005 12:18 PM
> To: sc-l@securecoding.org
> Subject: [SC-L] certification for engineers/developers?
> 
> A lot of people I know in IT are picking up certifications 
> and I'm wondering if there's any equivalent for software 
> engineers or product security
> engineers.I have vague memories of  QE/QA certifications for ISO
> compliance, but a quick perusal of google and yahoo turns up 
> nothing for security engineers.
> 
> The main reason I'm looking at certification is defensive -- 
> I've been in one too many meetings where someone's opinion 
> was given more weight because
> of industry certification or advanced degree.  As product 
> security and
> secure development gets more visibility in organizations, 
> conflicts with IT (and other groups) start to happen over 
> things like trusted development
> environments and product vulnerability escalation paths. 
> It seems like
> everyone in IT  has some sort of certification these days, 
> and the certifications are sold to upper management as a 
> method of knowing your employees have a certain level of knowledge.
> 
> Of course, none of us in engineering have certifications.   
> Those of us with
> formal education have degrees from a long time ago in an 
> academic world very far away.
> 
> Being the sort who'd rather not bring a knife to a gun fight, 
> I figure I
> should start getting myself some walllpaper as well.   Maybe 
> I should just
> sit for the CISSP, or maybe get something like Sun's JCP or 
> the IEEE CSDP
> and be done with it?   Or maybe go the academic route and get 
> a MS in CS?
> - --
> [EMAIL PROTECTED]
> 
> pgp: 0xF5F84C8F, 7405 0143 B665 303D D2E8  4257 95AD F02F F5F8 4C8F
> 
> 
> 
> 
> - --
> GPG key / Schlüssel -- http://simultan.dyndns.org/~arjones/gpgkey.txt
> Encrypt everything. / Alles verschlüsseln.
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFCQOw2oI7tqy5bNGMRAn9xAKDSjlw0TMxYlkam3K9Ke8n0YnlX9gCfd1nM
> vuVX94hrJPFnyB174BnyuX4=
> =vHL/
> -END PGP SIGNATURE-
> 
> 
> 

RE: [SC-L] Top security papers

[Jeremy Epstein]

There's lots of interesting papers; I couldn't begin to select a "top 10".
But for an answer to this question from the late 90s, take a look at the UC
Davis collection available at
http://csrc.nist.gov/publications/history/index.html

Also a plug: every year the Annual Computer Security Applications Conference
(www.acsac.org) invites two or three authors of seminal papers to update &
present their papers given the benefit of hindsight.  Last year's papers
included an update by Gene Spafford on the dissection of the Morris Worm,
and an update from Peter Neumann on PSOS (Provably Secure Operating System).
This year we'll hear a retrospective on the Orange Book by Marv Schaefer
(one of the authors) and an update on some of the classic TCP attacks from
Steve Bellovin.

--Jeremy

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> Behalf Of Matt Setzer
> Sent: Saturday, August 07, 2004 9:42 PM
> To: [EMAIL PROTECTED]
> Subject: [SC-L] Top security papers
> 
> 
> It's been kind of quiet around here lately - hopefully just 
> because everyone
> is off enjoying a well deserved summer (or winter, for those 
> of you in the
> opposite hemisphere) break.  In an effort to stir things up a 
> bit, I thought
> I'd try to get some opinions about good foundational 
> materials for security
> professionals.  (I'm relatively new to the field, and would 
> like to broaden
> my background knowledge.)  Specifically, what are the top five or ten
> security papers that you'd recommend to anyone wanting to 
> learn more about
> security?  What are the papers that you keep printed copies 
> of and reread
> every few years just to get a new perspective on them?  
> 
> 
> Amoroso has a list of selected papers in an appendix to 
> "Fundamentals of
> Computer Security Technology" (sorry, haven't been able to 
> find a web link),
> but I'm interested in hearing other perspectives, as well as 
> hearing about
> newer papers that have excited people.   Any thoughts?
> 
>  
> 
> Matt Setzer
> 

RE: [SC-L] Programming languages -- the "third rail" of secure co ding

[Jeremy Epstein]

Kevin Wall pointed to http://www2.latech.edu/~acm/HelloWorld.shtml as a good
source point; several of the languages I programmed in aren't listed (e.g.,
PL/360, which in many respects was to the IBM 360 as C was to the PDP/11).
Throughout the 1970s (and maybe even 1980s) a researcher named Jean Sammet
at IBM published a yearly list of what claimed to be all the programming
languages in use.  See
http://www.computerhistory.org/events/hall_of_fellows/sammet/ for more about
her.

To relate this to security, I "discovered" the concept of a buffer overrun
when writing PL/360 code back in 1978.  Languages that lack strong typing,
like PL/360 and C, clearly have a harder time being secure than those that
aren't.  And that's true of reliability as well.

So perhaps such a list would be interesting if one identified the
characteristics that make a language "good" from a security perspective
(several such lists have been posted to this list), and then correlate it to
some of the very long lists of languages.  That would at least give a
starting point for a discussion of "best"

IMHO, though, any such effort is pointless.  The reality is that we're going
to be stuck with C/C++, Java, C#, FORTRAN, COBOL, and various
interpreted/scripting languages for a very long time.  Rather than argue
about what makes something good/better, we'd be better off figuring out how
to use them more effectively.

As engineers, we need "good enough", not perfection.

RE: [SC-L] Programming languages used for security

[Jeremy Epstein]

der Mouse is correct.  I recall a product from the early 80s called "The
Last One".  There was an advertisement for the product on Prof Doug Comer's
door when I was a grad student at Purdue... the claim was that this product
made designing applications so simple that you'd never have to program
again.  I'm sure you're all familiar with this product, since it made your
lives obsolete.

And it would have succeeded, if the Mafia hadn't hushed it up along with
Jimmy Hoffa's death.

One of the buzzwords du jour is "model driven architectures" (MDA); OMG has
a working group on it (http://www.omg.org/mda/).  It's just the latest
iteration in what der Mouse called "very-high-level languages".  It has the
same promises as we've heard by countless iterations of abstractions
faster development, fewer bugs, less need for programmers, etc.  I'm
skeptical.

Getting back to the point at hand, though, I think this discussion is
confusing two related topics: languages that help you build code that
doesn't have security implementation bugs, and languages that help you build
code that doesn't have security design flaws.  [Gary McGraw pushes the
difference between bugs & flaws, and I agree.]  Example: Java helps you
avoid a lot of the common *bugs* (by doing some things automatically like
bounds checking, and providing libraries to do other things correctly like
cryptography], but can't do much to help you avoid misdesigning the
software.  I think we're getting pretty good (relatively speaking) at
building languages for bug-free code, but much less so for flaw-free code.

To me, that's the *real* potential of the very-high-level languages... if
things can be brought up to a point where the design becomes more obvious
(since the implementation becomes somewhat automated), then there's a better
chance of finding the security design problems.

On the other hand, the problem with abstracting too much is that the
security problems can get swept under the rug.

To get REALLY back to the point, I'd like to comment on Fabien's comment
that "In my opinion, it's the most important things for a languages,
something to easily validate user input or to encrypt password are a must
have."  Fabien is right, but increasingly that's only half the problem.
There also needs to be something in the libraries for the language to
securely store data that can't be one-way hashed, as are (inbound)
passwords.  For example, if I need to store the password my application
needs to authenticate to a database, or other critical data, it would be
nice to have that built into the language libraries, instead of having to
build it myself.  It would certainly reduce the number of programmers who
build such storage mechanisms themselves, and insecurely at that.

My $0.02 or equivalent in local currency.

--Jeremy

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> Behalf Of der Mouse
> Sent: Friday, July 09, 2004 4:18 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [SC-L] Programming languages used for security
> 
> 
> > 2. Do we need programming languages at all?  Why not write precise
> > high-level specifications and have the system generate the program,
> > thereby saving time and eliminating coding error?
> 
> Then the "high-level specification" _is_ the programming language,
> albeit a relatively unusual one, with the thing you call "the system"
> being what is normally called the language's compiler.
> 
> Such very-high-level languages are a perennial idea.  As you 
> point out,
> they aren't always appropriate, but when they are they can be helpful.
> But they don't eliminate programming, any more than COBOL (which was
> supposed to make it possible to write programs in plain English and
> thereby eliminate programming as a skill) did.  And they won't
> eliminate coding error.  They'll eliminate certain classes of coding
> error, just as assembly does as compared to machine language, or as C
> or Pascal does as compared to assembly language - but coding errors
> will still occur, just as they do in assembly or C.  They'll just be
> errors at or above the level at which the code is written.
> 
> Or, of course, they'll due to be bugs in the compiler.
> 
> /~\ The ASCII der Mouse
> \ / Ribbon Campaign
>  X  Against HTML [EMAIL PROTECTED]
> / \ Email! 7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
> 
> 

RE: [SC-L] Re: White paper: "Many Eyes" - No Assurance Against Ma ny Spies

[Jeremy Epstein]

Crispin said:
> But taking the remark seriously, it says that you must not trust 
> anything that  you don't have source code for. The point of 
> Thompson's 
> paper is that this includes the compiler; having the source 
> code for the 
> applications and the OS is not enough, and even having the source for 
> the compiler is not enough unless you bootstrap it yourself.

Ken Thompson's point is that the *source* is not enough... maybe you mean to
say "it says that you must not trust anything that you don't fully
understand".

> Extrapolating from Thompson's point, the same can be said for 
> silicon: 
> how do we know that CPUs, chipsets, drive controllers, etc. 
> don't have 
> Trojan's in them? Just how hard would it be to insert a funny 
> hook in an 
> IDE drive that did something "interesting" when the right 
> block sequence 
> comes by.

In fact, there have been cases where the software was correct, but the
hardware was implemented incorrectly in a way that subverted the software
protections.  I found a bug 20 years ago in a microprogrammed disk
controller that under particular circumstances would cause it to write one
sector more than was specified... once can certainly hypothesize something
like that being deliberate (it was, I believe, accidental).  And I was told
about a particular Orange Book A1-targeted system where they discovered
during development that a hardware bug led all of their "provably secure"
code to be totally insecure.

[...]

> The horrible lesson from all this is that you cannot trust 
> anything you 
> do not control. And since you cannot build everything yourself, you 
> cannot really trust anything. And thus you end up taking calculated 
> guesses as to what you trust without verification. Reputation 
> becomes a 
> critical factor.

Again, this is almost but not quite correct... it's not just "anything you
do not control", but "anything you do not fully understand and control".
It's not good enough to have the source code and the chip masks, if you
don't also understand what the source code and chip masks mean, and have
confidence through your personal electron microscope that you also built
that the chip you're running is an implementation of the mask, etc.  And at
some level you have to trust the atomic physicists who explain how molecules
& atoms interact to cause the stuff on the chip to work.

> It also leads to the classic security analysis technique of amassing 
> *all* the threats against your system, estimating the probability and 
> severity of each threat, and putting most of your resources 
> against the 
> largest threats. IMHO if you do that, then you discover that 
> "Trojans in 
> the Linux code base" is a relatively minor threat compared to "crappy 
> user passwords", "0-day buffer overflows", and "lousy 
> Perl/PHP CGIs on 
> the web server". This Ken Thompson gedanken experiment is fun for 
> security theorists, but is of little practical consequence to 
> most users.

Absolutely true.  This is one of the great frustrations to me... I get
complaints from customers on occasion that they don't like one security
feature or another, and that it absolutely *must* be changed to meet their
security requirements... all the while not changing the out-of-the-box
administrator password.  We need to spend more time learning about risk
assessment, and teaching how to use it effectively to get "good enough"
security.

--Jeremy

RE: [SC-L] Re: White paper: "Many Eyes" - No Assurance Against Many Spies

[Jeremy Epstein]

I agree with much of what he says about the potential for infiltration of
bad stuff into Linux, but he's comparing apples and oranges.  He's comparing
a large, complex open source product to a small, simple closed source
product.  I claim that if you ignore the open/closed part, the difference in
trustworthiness comes from the difference between small and large.  That is,
if security is my concern, I'd choose a small open source product over a
large closed source, or a small closed source over a large open source... in
either case, there's some hope that there aren't bad things in there.

Comparing Linux to his proprietary system is just setting up a strawman.
of course the fact that he's selling something that conveniently replaces
the strawman he knocks down is simply a coincidence

--Jeremy

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> Behalf Of [EMAIL PROTECTED]
> Sent: Thursday, April 29, 2004 2:32 PM
> To: Kenneth R. van Wyk
> Cc: [EMAIL PROTECTED]
> Subject: [SC-L] Re: White paper: "Many Eyes" - No Assurance 
> Against Many
> Spies
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Kenneth R. van Wyk wrote:
> 
> >FYI, there's a white paper out by Dan O'Dowd of Green Hills 
> Software (see 
> >http://www.ghs.com/linux/manyeyes.html) that "It is trivial 
> to infiltrate the 
> >loose association of Linux organizations which have 
> developers all over the 
> >world, especially when these organizations don't even try to prevent 
> >infiltration, they accept code from anyone."
> 
> And he's selling us the solution, how convenient. :\  Hmm.
> 
> Leaving aside the couple of obvious problems with this essay's
> arguments, I'll note that some of the author's points are valid.  It
> puzzles me that many otherwise security-conscious people have 
> no qualms
> downloading and installing whatever they fancy with little thought to
> the source or the author's motives.  It is indeed a pretty 
> loose network
> which supports much of what we know as GNU/Linux.  That is 
> less true of
> FreeBSD and even less of OpenBSD.
> 
> - -d
> 
> - -- 
> David Talkington
> [EMAIL PROTECTED]
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFAkUoT5FKhdwBLj4sRAluEAJ4oaUqtTrKPsOpaTiRJ9vycDhlwMACgo6D3
> M/i6mUw7n6wm2c64aBIaPwk=
> =NAeE
> -END PGP SIGNATURE-
> 
> 

RE: [SC-L] Anyone looked at security features of D programming language compared to Spark?

[Jeremy Epstein]

Jim & Mary Ronback opined:
> I am hard put to find an example of a language feature which makes a 
> system more secure but less safe or vice versa, in any context. Can 
> anyone else think of one?

Not 100%, but consider automatic garbage collection.  Tends to make a system
more secure, because it's associated with languages that avoid pointers with
all their evilness.  Tends to make a system less safe, because if the
garbage collection occurs at the wrong time (e.g., when you're spitting out
radiation for a medical instrument), it could cause the system to
temporarily freeze.

--Jeremy

RE: [SC-L] virtual server - IPS

[Jeremy Epstein]

Not to digress too far, but...

> On 3/31/04 10:05 AM, "Jeremy Epstein" 
> <[EMAIL PROTECTED]> wrote:
> > You might also consider one of the IPS products (e.g., Okena/Cisco,
> > Entercept/NAI, or PlatformLogic), all of which will allow 
> you to constrain
> > what happens and may be somewhat more scalable than 
> VMware if you need
> > to run a bunch of instances of the virtual environment.

Paco Hope responded: 
> This answer decidedly beyond the scope of "secure coding."  
> IPSes don't even
> run on the host with the code. IPS systems are so far removed from the
> actual host that they have no context on which to base decisions about
> custom code. The OS can't stop bad programmers from shooting 
> themselves in
> the foot. It can at least apply a few limits to the damage 
> when they do.

There are different kinds of IPSs (unfortunately, the term is massively
overloaded).  The types I listed run on the host with the code, in between
the OS and the application.  And they *do* have the context to base
decisions on...  I'm most familiar with PlatformLogic, which provides a very
sophisticated policy language that allows you to specify for every program
exactly what it can do (e.g., what files it can access in what modes, what
ports it can use, what IP addresses), as well as privileged systems calls,
etc.  It's ideally suited to constraining virtual servers.

Yes, there are IPSs that are running on the network (e.g., as a network
filter), but those are more network IPSs (as opposed to host IPSs), to
borrow terminology from the IDS world.

> The original question was "how can I limit one user's ability 
> to interfere
> with other users on the box?"  An answer that takes the box 
> offline when bad
> stuff happens is probably not the answer he was hoping for.  It's a
> host-based question, and the network is not the right place 
> to solve it.

I agree.  The solution I propose does not take the box offline; depending on
how the IPS is configured, it would either disallow the particular
operation, or shut down that virtual server (without affecting other virtual
servers).

--Jeremy

RE: [SC-L] virtual server - security

[Jeremy Epstein]

You might also consider one of the IPS products (e.g., Okena/Cisco,
Entercept/NAI, or PlatformLogic), all of which will allow you to constrain
what happens and may be somewhat more scalable than VMware if you need
to run a bunch of instances of the virtual environment.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> Behalf Of Scott Nemec
> Sent: Tuesday, March 30, 2004 6:46 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [SC-L] virtual server - security
> 
> 
> Have you looked at VMware?  ( http://www.vmware.com )
> 
> It let's you provide an environment at the hardware-like 
> level inside a
> real box.  This way, if the the script kiddie get's control of your
> virtual environment, you can just reset back to a pre-saved state.
> Meanwhile, the real box is protected from the virtual (at least should
> be).
> 
> On Tue, 30 Mar 2004, Serban Gh. Ghita wrote:
> 
> > Hello
> >
> > I am banging my head on the table every day, because i 
> cannot find an
> > elegant and safe solution to secure a virtual shared 
> environment (server).
> > Take the following facts:
> > -you have a virtual server (unix) and you have to take care 
> of a lot of
> > clients.
> > -no one has acces to shell, cronjobs or stuff like that, 
> only 21 and 80
> > -you dont want anyone to get out of his 'box' (eg /home/sasha/)
> > -you want to allow php, perl or other web languages to run 
> safely and in the
> > same time will _almost_ all features.
> > -in php (because this is the one of the most user language 
> for web - for
> > mostly endusers), i have options like safe_mode, but if i 
> activate that,
> > many functions and features will not work. i know (because 
> i tested) that
> > the best solution is open_basedir, but i cannot create an 
> restriction like
> > that for each user, or at least i dont know how to do that.
> >
> > My problem is that i tested some script-kiddies local 
> exploits (php,perl)
> > and the system is vulnerable, the user can get out of his 
> box and see system
> > files (etc/passwd, other dirs).
> >
> > What are the options here. Any paper or book written about this?
> >
> > Thanks
> >
> > Serban Gh. Ghita
> >
> >
> >
> 
> 

RE: [SC-L] Re: Java sandboxing not used much

[Jeremy Epstein]

I agree with Ches, but need to mention that it's not always that simple.  I
offered my customers (as a no-cost feature) a Java sandbox file for our Java
server product... no one wanted it.  So it wasn't worth the effort to
develop/maintain.

While it's true that we need to make things simpler to use, we *also* need
to motivate users to take advantage of the security features we provide.  If
they don't see the value in using the sandbox.conf, then it won't be used,
even if it only requires a minimal effort.

--Jeremy

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> Behalf Of Bill Cheswick
> Sent: Thursday, March 11, 2004 3:04 PM
> To: [EMAIL PROTECTED]
> Subject: [SC-L] Re: Java sandboxing not used much
> 
> 
> > Complex security systems are often completely ignored.
> 
> This is definitely a problem with with more-involved security systems.
> At one point I obtained a system that had obtained B1 certification
> to implement a firewall.  The firewall worked fine, but I never
> got the hang of the system administration for the damn thing.
> 
> User client-level applications should come with recommended 
> sandbox.conf
> files that will contain them appropriately.  There's already 
> a shortage
> of systems and network security people, and this stuff should be as
> easy as possible.  
> 
> ches
> 
>