Re: [SC-L] SC-L Digest, Vol 6, Issue 56

2010-03-20 Thread ljknews
At 7:56 PM +0200 3/19/10, AK wrote:

 It is way easier for attackers to reverse engineer desktop applications
 than web applications. Assuming proper server configuration, it is next
 to impossible for an attacker to get the server side source code or
 compressed form (e.g WARs) for a web application and proceed with
 disassembly/decompilation/patching.

Assuming proper _desktop_ configuration, the user does not have
the ability to modify the programs they will execute, nor change
the protections of objects on the system.

http://nvd.nist.gov/fdcc/fdcc_faq.cfm

Yes, physical access to a computer means ultimately it is possible
to gain control, but the necessary measures to not constitute
easier, and given control of one test machine it is not at all
trivial to transfer that to control of another machine, especially
if the machines are not connected to a common network.
-- 
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
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] market for training CISSPs how to code (Matt, Parsons)

2010-03-18 Thread ljknews
At 7:36 PM +0200 3/18/10, AK wrote:

 Who says so, in the context of web applications?
 I can see it (somewhat) from a desktop application
 perspective, but how is this relevant in web apps?

Why should standards for a web application be different than
for a desktop application ?
-- 
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
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] 2010 bug hits millions of Germans | World news | The Guardian

2010-01-07 Thread ljknews
At 10:43 AM -0600 1/7/10, Stephen Craig Evans wrote:

 I am VERY curious to learn how these happened... Only using the last
 digit of the year? Hard for me to believe. Maybe it's in a single API
 and somebody tried to be too clever with some bit-shifting.

My wife says that in the lead-up to the year 2000 she caught
some programmers fixing Y2K bugs by continuing to store
year numbers in two digits and then just prefixing output
with 19 if the value was greater than some two digit number
and prefixing output with 20 if the value was less than or
equal to that two digit number.

Never underestimate programmer creativity.

Never overestimate programmer precision.
-- 
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
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] 2010 bug hits millions of Germans | World news | The Guardian

2010-01-07 Thread ljknews
At 2:37 PM -0600 1/7/10, Wall, Kevin wrote:
 Larry Kilgallen wrote...
 
 At 10:43 AM -0600 1/7/10, Stephen Craig Evans wrote:

  I am VERY curious to learn how these happened... Only using the last
  digit of the year? Hard for me to believe. Maybe it's in a
 single API
  and somebody tried to be too clever with some bit-shifting.

 My wife says that in the lead-up to the year 2000 she caught
 some programmers fixing Y2K bugs by continuing to store
 year numbers in two digits and then just prefixing output
 with 19 if the value was greater than some two digit number
 and prefixing output with 20 if the value was less than or
 equal to that two digit number.

 Never underestimate programmer creativity.

 Never overestimate programmer precision.
 
 While I never fixed any Y2K problems I worked next to someone
 who did for about 6 months. What you refer to is pretty much what
 I mentioned as the fixed window technique that was very common
 to those developers who were addressing the problems at the time.
 
 IIRC, it was a particularly popular approach for those who waited until
 the last moment to address Y2K issues in there systems because it still
 allowed for 2 digit year fields in all their forms and databases and output.

Going back to the original Y2K issue, within the past 5 years
my wife and I visited a friend of my late father.  This friend
had retired as somewhat of a bigwig at an industrial giant that
formerly was in the business of manufacturing their own line of
computers.  He admitted that back in the day they had set up
things to use two digits for storing year numbers, knowing that
before the year 2000 came around, _they_ would all be retired.
-- 
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
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)

2009-10-02 Thread ljknews
At 4:33 PM -0500 10/1/09, Wall, Kevin wrote:

 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.

Reading nothing beyond what was posted, the problem I see is
to provide a complete specification against which to prove
correctness.
-- 
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
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] Inherently Secure Code?

2009-08-28 Thread ljknews
At 8:47 AM -0700 8/27/09, Benjamin Tomhave wrote:

  Should any sort of overflow really be allowed?

It is not, except by management decision (in choosing an unsafe
language).
-- 
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
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] informIT: attack categories

2009-08-26 Thread ljknews
At 6:36 PM -0400 8/25/09, Steven M. Christey wrote:
 Gary,
 
 You said in the article:
 
The next category of attacks to expect are attacks that target defects in
design and architecture - which I call flaws.
 
 I think it's already happening.

I think it has been happening for years.  I use Microsoft Word
V5.1a from 1992, because Microsoft followed that with Word 6.0
which introduced the design defect allowing Macro Viruses.

Of course this was not actually an innovation, as IBM had
previously introduced _and_withdrawn_ a similar vulnerability
in their CMS operating environment (the mail program would
automatically call a text formatter which could call the
operating system under the direction of the sender.

Those who do not study history are condemned to repeat it.
-- 
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
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] IBM Acquires Ounce Labs, Inc.

2009-07-28 Thread ljknews
At 8:39 AM -1000 7/28/09, Jim Manico wrote:

 A quick note, in the Java world (obfuscation aside), the source and  
 binary is really the same thing. The fact that Fortify analizes  
 source and Veracode analizes class files is a fairly minor detail.

It seems to me that would only be true for those using a
Java bytecode engine, not those using a Java compiler that
creates machine code.
-- 
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
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] Insecure Java Code Snippets

2009-05-08 Thread ljknews
At 9:15 AM -0400 5/8/09, SC-L Reader Dave Aronson wrote:
 ljknews ljkn...@mac.com wrote:
 At 12:47 PM -0500 5/7/09, Brad Andrews wrote:
 Quoting ljknews ljkn...@mac.com:
 At 5:49 PM -0500 5/6/09, Brad Andrews wrote:
 Try a few of the PC-Lint bugs, if you ever wrote C/C++ code.
 They can be really hard to figure out,
 And yet people keep choosing those programming languages.
 They offer quite a bit of power in exchange for the danger.
 I would be interested in hearing what they can do that cannot
 be done in Ada.
 
 It's rarely (I won't say never!) a question of what *can't* be done in
 language X or Y.  Usually, it's about what's *easier* to do in X or Y.
  Sometimes the security tradeoff is worth taking the hard way, but
 sometimes the choice is to the point of being at all practical or not.

Well the _easiest_ development comes from not worrying about
security.

So tell me what you think is easier in C/C++.
-- 
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
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] Insecure Java Code Snippets

2009-05-07 Thread ljknews
At 12:47 PM -0500 5/7/09, Brad Andrews wrote:

 Quoting ljknews ljkn...@mac.com:
 
 At 5:49 PM -0500 5/6/09, Brad Andrews wrote:

 Try a few of the PC-Lint bugs, if you ever wrote C/C++ code.
 They can be really hard to figure out,

 And yet people keep choosing those programming languages.
 
 They offer quite a bit of power in exchange for the danger.

I would be interested in hearing what they can do that cannot
be done in Ada.

My bias is based on my experience.  I am sure somebody who
knows Eiffel would be interested in hearing what C/C++ can
do that cannot be done in Eiffel.
-- 
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
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] BSIMM: Confessions of a Software SecurityAlchemist(informIT)

2009-03-25 Thread ljknews
At 1:00 PM -0700 3/25/09, Andy Steingruebl wrote:
 On Wed, Mar 25, 2009 at 10:18 AM, ljknews
mailto:ljkn...@mac.comljkn...@mac.com wrote:


 Worry about enforcement by the hardware architecture after
 you have squeezed out all errors that can be addressed by
 software techniques.\


 Larry,

 Given the focus we've seen fro Microsoft and protecting developers from
 mistakes through things like DEP, ASLR, SEH, etc. why do you think that
 these can't be done in parallel?

I don't know any of those acronyms, and I have very little to
do with Microsoft.  The last software of theirs I bought was
Microsoft Word V5.1a, the last one _before_ they introduced
Macro viruses.

I mean, we used to not have Virtual
Memory or real MMUs and the developer had to make sure they didn't step on
other people's pages.  Hardware support for protection on pages has helped
with a lot of things right?

Yes, but for me that was prior to 1978, and the benefit of
hardware protection pales by comparison to the benefit of
not programming everything in assembly language.

 I'm not saying I'm holding out hope for hardware to solve all our
problems (that would be silly) but I do think it can be fairly useful for
some classes of problems and a lot more scalable/repeatable.  
Practical
right now, no.  But we're sort of in the realm of fantasy in this
discussion already if we think the general mass of people writing software
are going to switch languages because certain ones are more reliable

I don't expect programmers to make that decision - I expect
astute management to make that decision (wherever astute
management happens to surface).

Management has a lot easier time changing languages than
changing hardware architectures.  Sometimes the hardware
is even dictated by the customer (such as when trying to
sell into a particular market).
-- 
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
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] How Can You Tell It Is Written Securely?

2008-12-01 Thread ljknews
At 9:03 PM -0500 11/26/08, Mark Rockman wrote:

 OK.  So you decide to outsource your programming assignment to Asia and
demand that they deliver code that is so locked down that it cannot
misbehave.  How can you tell that what they deliver is truly locked down?
Will you wait until it gets hacked?  What simple yet thorough inspection
process is there that'll do the job?  Doesn't exist, does it?

Certainly it exists.  Rerun the verification of the formal proof,
as used in the Tokeneer project I mentioned earlier.

Of course a formal proof only proves that software conforms to
a specification, so unless you have a specification you have
nothing, and that is what a lot of software is lacking.
-- 
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
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] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-26 Thread ljknews
At 9:32 PM -0800 11/25/08, Brian Chess wrote:

 Larry, I'm not sure I get your meaning.  You say you don't think it's a
dry well, but then you say programmers ignore the privilege management
facilities at their disposal.

I mean they ignore it until security overseers (800.53a, PCI DSS,
8500.2 evaluators) come by and force them to fix it.

 At 10:57 AM -0800 11/25/08, Andy Steingruebl wrote:
 On Tue, Nov 25, 2008 at 9:48 AM, Gunnar Peterson
mailto:[EMAIL PROTECTED][EMAIL PROTECTED]mailto:[EMAIL PROTECTED][EMAIL 
PROTECTED]
wrote:


 but actually the main point of my post and the one i would like to
 hear people's thoughts on - is to say that attempting to apply
 principle of least privilege in the real world often leads to drilling
 dry wells. i am not blaming any group in particular i am saying i
 think it is in the too hard pile for now and we as software security
 people should not be advocating for it until or unless we can find
 cost effective ways to implement it.

 Certainly it is not a dry well.  For the operating system I deal
 with, application programmers _consistently_ ignore the facility
 provided for fine-grained access to files and leave users with
 coarse-grained access as their only recourse.

So attempting to apply it is not a dry well and not too hard -
just typically done as a retrofit due to political rather than
techical circumstance.

I had a friend who was working on software where multi-million
dollar accounts failed to balance correctly.  That defect got
considerable management attention.  The same _could_ be done
for security.
-- 
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
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] Software Assist to Find Least Privilege

2008-11-25 Thread ljknews
At 12:26 PM -0500 11/25/08, Mark Rockman wrote:

 It be difficult to determine a priori the settings for all the access
control lists and other security parameters that one must establish for
CAS to work.  Perhaps a software assist would work according to the
following scenario.  Run the program in the environment in which it will
actually be used.  Assume minimal permissions.  Each time the program
would fail due to violation of some permission, notate the event and plow
on.  Assuming this is repeated for every use case, the resulting reports
would be a very good guide to how CAS settings should be established for
production.  Of course, everytime the program is changed in any way, the
process would have to be repeated.

The approach my company recommends is intended to minimize any
possible impact on existing operations (we deal exclusively
with existing installations).

1)  Enable auditing for use of privilege.
2)  Wait for a period of normal operation
(time period depends on the nature of
the business).
3)  Remove privileges from any user who never
used a particular privilege.

Of course that must be accompanied by an aggressive policy
of requiring justification of every assignment of privilege
to an individual.  In many cases, permissions have been given
for an individual to modify particular data when in fact they
should only be authorized to do that when using a particular
program.  Tightening that up uses a mechanism whose name will
vary depending on the operating system in use, but it is bound
to require modification and security analysis of applications.

The context in which we are recommending this is typically
where external security requirements are suddenly raised,
e.g. 800-53a, PCI DSS, 8500.2.
-- 
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
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] Cat out of the bag?

2008-10-30 Thread ljknews
At 11:09 AM -0600 10/30/08, Jonathan Leffler wrote:
 Content-Type: multipart/signed; protocol=application/x-pkcs7-signature;
   micalg=sha1; boundary=---z22511_boundary_sign
 
 Gary McGraw [EMAIL PROTECTED] wrote:
Here is a pointer to an article...
 
 I'm getting 404 errors?  I backed up the chain of directories in the URL 
 and the link is broken on the page:
 
 http://www.cigital.com/papers/

http://validator.w3.org shows that page has 25 HTML errors.

-- 
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
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] Human Elements of Security Survey

2008-10-09 Thread ljknews
At 8:40 PM -0400 10/8/08, Sammy Migues wrote:

 JavaScript is required on SurveyMonkey.

Thank you for the warning.  It is amazing the number of
people who presume that security people are willing to
go to a website enabling cookies or JavaScript or worse.

Of course it is also amazing the number of web sites that
silently fail in some bizarre fashion if reached by a
secured browser.
-- 
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
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] Survey

2008-08-26 Thread ljknews
At 7:21 PM -0400 8/24/08, [EMAIL PROTECTED] wrote:

 The publisher of the web page is not in the security business,
 they are in the publishing business.  But how can I respect
 their publishing expertise if they fail a simple automatic
 test.
 
 Well, I guess that most of web developers are not validating with  
 tools such as w3 validators, but more interesting, validating with  
 different browsers...

My experience is that browsers succeed on standards-compliant
pages.  Standard compliance should be the first test.  If it
subsequently fails on a particular browser, it is a browser
defect which may or may not be of interest to the publisher.
-- 
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
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] Survey

2008-08-26 Thread ljknews
At 9:12 AM -1000 8/26/08, Jim Manico wrote:

 How does xHTML help stop access control vulnerabilities?
  Authorization issues? CSRF problems?

It is indicative of the caliber of the people who built
the site.

My immediate interest is that validation combats browser crashes.

I am not interested in dealing with people who cannot get
the simple things right.
-- 
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
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] Root Canal Treatment vs Source Code Review

2008-07-01 Thread ljknews
At 10:43 PM -0400 6/30/08, Mary and Glenn Everhart wrote:

 There is another reason I have seen quite often: you can't readily ask 
 the designer of
 the code what it does when he is dead, or when he has left the company 
 (esp. if he works for a competitor).

When I participated (as author) in formal inspection there were
as many defects found (and fixed) in the comments as in the code.
And most people think my comments are better than average.

I have left the company but still have some access to see
what defects they have found since.
-- 
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
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] InternetNews Realtime IT News - Merchants Cope With PCI Compliance

2008-06-30 Thread ljknews
At 9:44 AM -0400 6/30/08, Kenneth Van Wyk wrote:

 Happy PCI-DSS 6.6 day, everyone.  (Wow, that's a sentence you don't  
 hear often.)
 
 http://www.internetnews.com/ec-news/article.php/3755916
 
 In talking with my customers over the past several months, I always  
 find it interesting that the vast majority would sooner have root  
 canal than submit their source code to anyone for external review.   
 I'm betting PCI 6.6 has been a boon for the web application firewall  
 (WAF) world.

The Note: at the end of PCI DSS (v1.1) 6.6 talks about
this method but typographically seems to apply to both
bullets.  Does anyone know what the authors had in mind ?
-- 
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
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] GCC and pointer overflows [LWN.net]

2008-05-01 Thread ljknews
At 1:00 PM -0400 5/1/08, Epstein, Jeremy wrote:

 Ken, a good example.  For those of you who want to reach much further
 back, Paul Karger told me of a similar problem in the compiler (I don't
 remember the language)

VAX Pascal, before VMS was on Alpha (and long before Itanium).

 used for compiling the A1 VAX VMM kernel, that
 optimized out a check in the Mandatory Access Control enforcement, which
 separates information of different classifications (*).  [For those not
 familiar with it, this was a provably secure kernel on which you could
 host multiple untrusted operating systems.  Despite what some young-uns
 seem to think, VMs are not a new concept - they go back at least three
 decades that I know of, and possibly longer.  The A1 VAX effort ended
 roughly 20-25 years ago, to give a timeframe for this particular
 compiler issue.]

-- 
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
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] GCC and pointer overflows [LWN.net]

2008-05-01 Thread ljknews
At 3:12 PM -0400 5/1/08, Leichter, Jerry wrote:

 The VAX VMM effort died with the announcement of the Alpha, in late 1992
 - though obviously the death was decided internally once the move to
 Alpha was decided, which would have been somewhat earlier.  The origins
 of the VAX VMM effort date back to the early 80's.

My understanding is that DEC pulled the plug on the VMM project
(called SVS) during a successful field test when they discovered
that while the NSA division that handled trusted computing was
really gung ho about the project, none of the government units
which might actually make purchases were interested in multilevel
secure machines.  Remember that the MicroVAX II was available at
the time and from many perspectives (including that of taxpayers)
it was a lot nicer to use separate machines for various security
classifications.
-- 
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
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] InformIT: budgeting for software security

2008-04-11 Thread ljknews
At 8:14 AM -0500 4/11/08, Wall, Kevin wrote:

 In the context, I think his concern was that in the past, the RSA
 conferences were focused on infosec, and on cryptography in particular. 
 Apparently,
 based on Stephen and gem's comments, it seems to have lost its focus. I think
 that's all that was being implied here.

Some years ago at an RSA Conference I recall seeing Jefferson
Starship.  At least one song had altered lyrics for the GAK
issue of the year, but that was not a whole lot of security
content in a general session.
-- 
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
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] Code review pool

2007-11-05 Thread ljknews
At 12:50 PM +0100 11/5/07, Paolo Perego wrote:

 Hi guys, trying to improve Owasp Orizon project in a better way, I
 released a poll over my blog here:
 http://thesp0nge.livejournal.com/5687.html
 
 It would be great having your feedback about your vision to code
 review and safe coding as developers and security specialist.

I see a bunch of links called View Answers along with a link
called Poll #1083138.

Clicking on the Poll #1083138 link takes me to a page of answers.
-- 
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
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] COBOL Exploits

2007-11-02 Thread ljknews
At 12:13 AM -0400 11/2/07, Mark Rockman wrote:

 The adolescent minds that engage in exploits wouldn't know COBOL if a
printout fell out a window and onto their heads.  I'm sure you can write
COBOL programs that crash, but it must be hard to make them take control
of the operating system.

Of course if a program is able to take control of the operating system,
either:

A. The operating system is at fault (typically not COBOL)

B. The program is installed with special privileges

Just feeding bad parameters to a system call is inadquate to suborn
a well-constructed operating system.
-- 
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
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] Mainframe Security

2007-11-02 Thread ljknews
At 4:11 PM +0100 11/2/07, Johan Peeters wrote:

 Let me offer a little variant on the previous theme though to
 illustrate, hopefully more convincingly, why I find COBOL worrisome:
 
   ...
01 txtpic x(2).

move 'hi' to txt
call 'evil-code' using txt

 
   IDENTIFICATION DIVISION.
PROGRAM-ID. evil-code.
DATA DIVISION.
linkage section.
01 assetPIC  X(1200).
procedure division using asset

 
 The author of evil-code now has a selection of the contents of the
 caller's data segment at his disposal.

Are you saying that evil-code is written in some language that allows
it to take advantage of by-reference semantics to go outside the
nominal boundaries of 2 bytes presumed by COBOL ?

If so, this is hardly an issue specific to COBOL.  Presuming evil-code
can play address arithmetic issues, any situation where the caller's
address space is visible to evil-code is similarly vulnerable.

Clearly evil-code should be in a separate address space to defend
against such an attack.
-- 
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
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] Mainframe Security

2007-11-02 Thread ljknews
At 2:16 PM +0100 11/2/07, Johan Peeters wrote:

 I have been looking at an IBM system. If I do something like this
 
   ...
01 txt PIC  X(120)

string '**'
  into txt
end-string
display txt
 
 I get to see ** on sysout followed by what appears to be selected
 contents of the data section. This strikes me as somewhat worrysome -
 it reminds me of the format string vulnerabilities in C.
 Am I just being paranoid?

A program that improperly releases data due to programmer error is
beyond what I consider to be the realm of security.  To me that is
merely bad programming.

To me the criterion is whether an outsider can cause a program to do
something other than what it does for normal users.  Some secret back
door password that causes organizational secrets to be released would
be a Trojan horse.  A typical method of controlling that is with the
security controls on a database, so only authorized users can read the
company secret field, no matter how badly the application programmer
messes up.
-- 
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
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] Mainframe Security

2007-11-02 Thread ljknews
At 11:45 PM +0100 11/2/07, Florian Weimer wrote:

 My limited exposure to Cobol makes me think it is as unlikely to have
 a buffer overflow as PL/I or Ada.
 
 Usually, Ada programmers switch off bounds checking before shipping
 code.  I don't know why Ada has such a reputation for robustness.

Can you provide a pointer to the study showing that ?

Certainly none of the Ada I ship has bounds checking disabled.
-- 
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
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] Mainframe Security

2007-11-01 Thread ljknews
At 9:16 PM +0100 11/1/07, Johan Peeters wrote:
 I think this could do a great service to the community.
 
 Recently I was hired by a major financial institution as a lead
 developer. They said they needed me for some Java applications, but it
 turns out that the majority of code is in COBOL. As I have never
 before been anywhere near COBOL, this comes as a culture shock. I was
 surprised at the paucity of readily available information on COBOL
 vulnerabilities, yet my gut feeling is that there are plenty of
 security problems lurking there. Since so much of the financial
 services industry is powered by COBOL, I would have thought that
 someone would have done a thorough study of COBOL's security posture.
 I certainly have not found one. Anyone else?

Can anyone point to stories about Cobol exploits ?

I mean exploits that have to do with the nature of the language, not
social engineering attacks that happened to take place against a Cobol
shop.

My limited exposure to Cobol makes me think it is as unlikely to have
a buffer overflow as PL/I or Ada.
-- 
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
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] Dilbert Does Software Testing

2007-07-29 Thread ljknews
http://www.dilbert.com/comics/dilbert/archive/images/dilbert2007071745828.gif
-- 
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
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] how far we still need to go

2007-07-26 Thread ljknews
At 2:03 AM +0100 7/26/07, Dinis Cruz wrote:
 It's a simple economics problem. The moment these companies and
developers lose sales (or market share) because their products require
admin / root privileges to run, is the moment they start to REALLY support
it.

For Windows that day might be when they have to run under the new US
federal government standard Windows configuration, due out any month now.
-- 
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
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] Resources to fix vulns

2007-07-19 Thread ljknews
At 8:53 AM -0700 7/18/07, McCown, Christian M wrote:
 Content-class: urn:content-classes:message
 Content-Type: multipart/alternative;
   boundary=_=_NextPart_001_01C7C953.D03CBE5C

 What do you tell a C-level exec in terms of h/c and time it will take to
fix web app vulnerabilities discovered in a website?

 X number of vulnerabilities = Y h/c and Z time.

 Of course there's a host of factors/variables involved that could wind up
looking like actuarial tables or DNA sequences (!), but what we'd like to
be able to do is sum it up as an initial swag and let the app owners use
it as a factor in calculating the actual time to remediate.

Look at the track record for _that_organization_ fixing previous
vulnerabilities.
-- 
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
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] Resources to fix vulns

2007-07-19 Thread ljknews
At 9:50 AM -0400 7/19/07, McGovern, James F (HTSC, IT) wrote:

  I would actually recommend AGAINST using prior track records for fixing
 previous vulnerabilities because in all honestly they probably don't
 track it. Most enterprises prioritize any type of defect based on the
 importance as declared by business users whom traditionally would
 prioritize a spelling error on a web page of higher importance than a
 buffer overflow. Security stuff may get addressed while the developer
 has the patient open and therefore there is no real transparency in
 terms of the numbers.

If investigation of prior security vulnerability remediation shows it
is skewed by low organizational priority, then that _is_ an indication
of how fast _that_organization_ will fix a security vulnerability.  It
seems much more honest that guesses about how long it would take if it
were high priority.

As for record keeping, the source code archives should show the date a
change was made (even if bundled with other changes).
-- 
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
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 Next Frontier

2007-06-27 Thread ljknews
At 4:38 PM -0400 6/27/07, Paco Hope wrote:
 On 6/26/07 5:00 PM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote:
 
 Would there be value in terms of defining an XML schema that all tools could 
 emit audit information to?
 
 You might want to take a look at what the Fortify guys already do. Their 
 FVDL (Fortify Vulnerability Description Language) is XML written to a 
 specific schema

In the US, the federal government has a lot of that going on:

http://nvd.nist.gov/scap.cfm

but they only support certain platforms, like Windows.
-- 
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
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] Harvard vs. von Neumann

2007-06-11 Thread ljknews
At 9:00 AM -0400 6/11/07, Gary McGraw wrote:

 If we assumed perfection at the implementation level (through better
 languages, say), then we would end up solving roughly 50% of the
 software security problem.
 
 Clearly we need to make some progress at the architecture/design level
 to attain reasonable levels of software security.

 Perfect languages won't solve the software security problem.

And neither will perfect designs.

Both approaches needed.

But a large percentage of failures that result from weak languages are
already categorized in standard terms like buffer overflow.
-- 
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
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: What's the next tech problem to be solvedin softwaresecurity?

2007-06-10 Thread ljknews
At 9:51 PM +0100 6/9/07, David Crocker wrote:

 If instead we pay people to perform the more skilled tasks of establishing
 requirements and specifying the systems to meet them, and use computers to
 generate programs that meet the specifications, then such things as freedom 
 from
 buffer overflow come free of charge. By freedom here, I don't mean the sort 
 of
 freedom that comes in safe languages such as Ada and Java - in which the
 buffer overflow raises an exception, probably requiring a restart of the
 subsystem

In my experience with Ada 83, the potential for buffer overflow is detected
at compile time.  When I get an unexpected runtime exception, it is almost
always at the interface to another language.
-- 
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
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: What's the next tech problem to be solvedin softwaresecurity?

2007-06-10 Thread ljknews
At 9:16 AM -0400 6/10/07, Robert C. Seacord wrote:
 ljknews,
 
 Yes, it is virtually impossible to get a serious runtime error in an Ada
 program.  For example:
 
 http://www.youtube.com/watch?v=kYUrqdUyEpI

It amazes me that someone in a discussion of software security would point
to a page that requires Javascript to be viewed.

But I see the topic of the page was Ariane 5, a well known case of running
software in an environment other than that specified in the design of the
software.

That is a management issue - my comments were about buffer overflows,
as were the comments of David Crocker which I quoted.  If you have
secret knowledge that the Ariane 5 failure was related to buffer
overflows, please share it.

Not reading what was going on, in fact, was the cause of the Ariene 5
failure.

 At 9:51 PM +0100 6/9/07, David Crocker wrote:

   
 If instead we pay people to perform the more skilled tasks of establishing
 requirements and specifying the systems to meet them, and use computers to
 generate programs that meet the specifications, then such things as freedom 
 from
 buffer overflow come free of charge. By freedom here, I don't mean the 
 sort of
 freedom that comes in safe languages such as Ada and Java - in which the
 buffer overflow raises an exception, probably requiring a restart of the
 subsystem
 

 In my experience with Ada 83, the potential for buffer overflow is detected
 at compile time.  When I get an unexpected runtime exception, it is almost
 always at the interface to another language.
   

-- 
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
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] What's the next tech problem to be solved in software security?

2007-06-09 Thread ljknews
At 8:33 AM -0400 6/9/07, der Mouse wrote:

 Immunity from buffer overflows has been around for 30 years.  The
 fact that some set of developers choose to ignore the languages that
 provide it does not make the next environment that provides it an
 improvement for the industry.
 
 I'd disagree - if it means a significant increase in people actually
 using such environments (languages, whatever), then it's an
 improvement for the industry, even if it's no theoretical advance.

A law which outlawed unsafe languages could also be effective, but it
would not solve a tech problem, which is the basis for this thread.
At best these are solutions to social problems or education problems.
-- 
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
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] What's the next tech problem to be solved in software security?

2007-06-08 Thread ljknews
At 9:53 AM +0200 6/8/07, Stephen de Vries wrote:
 On 8 Jun 2007, at 02:23, Steven M. Christey wrote:

 More modern languages advertise security but aren't necessarily
 catch-alls.
 
 At the same time, the improvements in security made by managed code  
 (e.g. the JRE and .NET runtimes) for example, should not be  
 understated.  The fact that apps written in these languages are not  
 susceptible to buffer overflow issues is a HUGE improvement.

An improvement only for those who have previously chosen lowest common
denominator languages.  Immunity from buffer overflows has been around
for 30 years.  The fact that some set of developers choose to ignore
the languages that provide it does not make the next environment  that
provides it an improvement for the industry.
-- 
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
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: Secure Coding Certification

2007-05-14 Thread ljknews
At 11:35 AM -0400 5/14/07, Greg Beeley wrote:

 Agreed in concept to the no second-class citizens idea.  But I think
 the test needs to have a language-specific element to it.  Every language
 and environment has unique pitfalls and security considerations.  A
 developer who knows to avoid memory management, buffer, and integer issues
 in C may have no clue about nul-poisoning in a web scripting language's
 counted (as opposed to zero-terminated) strings.

And they may have no need for that.
-- 
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
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] Best practices for encrypting client-side data

2007-05-10 Thread ljknews
At 12:01 PM +1200 5/10/07, Robin Sheat wrote:
 Content-Type: multipart/signed; boundary=nextPart1622971.NJ1973Q3ia;
   protocol=application/pgp-signature; micalg=pgp-sha1
 Content-Transfer-Encoding: 7bit
 
 On Wednesday 09 May 2007 02:11:05 ljknews wrote:
 I would suggest two factor authentication, requiring some smart card
 (with built-in keypad, to prevent intercept of the pin) that actually
 provides the decryption.  Make the user keep the smart card with them,
 such as by requiring it for entrance to the cafeteria or rest room.
 That's not possible in this case. Mostly because it would involve more 
 investment on our part than the customers would be willing to pay for.
 
 However, I'm interested in generalising the ideas in this thread to go beyond 
 my particular situation; if you were storing data in an application on a 
 laptop, how would you keep it as safe as is feasible?

The tension between as safe as is feasible and not willing to pay for
is not susceptible to generalization.
-- 
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
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: compliance

2007-03-30 Thread ljknews
At 9:29 AM -0400 3/30/07, Benjamin Tomhave wrote:

 SOX has been a complete waste, imo.  First, the majority of it was already
 covered in existing law.  Second, it really has nothing to do with security
 from a practical standpoint.  The only purpose SOX has served is to give
 auditors another source of revenue.  And, worse than that, it initially gave
 auditors the appearance of more power and responsibility, which I saw
 carried out in external auditors trying to dictate to businesses how the
 business should operate (and not in a good way).  Talk about a fundamental
 violation of independence and objectivity.  The pendulum has fortunately
 swung back on that trend.
 
 PCI DSS, on the other hand, has been a very good effort with real,
 meaningful results.  Why is this?  Well, for one thing, it's specific.  As
 opposed to SOX, which paints with broad strokes and focuses on truth in
 reporting (gross oversimplification), PCI DSS goes into technical detail on
 what activities must be implemented, what minimum measures are for adequate
 security in a system, etc.  Perhaps the best example of this thought is
 section 3.6 in DSS v1.1, where it details the minimum requirements for key
 management.  It makes my job much easier having this level of detail, with
 much less left to interpretation (again, unlike SOX, where almost everything
 is open to interpretation and the whim of your auditors).

That parenthetical comment is almost verbatim the description of SOX
I received from someone who is subject to SOX audits.

My own nomination for specificity in security standards is NIST Special
Publication 800-53 (currently at Revision 1).

   http://csrc.nist.gov/publications/nistpubs/index.html#sp800-53-Rev1

Through all the controls there is only one requirement with which I disagree.
-- 
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
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] Economics of Software Vulnerabilities

2007-03-20 Thread ljknews
At 8:55 AM -0400 3/20/07, Michael S Hines wrote:
 I'm not sure what your sources are but from what I'm hearing and reading the
 problem is that there are many missing drivers for what have become standard
 peripherals that people are used to - and some of the vendors are reluctant
 to develop new drivers (the driver technology changed in Vista - so all
 drivers have to be reworked).
 
 MP3 players, ePhones, PDA's, etc. have become standard components in many
 places...  and they don't work with Vista - yet (if ever).

That is because the features provided by many add-on products depended on
the longstanding loose state of security on Microsoft Windows.

 It's the feature thing not that users are shunning security.
 
 And, at least to me, it is an indication that M$ did not understand the
 marketplace or rushed the (incomplete) product to market.  There's more than
 one way to foul up a new product launch.

The previous Microsoft mode had been to favor anything that would ease
feature implementation over anything that would provide security.
-- 
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
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] Dark Reading - Discovery and management - Security Startups Make Debut - Security News Analysis

2007-01-28 Thread ljknews
At 5:20 PM +1100 1/25/07, Crispin Cowan wrote:
 ljknews wrote:
 My guess is that if a company actually is capable of analyzing
 binary code they only do it for the highest volume instruction
 sets.
   
 They certainly will focus on larger markets first. If you want them to
 focus on *your* market, make it worth their while :)

So I should pay to have them check the work of my vendors ?

Or I would convince my vendors to pay them ?

Sorry, my business is not that large a fraction of my vendors' customer base.
-- 
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
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] Dark Reading - Discovery and management - Security Startups Make Debut - Security News Analysis

2007-01-22 Thread ljknews
At 1:52 PM -0500 1/22/07, Kenneth Van Wyk wrote:
 Content-Type: multipart/signed; protocol=application/pgp-signature;
   micalg=pgp-sha1; boundary=Apple-Mail-12-58709954
 Content-Transfer-Encoding: 7bit

 Ok, last software security news item for today, I promise.  :-)  This
article (see

http://www.darkreading.com/document.asp?doc_id=115110WT.svl=news1_1http://www.darkreading.com/document.asp?doc_id=115110WT.svl=news1_1)
is about a couple of new startup companies.  One of them in particular,
Veracode, may be of some interest here.  The article says, Veracode,
founded by Chris Wysopal and other former executives of @stake, is now
offering patented binary-code analysis of software for enterprises that
want to analyze their software's security on a regular basis. The ASP will
also offer security reviews of enterprise products and security analysis
of third-party apps for software developers.

 The article also provides some counterpoints, including some from Gary
McGraw, that are worth reading.  Among other things, Gary says, However,
if you want real security analysis you have to go past the binary, past
the source code, and actually consider the design.

 Opinions on binary vs. source code (and design!) analysis, anyone?

Analyzing source code is independent of machine architecture.

My guess is that if a company actually is capable of analyzing
binary code they only do it for the highest volume instruction
sets.

My guess is that attackers will go after machines they feel are
less protected.

Efforts which merely change attacker behavior are a waste of time.
-- 
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
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] Dark Reading - Discovery and management - Security Startups Make Debut - Security News Analysis

2007-01-22 Thread ljknews
At 3:10 PM -0800 1/22/07, Blue Boar wrote:
 ljknews wrote:
 Analyzing source code is independent of machine architecture.
 
 My guess is that if a company actually is capable of analyzing
 binary code they only do it for the highest volume instruction
 sets.
 
 My guess is that attackers will go after machines they feel are
 less protected.
 
 Efforts which merely change attacker behavior are a waste of time.
 
 Nope. If I'm running x86 boxes, I'd be more than happy to have to
 attackers move to SPARC.

Those of us _not_ running X86 do not feel that way.
-- 
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
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] temporary directories

2007-01-02 Thread ljknews
At 8:45 AM -0500 12/30/06, Leichter, Jerry wrote:

 [MJoderator:  This is likely beyond the point of general interest to sc-l]

Actually, I disagree, in that it seems to expose a set of vulnerabilities
not known even to language implementors.

 On Fri, 29 Dec 2006, ljknews wrote:

 | But these are problems that have been solved by those who provided the
 | Ada implementation (ACT and Aonix come to mind for Unix), and thus are
 | not an issue for the high level language programmer.

 Presumably they do the create-the-file-and-immediately-delete-it trick.
 Since the file must, however briefly, have an entry in some directory.
 General purpose code can't make assuptions about what directories
 are available for writing, so pretty much has to put the entry in
 a known, public place - almost always /tmp or /var/tmp.  Unless one
 does this very carefully, it's open to various attacks.  (For one
 trivial example, there is no way to tell the open() call to *always*
 create a new file - you can only tell it if the file already exists,
 don't open it, return an error instead.  The code had better check
 for that error and do something appropriate or it can be fooled into
 using a file an attacker created and already has access to.)

Certainly code that does not check for errors is inadequate.

 The techniques for doing this are complex enough - and the attacks
 if you don't do it *exactly* right obscure enough - that after all
 these years, attacks based on insecure temporary file creation
 are still reported regularly.  (Frankly, even though I know that
 these problems exist, if you were to ask me to write a secure
 temporary file creator right now, I wouldn't try - I'd look for
 some existing code, because I doubt I'd get it right.)

Which is what one does when using the existing language implementation
(except for the defect reported by Florian Weimer in this thread.
-- 
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
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] temporary directories

2007-01-02 Thread ljknews
At 5:11 PM +0100 12/30/06, Florian Weimer wrote:

 I gather you are saying that the innards of Unix will force creation
 of an unwanted directory entry on the Ada implementation of the required
 null name support for packagename.CREATE .  The Ada implementation
 could rely on exclusive access to the file (surely Unix has that, right?)
 
 You can create files in a way that fails if the file already exists,
 using the O_EXCL flag.  (Rumors have it that this won't work reliably
 over NFS, though, but I don't see why.)
 
 coupled with whatever Unix has that passes for the FAB$V_DLT bit to
 delete the file on Close (such as at insert Unix words for image rundown).
 
 You can delete open files on Unix, so you could in theory unlink it
 after creation.
 
 But the whole discussion is moot because existing Ada code seems to
 require that temporary files have names. 8-/

The Ada language does not have such a requirement, and in fact has a
requirement that names are _not_ required for temporary files.

 But these are problems that have been solved by those who provided the
 Ada implementation (ACT and Aonix come to mind for Unix), and thus are
 not an issue for the high level language programmer.
 
 AdaCore's implementation used mktemp and featured the usual race
 condition.

Yucko !!!
-- 
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
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] Compilers

2007-01-02 Thread ljknews
At 2:18 PM + 1/2/07, Peter Amey wrote:
 [snip]
 
 Isn't the whole basis of Spark a matter of adding proof 
 statements in the comments ?  I don't think the general 
 compiler marketplace would go for that built-in to compilers. 
  After all:
 
  1. The Praxis implementation can be used with multiple compilers
 
  2. The compiler market is so immature that some people are still
 using C, C++ and Java.
 
 But for the high-integrity market, Spark seems to fit the bill.
 --
 Larry Kilgallen
 
 We think so!  However, like everything else, it is how you use things
 that matter most.

How you use things may be an essential aspect, but so is the nature
of things.  Achieving the same quality by toggling the machine code
into the front panel is only possible on a theoretical basis, and getting
the same results with a long strand of limp spaghetti is just impossible.
-- 
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
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] Building Security In vs Auditing

2007-01-02 Thread ljknews
At 9:46 AM -0500 1/2/07, McGovern, James F (HTSC, IT) wrote:

 I read a recent press release in which a security vendor (names removed
 to both protect the innocent along with the fact that it doesn't matter
 for this discussion ) partnered with a prominent outsourcing firm. The
 press release was carefully worded but if you read into what wasn't said,
 it was in my opinion encouraging something that folks here tend to fight
 against. The outsourcing firm would use this tool in an auditing capacity
 for whatever client asked for another service but it would not become
 part of the general software development lifecycle for all projects. 
 
 - It didn't mention any notion of all developers within the outsourcing
 firm having tools on their desktop to audit as they develop

From the information supplied, it is not clear that the tool is something
appropriate for the development environment.  I develop a tool that could
be used in a (certain) development environment, but that would only tell
how the development environment was secured, having no effect on the degree
to which the outsourced code was secure.

 - It didn't mention any notion of training all developers within the
 outsourcing firm on secure coding practices

From the information supplied, it is not clear that the security vendor
is one that would be involved in training anyone.  Limitations on a
joint press release (one that names another company) are subject to
severe negotiations.  Even if the security firm _was_ going to do what
you suggest, I can see a PR flack at the outsourcing firm resisting any
public suggestion that any of their staff needed further training on any
aspect of data processing.
-- 
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
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] temporary directories

2006-12-29 Thread ljknews
At 6:56 PM -0500 12/29/06, Leichter, Jerry wrote:

 | Not on Unix, but I tend to use temporary names based on the Process ID
 | that is executing.  And of course file protection prevents malevolent
 | access.
 |
 | But for a temporary file, I will specify a file that is not in any
 | directory.  I presume there is such a capability in Unix.

 You presume incorrectly.  You're talking about VMS, where you can
 open a file by file id. 

Actually, I was talking about using the FAB$V_TMD bit when creating
the file.

 One can argue this both ways, but on the specific matter of safe
 access to temporary files, VMS code that uses FID access is much
 easier to get right than Unix code that inherently has to walk
 through directory trees.  On the other hand, access by file id
 isn't - or wasn't; it's been years since I used VMS - supported
 directly by higher-level languages (though I vaguely recall that
 C had a mechanism for doing it).

In Ada invoking packagename.CREATE with a null name will do the
trick, although if your VMS experience ended before 1983 you would
not have run into that.  But how to program easily against VMS V4.1
when the latest version is VMS V8.3 is not a typical problem.

I gather you are saying that the innards of Unix will force creation
of an unwanted directory entry on the Ada implementation of the required
null name support for packagename.CREATE .  The Ada implementation
could rely on exclusive access to the file (surely Unix has that, right?)
coupled with whatever Unix has that passes for the FAB$V_DLT bit to
delete the file on Close (such as at insert Unix words for image rundown).

But these are problems that have been solved by those who provided the
Ada implementation (ACT and Aonix come to mind for Unix), and thus are
not an issue for the high level language programmer.
-- 
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
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] Could I use Java or c#? [was: Re: re-writingcollege books]

2006-11-15 Thread ljknews
At 3:44 PM + 11/15/06, Pete Shanahan wrote:
 ljknews wrote:
 At 8:18 PM -0600 11/14/06, Wall, Kevin wrote:
 
 That makes a Java
 inappropriate
 for a lot of system-level programming tasks. Simple example: There's no
 way
 in pure Java that I can lock a process in memory. Wrt this list, that
 has
 a lot of security ramifications especially on shared processors. Sure
 makes
 hiding secrets a lot harder.

I did not write any of that.

 It's an operating system feature where you can lock a chunk of the memory of a
 process such that it is not swapped out at any time.
 
 see the specs for mlock, madvise.

Those words mean nothing to me, but I presume you are talking about
either locking a page into memory:

http://h71000.www7.hp.com/doc/83FINAL/4527/4527pro_081.html#jun_369

or locking a page into the working set:

http://h71000.www7.hp.com/doc/83FINAL/4527/4527pro_082.html#jun_373

or preventing an entire process from being swapped out:

http://h71000.www7.hp.com/doc/83FINAL/4527/4527pro_105.html#jun_526

None of those resolve the responsibility of the operating system to remove
residue from memory before transferring it to another user.  That is true
regardless of whether the process is running compiled code or a bytecode
engine (which is the real issue, not the implementation language).

 win32, I believe has an even more feature ridden facility for secure memory.
 
 on the receipt of abnormal termination signals this memory can be cleared, 
 thus
 keeping the secret safe, so you could produce a process crash dump that is
 sanitized for sending to a support group.

Yes, that is present in my environment as well.  Is the problem that the
bytecode engine used with languages like Java do not have a function to
exclude certain parts of memory from process crash dumps ?  That was not
clear from the prior statement.
-- 
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


Re: [SC-L] Could I use Java or c#? [was: Re: re-writingcollegebooks]

2006-11-15 Thread ljknews
At 10:55 AM -0600 11/15/06, Wall, Kevin wrote:
 Larry Kilgallen wrote:
 At 8:18 PM -0600 11/14/06, Wall, Kevin wrote:
 
  That makes a Java inappropriate for a lot of
  system-level programming tasks. Simple example: There's no
  way in pure Java that I can lock a process in memory. Wrt this 
  list, that has a lot of security ramifications especially on
  shared processors. Sure makes hiding secrets a lot harder.
 
 Please explain that issue.
 
 Is there some multiuser operating system that does not clear 
 memory before retasking it for another  process ?

 I wasn't referring to the OS not clearing memory between use by
 different processes. Instead consider a case where there's a secret
 such as an encryption key, password, etc. in a chunk of memory that
 has been paged out to a swap device (*nix) or pagefile.sys (Windows).
 The process them terminates abnormally because of a signal, abrupt
 power outage, etc. From a security POV, this is a bad thing since
 now your secret is somewhere on the hard drive.

But a cryptographic secret should not be in user-readable memory in the
first place, due to the risk of a trojan horse.  That belongs in OS memory
dedicated to the user but protected from them (i.e., inner mode) and at
that point the operating system can mark such memory as not being subject
to dumping.

The user might enter a password to _unlock_ that secret key, and some
trojan horse (or wiretap) might intercept that password and use it in
a malicious fashion, but the trojan horse cannot export the secret key
to another machine.  (By secret key, I mean the secret half of a public
key pair.)

 Overall, I find these types limitations with Java or C# more frustrating
 than I do with the performance issues.

A native compiler should have no problem calling any system service.
It would seem your objection is really to the bytecode engine version
of Java rather than to the language itself.
-- 
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


Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]

2006-11-13 Thread ljknews
At 10:31 PM +1100 11/13/06, mikeiscool wrote:
 On 11/13/06, Glenn and Mary Everhart [EMAIL PROTECTED] wrote:

 If there is some construct that NEEDS to be interpreted to gain something, it
 can be justified on that basis. Using interpretive runtimes just to link
 languages, or just to achieve portability when source code portability runs
 pretty well thanks, seems wasteful to me.
 
 You think source code portability is good enough such that runtime
 portability isn't really needed?

Anything beyond source code portability tempts the customer into use on
a platform where the developer has not tested.
-- 
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


Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]

2006-11-06 Thread ljknews
At 10:47 AM -0500 11/6/06, der Mouse wrote:
 I read this thread and I little be afraid.  I'm just ahead of a
 complete rewriting of my program.  The previous code was written in
 pure C (with an OOP looks-like somewhere).
 
 Perhaps I'm missing something.  Why do you have to abandon C?  You
 mention C++, C#, and Java, but no other languages; is there some reason
 you have to use a language that tries to be object-oriented?

Is there some reason you have to use a language that looks like C ?
-- 
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


Re: [SC-L] Why Shouldn't I use C++?

2006-11-01 Thread ljknews
At 9:08 PM -0500 10/31/06, Ben Corneau wrote:

 C and C++ are very different. Using C++ like C is arguable unsafe, but when
 it's used as it was intended can't C++ too be considered for secure
 programming?

What assurance does upper management have that C++ was used as it was
intended rather than like C ?
-- 
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


Re: [SC-L] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]

2006-10-17 Thread ljknews
At 12:11 PM -0400 10/13/06, James Walden wrote:

 you really have to use C because it's the only thing that will do,

That seems extremely improbable.
-- 
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


Re: [SC-L] bumper sticker slogan for secure software

2006-07-20 Thread ljknews
At 9:46 PM +0200 7/20/06, Florian Weimer wrote:
 * Pascal Meunier:
 
 But it's true for stupid bugs like buffer overflows and format string
 vulnerabilities, in which we're still swimming, and the proof is the fact
 that those aren't possible in some languages.

 Could you name a few such language implementations? 8-)

Ada !

 In most cases, the components that enforces the absence of buffer
 overflows are written in C.

Not in VAX/DEC/Compaq/HP Ada, which is the one that I use.

But the components that enforce the absence of buffer overflows are
not written in Bliss (the language of the Ada RTL for that compiler)
either.  They are in the code that is generated, or the failure to
generate that code because the problem was caught at compile time.
-- 
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


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

2006-07-16 Thread ljknews
At 3:27 PM -0400 7/15/06, Goertzel Karen wrote:
 Content-class: urn:content-classes:message
 Content-Type: multipart/alternative;
   boundary=_=_NextPart_001_01C6A844.D6A28B6B

 I've been struggling for a while to synthesise a definition of secure
software that is short and sweet, yet accurate and comprehensive. Here's
what I've come up with:

 Secure software is software that remains dependable despite efforts to
compromise its dependability.

 Agree? Disagree?

I disagree about that being bumper-sticker size, and I think we really
need bumper stickers.
-- 
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


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

2006-06-09 Thread ljknews
At 2:32 PM -0400 6/9/06, Jeremy Epstein wrote:

 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.

I don't even get those questions for our security product !
-- 
Larry Kilgallen
LJK Software
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Hiring folks that are familar with SC practices

2006-06-04 Thread ljknews
At 10:38 AM -0400 6/2/06, McGovern, James F (HTSC, IT) wrote:

 Figured I would ask the list a question that I haven't figured out the
answer to. How have other enterprises that seek architects and developers
knowleedgable in secure coding software development practices articulated
it to their internal HR recruiting arm? We have been seeking candidates
with this background but haven't ran across much on our side of town.

Are you bringing something to the table to attract such people ?

Or have you preconstrained the programming languages and techniques
to be used ?
-- 
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


Re: [SC-L] HNS - Biggest X Window security hole since 2000

2006-05-05 Thread ljknews
At 11:12 AM -0400 5/4/06, Kenneth R. van Wyk wrote:
 Content-Type: multipart/signed; boundary=nextPart1887150.2DlSXmIMA5;
   protocol=application/pgp-signature; micalg=pgp-sha1
 Content-Transfer-Encoding: 7bit
 
 Stories about this (below) X bug and the DHS-sponsored project that found it 
 have been floating around the net all week.  This story caught my eye, 
 though:
 
 http://www.net-security.org/secworld.php?id=3994
 
 The author claims, This flaw, caused by something as seemingly harmless as a 
 missing closing parenthesis, allowed local users to execute code with root 

Certainly that part is OS-specific.  On my VMS machine, X-windows processes
do not run as root.

 privileges, giving them the ability to overwrite system files or initiate 
 denial of service attacks.
 
 So, it sounds like a single byte change in the entire X src tree could fix a 
 bug that could give an attacker complete control of a system.  Lovely...
-- 
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


Re: [SC-L] Segments, eh Smithers?

2006-04-04 Thread ljknews
At 9:02 AM -0700 4/3/06, Crispin Cowan wrote:

 That second question is actually pretty technically deep. What is so
 different about paged memory systems that makes them harder to secure
 than segmented memory systems? My conjecture: it is the granularity of
 the memory blobs. Consider:
 
 * In a segmented system, you have a small number of fairly large
   memory objects (segments). Segments are hefty enough that they can
   be of variable size, and also can have security tags describing
   their security level at multiple levels. So a given segment can be
   tagged as being security level 1, 2, 3, and so forth, and the TCB
   need only check the level before granting or denying access.
 * In a paged system, in contrast, you have a very large number of
   much smaller memory objects (pages). Pages are simple, even having
   fixed size. Fixed size wastes memory, but no one cares because the
   pages are small enough that it doesn't hurt much. Because pages
   are simple, you cannot tag them with a bunch of different security
   levels. For that matter, x86 architectures only recently got a
   (kind-of) ability to distinguish between read and execute
   permissions per page, so asking associate and store security
   levels per page in hardware is likely more than the TLB can handle.

I will admit to not knowing much about hardware, but you seem to be
discussing a TCB implemented in software.

Consider the VAX/Alpha/Itanium on which VMS runs.  As a user program
I access pages, but I don't think of them in those terms.  I think of
them as Sections (some are Global) which contain the read-only part
of one shareable image, my own DCL symbols, etc.  Those sections to
which I have access are in my virtual address space protected so I
have that access to which I am entitled.

What is disturbing about that hardware ?  Is it the fact that the
operating system is really setting individual page protections rather
than a whole segment at a time ?

I realize you probably want more levels and compartments, but that
does not seem to me to make the task untenable.  Educate me.
-- 
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


Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code

2006-03-27 Thread ljknews
At 2:34 AM +0100 3/27/06, Dinis Cruz wrote:

 PS: For the Microsofties that are reading this (if any)   sorry for
the irony and I hope I am not offending anyone, but WHEN are you going
to join this conversion? (i.e. reply to this posts)

 I can only see 4 reasons for your silence: a) you are not reading these
emails, b) you don't care about these issues, c) you don't want to talk
about them or  d) you don't know what to say.

e) Your employer has a company policy against such participation.
-- 
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


Re: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, User vs Admin risk profile, and browsers coded in 100% Managed Verifiable code

2006-03-25 Thread ljknews
At 11:39 AM + 3/25/06, Dinis Cruz wrote:

 3) Since my assets as a user exist in user land, isn't the risk profile
 of malicious unmanaged code (deployed via IE/Firefox) roughly the same
 if I am running as a 'low privileged' user or as administrator? (at the

If the administrator's assets are compromised, all users of the system
will have their assets compromised.

 end of the day, in both cases the malicious code will still be able to:
 access my files, access all websites that I have stored credentials in
 my browser (cookies or username / passwords pairs), access my VPNs,

Certainly users should not store credentials in software on a computer.

 attack other computers on the local network, install key loggers,

If one is not the administrator, there should be no way to install
software.  If there is, the operating system is underprotected.

 establish two way communication with a Internet based boot net, etc ...

At least one aspect of that is a design defect in TCP/IP, allowing
unprivileged users to create a port to receive inbound connections.
Other networking protocols avoid that flaw.
-- 
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


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

2006-03-06 Thread ljknews
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


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

2006-03-06 Thread ljknews
At 6:04 AM -0800 3/6/06, Jeremy Epstein wrote:

 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.

I cannot think of any other _network_ security mechanisms that do not
also apply to securing a single multiuser machine.
-- 
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


[SC-L] Where to read about construction quality software

2006-02-07 Thread ljknews
The US Department of Homeland Security seems to be sponsoring a web site
at https://buildsecurityin.us-cert.gov/portal/ , devoted to construction
of quality software.

But feeding that URL to http://validator.w3.org/ produces a list of 277
HTML errors on that software quality page :-)

No, I don't go checking such stuff just to be ornery - it produced a blank
screen on the first browser I tried.
-- 
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


Re: [SC-L] Intel turning to hardware for rootkit detection

2005-12-14 Thread ljknews
At 1:33 AM -0800 12/14/05, Crispin Cowan wrote:
 Smashguard, if I recall correctly, offers approximately the protection
 of existing compiler methods, but with the added fun of requiring
 modified (non-existent) hardware.
 
 The referenced hardware in the IEEE article and the intel.com pages
 appears to be some descendant of Palladium; it is a hardware integrity
 checker/attestation mechanism. A small, hardware-enforced core performs
 a chain of crypto-checks prior to boot strapping the BIOS, and then the
 OS, and makes itself available to applications. Thus an application can
 (more or less) prove to a remote machine that the BIOS, kernel, and
 application are in fact the approved versions that the remote machine
 wants to see. The closest published work would be Bill Arbaugh's
 dissertation and associated papers.

That sounds very much like DEC's Distributed Systems Security Architecture,
which was never an implemented product.  
-- 
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


Re: [SC-L] Intel turning to hardware for rootkit detection

2005-12-13 Thread ljknews
At 9:28 AM -0800 12/13/05, Ron Forrester wrote:
 On 12/13/05, Kenneth R. van Wyk [EMAIL PROTECTED] wrote:
 The detection mechanism seems to primarily be looking primarily for non-OS
 software modifying OS inhabited memory blocks.  Wonder how they're definining
 (and maintaining the definition) of each...  I also wonder how it'll impact
 near-OS software installations like, say, device drivers, authentication
 plug-ins, and other things that need to poke pretty deeply into the OS in
 order to install.
 
 I have to admit, when I initially read about this I immediately
 dismissed it as nothing but marketing hype -- what little details they
 gave for the solution seemed to me to be less than practical and
 certainly would have issues adapting to targeted attempts to deceive
 the mechanism.
 
 I'd love to hear other peoples thoughts on the matter.

For a test of their generalized characterization of the problem,
consider how well they might do analyzing VMS running on Itanium.

If the non-OS software attempted to trick the OS software into
doing something from an inner mode, their external approach seems
intractable.  On the other hand, non-OS software calls to OS
software regularly result in changes to memory protected against
outer mode access.
-- 
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


Re: [SC-L] New TC poll: Was Lynn right?

2005-08-09 Thread ljknews
At 11:54 AM +0100 8/9/05, Nick Murison wrote:
 (Yes, this is a shameless plug)
 
 Good morning everyone,
 
 Seen as the storm after BlackHat has settled a little, I thought it'd be nice
 to see what people had decided about Michael Lynn's presentation.  Was he
 right to go ahead with it, or was it really not his call?
 
 Judging from the security mailing lists, everyone and their dog has now had
 the opportunity to ramble on about the finer details of the situation.  At
 www.ThreatsAndCountermeasures.com, we just want some straight answers, so we
 made it the topic of our latest poll :)
 
 So go along to https://www.threatsandcountermeasures.com and submit your
 vote:
 
 Was Lynn right to hold his BlackHat talk?
 a) Yes, information should be free
 b) Yes, to safeguard infrastructure
 c) No, to safeguard infrastructure
 d) No, he violated IP
 e) Don't care

You omitted:

  f) Not enough information provided to know what on earth you are discussing.
-- 
Larry Kilgallen

[Ed. *grin*  There were numerous media accounts of the uproar that Michael Lynn
generated at the BlackHat conference a week+ ago by disclosing a heap overflow
vulnerability (that can lead to execution of arbitrary code on a target system)
in Cisco's IOS. Check out 
http://www.esecurityplanet.com/patches/article.php/3524701 
for a short overview, for example.  KRvW]



Re: [SC-L] Spot the bug

2005-07-19 Thread ljknews
At 9:55 AM -0400 7/19/05, Mark Curphey wrote:
If you fancy yourself as a good code reviewer you can play spot the bug at
MSDN. They will be getting harder !

http://msdn.microsoft.com/security/

The overarching bug seems to be the assertion that there is only one bug,
since those offering comments found two right off.

The less excusable of the two bugs appears at first glance to be an
out of bounds reference to an array, but on reflection is an error
in choice of programming language.
-- 
Larry Kilgallen




RE: [SC-L] Credentials for Application use

2005-05-11 Thread ljknews
At 11:00 AM -0500 5/11/05, Gizmo wrote:
Maybe I don't fully understand the concept of Single Sign-On.

As I understand it, SSO allows a user to login to an application portal, and
all of the applications that user accesses via that portal know who the user
is and what rights they have within their respective application realms.  As
such, it is a front-end technology; the back-end applications don't know
anything about this.

That is _one_ (relatively insecure) method of implementing single sign-on.

The general definition of single sign-on is that a user only logs on once
to access a variety of computer applications.

For some applications, relying entirely on Microsoft's credentials is
adequate.

For some applications, relying on the TSO login is adequate.

For some applications, relying on Kerberos credentials is adequate.

etc.
-- 
Larry Kilgallen




RE: [SC-L] Credentials for Application use

2005-05-11 Thread ljknews
At 11:28 AM -0400 5/11/05, Goertzel Karen wrote:

Of course, and SSO is only as secure as (1) the assurance of the
credential on which it bases its authentication decisions (a static
password with an SSO is a really STUPID idea);

That depends on the security of the channel between the user and
the entity authenticating the password.  A fixed password used to
unlock a token by entering it into keys on the token is not bad.
Use the keyboard associated with a programmable computer, and you
increase the risks monumentally.
-- 
Larry Kilgallen




Re: [SC-L] Why Software Will Continue to Be Vulnerable

2005-05-02 Thread ljknews
At 8:05 AM -0400 5/2/05, Kenneth R. van Wyk wrote:

 Yet, despite that pessimistic outlook -- and the survey that
 forked this thread -- I do think that companies are demanding
 more in software security, even though consumers are not.

Companies value time spent on cleanup more than consumers do.
-- 
Larry Kilgallen




Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-12 Thread ljknews
At 4:21 PM -0400 4/11/05, Dave Paris wrote:
Joel Kamentz wrote:
 Re: bridges and stuff.

 I'm tempted to argue (though not with certainty) that it seems that the 
 bridge analogy is flawed
 in another way --
 that of the environment.  While many programming languages have similarities 
 and many things apply
 to all programming,
 there are many things which do not translate (or at least not readily).  
 Isn't this like trying to
 engineer a bridge
 with a brand new substance, or when the gravitational constant changes?  And 
 even the physical
 disciplines collide
 with the unexpected -- corrosion, resonance, metal fatigue, etc.  To their 
 credit, they appear far
 better at
 dispersing and applying the knowledge from past failures than the software 
 world.

Corrosion, resonance, metal fatigue all have counterparts in the
software world.  glibc flaws, kernel flaws, compiler flaws.  Each of
these is an outside influence on the application - just as environmental
stressors are on a physical structure.

Corrosion and metal fatigue actually get worse as time goes on.
Software flaws correspond more to resonance, where there is a
defect in design or implementation.
-- 
Larry Kilgallen




Re: [SC-L] Open Source failure analysis tool released for Linux

2004-10-15 Thread ljknews
At 8:23 AM -0400 10/15/04, Kenneth R. van Wyk wrote:

I believe that we don't do enough to analyze and learn from software failures.  

I believe the industry as a whole does plenty to analyze software
failures, particularly considering how little is done to avoid
those errors.  Added analysis in the face of near-zero remediation
would be useless.

How many times do we see buffer overflow as the cause, yet even on
this mailing list people still defend the use of languages that not
only permit but actually promote such errors.
-- 
Larry Kilgallen




Re: [SC-L] ComputerWorld interview with Theo de Raadt on Software Security

2004-09-10 Thread ljknews
At 10:37 AM -0400 9/10/04, Kenneth R. van Wyk wrote:
FYI, ComputerWorld is running an interesting interview with Theo de Raadt, on 
the state of software security, and OpenBSD in particular.  See 
http://www.computerworld.com.au/index.php/id;1498222899;fp;16;fpid;0 for the 
complete text.

He seems to never have hear of operating systems besides those that look
like Unix or come from Microsoft.
-- 
Larry Kilgallen




RE: [SC-L] Programming languages -- the third rail of secure coding

2004-08-02 Thread ljknews
At 2:25 PM +0930 8/2/04, Nick Lothian wrote:

What features make Ada safer than Java/C#? (I only have limited experience
with Ada but from memory there was nothing that jumps out at me as something
that Java lacks)

Quoting from Tucker Taft in

http://www.google.com/groups?selm=FD85Lq.Hyp.0.-s%40inmet.camb.inmet.com

 Integer conversion (casting) in Java is truncating.  Integer conversion in 
 Ada is value-preserving, with a run-time check on overflow (note that
 GNAT in some configurations suppresses overflow checks by default,
 which is naughty in some people's view ;-).  To get truncation in Ada,
 you need to use an explicit mod/rem or Unchecked_Conversion.

Markus Kuhn has a general comparison between Ada, Java and C++ at

http://www.google.com/groups?selm=77nhuv%2429c%243%40pegasus.csx.cam.ac.uk

Real-time aspects of Java garbage collection are discussed at

http://www.google.com/groups?selm=a3eaa964.0304162240.540962aa%40posting.google.com

Enumerated types are discussed at

http://www.google.com/groups?selm=sbrvtvgdcdjps866mbuonffsl816ucgipd%404ax.com

Comparing the Ada protected object to the Java monitor

http://www.google.com/groups?selm=82347202.0305061140.53347ae1%40posting.google.com

and other synchronization issues

http://www.google.com/groups?selm=3D0CA980.5050505%40worldnet.att.net

Strong typing of scalars

http://www.google.com/groups?selm=254c16a.0305190830.21c61eca%40posting.google.com

Lack of generics means containers are not type-safe in Java

http://www.google.com/groups?selm=ba162549.0301052052.5a03f7a7%40posting.google.com

Reference to a general comparison document from ACT Europe

http://www.google.com/groups?selm=W0er9.42832%24qb.14876%40nwrddc01.gnilink.net


-- 
Larry Kilgallen




RE: [SC-L] Programming languages -- the third rail of secure coding

2004-08-01 Thread ljknews
At 1:03 PM +0930 8/1/04, Nick Lothian wrote:
 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.  

What are peoples opinions of the languages listed above?

Would I be overly controversial in saying:

C/C++: Unsafe (for most people)

It is possible to code correctly in (almost) any language,
but the likelihood of success varies.  To me the big issue
of C* languages has to do with what assurances _management_
has that the effort will result in correct code.

The C++ compilers I know of allow a programmer to drop into
raw C, and given the low level of understanding safety and
security issues across the programming population there will
be a strong temptation to do that.

Java/C#: Reasonably safe (both provide protection against buffer overflows,
are type safe and provide built-in security mechanisms)
FORTRAN/COBOL: Don't know - my impression is that COBOL is fairly safe
Scripting Languages: Depends on the language. Lack of type safety can be a
problem, but on the other hand they are usually safe from buffer overflows
and the fact they you can do a lot more in fewer lines of code can make the
code safer by making errors more obvious.

Are there other languages in widespread use (ie, the language must be used
more than - say - Python) that are safer than those listed above? 

Certainly Ada is a lot safer than those above, and the SPARK subset
we have discussed here is even safer (not just by being a subset but
also by supporting proofs of correctness).  SPARK is much less widely
deployed that whatever was used to implement Internet Explorer, but I
have strong preference as to which of the two I would want used in the
programming of fly-by-wire for an airplane on which I fly.
-- 
Larry Kilgallen


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

2004-07-30 Thread ljknews
coding
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: Secured by aspStation
Sender: [EMAIL PROTECTED]
Precedence: bulk
Mailing-List: contact [EMAIL PROTECTED] ; run by MajorDomo
List-Id: Secure Coding Mailing List sc-l.securecoding.org
List-Post: mailto:[EMAIL PROTECTED]
List-Subscribe: http://www.securecoding.org/list/
List-Unsubscribe: http://www.securecoding.org/list/
List-Help: http://www.securecoding.org/list/charter.php
List-Archive: http://lists.virus.org
Delivered-To: mailing list [EMAIL PROTECTED]
Delivered-To: moderator for [EMAIL PROTECTED]

At 3:14 PM -0400 7/30/04, Jeremy Epstein wrote:

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.

The problem is that some people persist in using less-safe languages for
new code.  When put into a discussion (here) with those who say Use the
best tool, a non-conversation takes place.

If the list were retitled to be Secure Coding in Unsupportive Languages
or Secure Coding with Approprate Languages then half of us would leave
and the rest could actually conduct a discussion.
-- 
Larry Kilgallen



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

2004-07-14 Thread ljknews
At 10:39 AM -0700 7/14/04, Blue Boar wrote:
ljknews wrote:

 At 11:38 AM -0700 7/13/04, Blue Boar wrote:
 
ljknews wrote:

The environment with which I am most familiar is VMS, and tradition
is what guides secure interfaces.  Inner mode code _must_ probe any
arguments provided from an outer mode, probe the buffers specified
by descriptors provided, etc.

What do you do when you're handed a bad pointer?
 
 Return SS$_ACCVIO.

So you put in an error handler that catches access ciolation before you try to use 
the pointer?  OK, fair enough.  What if the pointer points to memory you own, but not 
the right kind?

The inner mode code probing ensure that the calling mode has the ability
to read and/or write the memory (according to the semantics of the particular
interface.

The inner mode code does not distinguish between stacks and various heaps,
just that the memory is readable or writable by the calling process in the
mode from which the call is made.

 I have always been under the impression that raw pointers could always cause you 
 problems.  I've assumed that a secure language would have to eliminate that as a 
 type.

As have I.
-- 
Larry Kilgallen




Re: [SC-L] Risk Analysis: Building Security In #3

2004-07-13 Thread ljknews
At 5:30 PM -0600 7/12/04, Jared W. Robinson wrote:
I read the paper, and found it interesting. I read the statistic 50
percent of security problems are the result of design flaws. Where does
that number come from? Experience?

I would say it comes from sloppy wording.

At best, the author might discuss 50 percent of security problems
discovered to date
-- 
Larry Kilgallen




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

2004-07-12 Thread ljknews
At 3:55 PM -0700 7/10/04, Crispin Cowan wrote:

 However, I think I do see a gap between these extremes. You could have
 a formal specification that can be mechanically transformed into a
 *checker* program that verifies that a solution is correct, but cannot
 actually generate a correct solution.

Isn't that pretty much what the SPARK Inspector does ?
-- 
Larry Kilgallen




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

2004-07-09 Thread ljknews
At 8:49 AM -0500 7/9/04, Wall, Kevin wrote:

   If a GENERAL PURPOSE programming language were designed by
   scratch by someone who was both a security expert and
   programming language expert, what would this language (and
   it's environment) look like?

   More specifically,

  + What set of features MUST such a language support (e.g.,
strong static typing, etc.)?

Such typing should include specification by the programmer of the range
of values allowed in variables: -32767 to +32767, 0 to 100, 1 to 100,
Characters a-z only, characters A-Z only, -10.863 to +4.368, etc.

The language should also support exact specification of arithmetic
operations to be performed for various types (overflow semantics,
precision, decimal vs. binary arithmetic, etc.).  This is important
to ensure the desired behavior is obtained when one changes to a
new compiler/interpreter, if only to have a program rejected as
requiring behavior not supported on the new compiler or operating
system.

  + Perhaps just as importantly, what set of features should
the language omit (e.g., pointer arithmetic, etc.)?
  + What functionality should the accompanying libraries support
(e.g., encryption, access control, etc.)?
  + What would be the optimal paradigm (from a theoretical, rather
than pragmatic perspective) that such a language would fit into
(e.g., object-oriented, functional, imperative, logic programming,
etc.)? [Note: I mention theoretical, rather than pragmatic so
that such a language would be unduly influenced by the fact that
presently developers familiar with OO and imperative styles vastly
out number all the others, with functional coming up a distant
3rd.]
  + (Related to the previous item) Would such a language be compiled
or interpreted or something in between.

-- 
Larry Kilgallen




RE: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

2004-07-09 Thread ljknews
At 2:26 PM +0100 7/9/04, David Crocker wrote:

 And much as I dislike Ada, I have to admit that if you don't
 intend to use dynamic binding and don't need the low-level features of C,...

Which are those low-level features not available with Ada ?

The C compilers I have used claim to be ANSI-compliant but lack anything
equivalent to Ada's representation clauses.

-- 
Larry Kilgallen




Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

2004-07-07 Thread ljknews
At 9:40 AM -0400 7/7/04, James Walden wrote:
Dana Epp wrote:

 Of course, I also think students should have to take at least one course in ASM to 
 really understand how computer instructions work, so they can gain a foundation of 
 learning for the heart of computer processing. And
 I think they should be taught the powers and failures of C. Since I know many of 
 you think I'm nuts for that, you might want to look at this outline with the same 
 amount of consideration.

I agree with you on both of those requirements.  You need to have a basic 
understanding of assembly and how C is translated into assembly to understand the 
most common types of buffer overflow attacks.  There are better languages for secure 
programming than C, but students are almost certainly going to have to read or write 
C at some point in their careers, so they need to understand it.

What is wrong with this picture ?

I see both of you willing to mandate the teaching of C and yet not
mandate the teaching of any of Ada, Pascal, PL/I etc.

This seems like the teaching of making do.
-- 
Larry Kilgallen




Re: [SC-L] ACM Queue article and security education

2004-07-02 Thread ljknews
At 1:02 PM -0700 7/1/04, Blue Boar wrote:
ljknews wrote:
 I think it will be properly considered when the most strict portion
 of the software world is using language X.   I have used many
 programs where the flaws in the program make it clear that I care not
 one whit about whether the authors of that program have opinion about
 anything I might use. They are simply not competent, either as
 individuals or else as an organization.

 By most strict portion, do you mean people that care most about correct
 code, proofs, and such?

And organizations that hire the people you describe below to test the
software they build.

 I don't deny that the bulk of the heavy lifting will be done by people
 well-qualified to do so.  However, I'm of the school of thought that
 certain types of people who like to break things, and whose chief skill
 is breaking things, will always have a decent shot at finding a problem.
 There are people who couldn't build it, but they can sure break it.

 You don't typically get their attention until something is really,
 really popular.

Lots of people bring their attention to issues they are paid to test.
-- 
Larry Kilgallen




Re: [SC-L] ACM Queue article and security education

2004-07-01 Thread ljknews
At 9:10 AM -0700 7/1/04, Blue Boar wrote:

Language X may very well be a much better starting point, I don't know.  I do believe 
that it will never be properly looked at until the whole world starts using it for 
everything, though.

I think it will be properly considered when the most strict portion of the
software world is using language X.   I have used many programs where the
flaws in the program make it clear that I care not one whit about whether
the authors of that program have opinion about anything I might use. They
are simply not competent, either as individuals or else as an organization.
-- 
Larry Kilgallen




Re: [SC-L] ACM Queue article and security education

2004-06-30 Thread ljknews
At 8:10 PM -0400 6/29/04, James Walden wrote:

While there are non-university classes and workshops that teach software security, I 
doubt that a majority of developers have attended even one such class.  Software 
security has to be integrated into the CS curriculum before we can expect a majority 
of developers to have the appropriate skills, and then there will still be the issue 
of applying them under deadline pressure.

That said, I agree with most of the article.  We can't wait for years to software 
security to become a standard part of the curriculum, and most of his suggestions, 
such as turning C compiler warnings into errors, are good ideas no matter what the 
current status of security education.  I also second his enthusiasm for perl's taint 
mode.

Teaching students how to avoid problems in C should be a separate (optional)
course.

Dealing with issues that have _not_ been solved in higher level languages
should be a required course not burdened by the baggage of C.

And whether something is a warning or an error is outside the scope
of the programming language itself and into the build process which would
allow completion in the face of warnings.


RE: [SC-L] Interesting article on the adoption of Software Security

2004-06-11 Thread ljknews
At 9:16 AM -0500 6/11/04, Michael S Hines wrote:

 IBM had Language Environment (LE) before .NET come along.  

What is Language Environment (for either of those) ?




Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

2004-06-09 Thread ljknews
At 9:11 AM -0400 6/9/04, Gary McGraw wrote:
Language makes a huge difference, eapecially in the realm of bugs.  So not using C 
and C++ is smart.  Use Java or C# instead.

Or Ada, or PL/I, or Pascal, or Eiffel, etc.

There are _lots_ of choices out there.




Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

2004-06-08 Thread ljknews
At 1:10 PM -0400 6/8/04, Jose Nazario wrote:
thought some of you may find this editorial from the May 04 ACM Queue
worth a read. ACM Queue is an interesting magazine and has a website at
acmqueue.org.

Buffer Overrun Madness

ACM Queue vol. 2, no. 3 - May 2004
by Rodney Bates, Wichita State University

Why do good programmers follow bad practices?

In January 2003, the Slammer worm was reported to be the fastest spreading
ever. Slammer gets access by exploiting a buffer overrun. If you peruse
CERT (Computer Emergency Readiness Team) advisories or security upgrade
releases, you will see that the majority of computer security holes are
buffer overruns. These would be minor irritations but for the world's
addiction to the weakly typed programming languages C and its derivative
C++.

And yet this mailing list, supposedly devoted to secure coding,
seem polarized around the notion of shoring up those languages.




Re: [SC-L] Change of position

2004-04-01 Thread ljknews
At 10:09 AM -0500 4/1/04, Gary McGraw wrote:
Hi all,

I have done lots of soul searching lately and have come to the
conclusion that trying to make software secure is not worth the effort.
I think instead we should concentrate more effort on protection
technologies such as advanced stateful firewalls, intrusion detection
mechanisms, host-based behavior control, and above all policy.  We
simply can't make software work effectively in a cost effective manner.

I hope all of you will agree.  

I realize it is April Fools day, but all the host-based behavior
control I have encountered is implemented by operating system software.
If that software cannot be made secure, there is no hope.

The major timewasting I see in software security is the leap of faith
from:

theoretically, safe code can be written in any language

to:

using any language to write safe code can be done within
real-world economic constraints.


[SC-L] Re: Application Sandboxing, communication limiting, etc.

2004-03-10 Thread ljknews
At 11:14 AM -0700 3/10/04, Jared W. Robinson wrote:

Seems to me that the average user application doesn't need to open
TCP/UDP ports for listening.

Fixed in a previous major protocol stack.

Doing the equivalent on DECnet requires privilege.




RE: [SC-L] Any software security news from the RSA conference?

2004-03-01 Thread ljknews
At 5:58 PM -0600 2/27/04, Alun Jones wrote:

Microsoft has a lot of code to contend with, and much of it is old - so a
lot of it has had to be scrubbed clean of imperfections, and some has had to
be re-written.

A few years ago I heard the problem described as the opposite - that for
Windows V.something about 30% of the existing code was entirely replaced
(compared to corrected), which is more than _any_ organization can handle
safely on a project of that size.