Re: [SC-L] has any one completed a python security code review`

2010-04-07 Thread Pascal Meunier
On Mon, 5 Apr 2010 11:08:47 -0500
Matt Parsons mparsons1...@gmail.com wrote:

 Has anyone completed a python security code review?  What would you
 look for besides inputs, outputs and dangerous functions?   Do any of
 the commercial static code analysis vendors scan that code?  I would
 think not because python is not compiled at run time like the other
 languages that static analysis tools can scan.  Any help would be
 greatly appreciated.   
 

I have, on software needing to run with elevated privileges at times.
All the well-known issues with filesystem operations are still there
(symlink attacks, file permissions).  As with any program, a Python
program operating with elevated privileges in a shared folder (/tmp) or
folder under another user's control is a dangerous proposition.  There
can be bugs that in some circumstances can become resource exhaustion
vulnerabilities, for example a file descriptor leak if you use the low
level file operations (in os).  There can also be log pollution issues
and poor randomness issues (sometimes not in the Python code itself,
but in SQL). On a server-type system, multiple similar commands can
create concurrency issues (race conditions), and the absence of rate
limitation on expensive operations can create DoS vulnerabilities. All
these were found the old fashioned way, with a code audit.

Pascal Meunier
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


Re: [SC-L] CERIAS : Beware SQL injections due to missing prepared statement support

2009-07-30 Thread Pascal Meunier
Actually it's not vulnerable because the strings are escaped first.  My point 
is simply that using prepared statements would have been more robust than 
escaping strings on the client side.  I'm sorry I didn't make that clear, I'll 
go edit my post now.

Thanks!
Pascal

Kenneth Van Wyk wrote:
 Here's one for the daily UGH!
 
 Great points raised by Pascal Meunier (see below) about poorly
 implemented language support for Prepared Statement SQL calls.  In
 particular, Python's pyPGSQL actually takes its prepared statement and
 translates internally to an old-style concatenated string query, thereby
 opening itself up to various SQL injection vulnerabilities.
 
 http://www.cerias.purdue.edu/site/blog/post/beware_sql_injections_due_to_missing_prepared_statement_support/#When:16:32:23Z
 
 
 Interesting article, Pascal.  Thanks!
 
 Cheers,
 
 Ken
 
 -
 Kenneth R. van Wyk
 KRvW Associates, LLC
 http://www.KRvW.com
 
 (This email is digitally signed with a free x.509 certificate from
 CAcert. If you're unable to verify the signature, try getting their root
 CA certificate at http://www.cacert.org -- for free.)
 
 
 
 
 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
 as a free, non-commercial service to the software security community.
 ___

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Lateral SQL injection paper

2008-04-29 Thread Pascal Meunier
If I understand this correctly, it's difficult to exploit because if you can 
alter database types, you probably can send arbitrary SQL statements to the 
database somehow already.  In that case, what extra capabilities does this 
attack give you?  

When I design applications using Postgresql, I define a client role that can 
only execute stored procedures (and nothing else) that were defined by another 
definer role with limited privileges (e.g., not create or drop tables, and 
certainly not redefine types...), and those procedures are executed with the 
privileges of the definer (EXTERNAL SECURITY DEFINER;).  So, the client is 
quite constrained in its capabilities.  Wouldn't the application of this scheme 
to an Oracle back-end prevent this attack?  If so then it's not just a question 
of input validation, but of proper and careful configuration of database roles. 
 

Isn't this something that Oracle could fix relatively easily?  For example, 
by forbidding the redefinition of fundamental database types by default in new 
roles?  This would be an application of the principle of secure defaults.  That 
functionality could even be phased out eventually, as I can't imagine that it's 
needed much if at all.  Usually when one claims a class of vulnerabilities, 
this is something that can't be fixed in a language or technology, and that 
becomes the responsibility of developers.  I find it strange to claim a new 
class of vulnerability when it's something peculiar to Oracle that can likely 
be fixed by Oracle itself so it's more like an Oracle bug.  This sounds perhaps 
worthy of a CVE entry (a vulnerability in Oracle) but not a CWE entry (a class 
of vulnerabilities).  I agree that doing validation at multiple layers can be 
beneficial, and that it is required when trust boundaries are crossed, but the 
importance of the find seems a little exaggerat
ed.

Regards,
Pascal Meunier


Kenneth Van Wyk wrote:
 Greetings SC-Lers,
 
 Things have been pretty quiet here on the SC-L list...
 
 I hope everyone saw David Litchfield's recent announcement of a new
 category of SQL attacks.  (Full paper available at
 http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf)
 
 He refers to this new category as lateral SQL injection attacks.  It's
 very different than conventional SQL injection attacks, as well as quite
 a bit more limited.  In the paper, he writes:
 
 Now, whether this becomes exploitable in the normal sense, I doubt
 it... but in very
 specific and limited scenarios there may be scope for abuse, for example
 in cursor
 snarfing attacks -
 http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf.
 
 In conclusion, even those functions and procedures that don’t take user
 input can be
 exploited if SYSDATE is used. The lesson here is always, always validate
 and don’t let
 this type of vulnerability get into your code. The second lesson is that
 no longer should
 DATE or NUMBER data types be considered as safe and not useful as
 injection vectors:
 as this paper has proved, they are. 
 
 
 It's definitely an interesting read, and anyone doing SQL coding should
 take a close look, IMHO.  It's particularly interesting to see how he
 alters the DATE and NUMBER data types so that they can hold SQL
 injection data.  Yet another demonstration of the importance of doing
 good input validation  -- preferably positive validation.  As long as
 you're doing input validation, I'd think there's probably no need to
 back through your code and audit it for lateral SQL injection vectors.
 
 Anyone else have a take on this new attack method?  (Note that I don't
 normally encourage discussions of specific product vulnerabilities here,
 but most certainly new categories of attacks--and their impacts on
 secure coding practices--are quite welcome.)
 
 
 Cheers,
 
 Ken
 
 -
 Kenneth R. van Wyk
 SC-L Moderator
 
 KRvW Associates, LLC
 http://www.KRvW.com
 
 
 
 
 
 
 
 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
 as a free, non-commercial service to the software security community.
 ___

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Coding with errors in mind - a solution?

2006-09-01 Thread Pascal Meunier



On 8/31/06 8:05 PM, mikeiscool [EMAIL PROTECTED] wrote:

 On 9/1/06, Pascal Meunier [EMAIL PROTECTED] wrote:
 
 
 
 On 8/30/06 3:46 PM, Tim Hollebeek [EMAIL PROTECTED] wrote:
 
 
 What you've proposed are exceptions.  They do help (some) in separating
 the normal logic from error handling, but:
 
 (1) they often leave the job half done which has its own risks.
 writing exception safe code can be more of a nightmare than error
 checking.
 
 I can't help noticing...  In Ruby there's an ensure clause that allows you
 to bring closure to half-done operations.  Perhaps your point is that some
 languages have poor exception support, just like some languages don't
 provide safe string handling functions?
 
 His point, I think, is that if you wrap a series of statements in an
 try/catch block, you might not roll back every statement you needed
 to, or checked appropriate conditions.
 
 For example:
 try {
  openFile();
  getData();
  writeToFile();
  setSomeFlag()
  moveFile();
  deleteTempThings();
 } catch(Exception e){
  ...
 }
 
 Now obviously that's a statement that could be written far better, but
 the point is that with the lazy/bad/accidental-bug-producing
 programmer it might be common.

Ah, yes, I can see a bad (or under pressure) programmer lumping together the
handling of exceptions that should be handled separately, or making just one
giant try block so when there's an exception, even if you specify the type
there's still ambiguity as to where it came from and therefore can't handle
it properly.  That could be quite a mess.  Thanks.

Exceptions simplify the code? I don't think so. They also don't reduce
code duplication [per se] you need to add extra functions, etc, to do
that.

They can simplify the code because
-as previously mentioned by Tim, they separate error handling from normal
logic, so the code is easier to read (it is simpler from a human reader's
perspective).  I have found bugs in my own code by going from error handling
to exceptions -- it made the mistake plain to see.

-if an exception is handled several call layers above, you don't have to
copy/translate and relay the error at each layer, with the attached loss of
context and possible translation mistakes (error #3 in one layer/module may
mean something different in another...).  So, there's less (duplicated)
code.

-It is common (and bad, IMO) practice for errors to be signified to callers
by returning an out of range or different type (or null) value when
something else is semantically expected.  The result is that if the caller
forgets to check for errors, a bad value is used by the remaining code.  If
the caller checks for errors, an often used way to do this is to tuck the
assignment inside an if statement.  Then, even if the error is checked for,
subsequent code may assume that the assigned variable still contains a
semantically correct value (e.g., the previous value) which causes bugs and
possibly vulnerabilities (I remember seeing an instance of this).  So (and
for additional reasons that could be chalked up to coding style
preferences), a good practice is to decouple the error channel from the data
channel (e.g., pass additional variables by reference or use exceptions as
the error channel).  By passing a variable by reference, its value can be
left intact if there's an error in the called function (I *really* like to
have variables that always contain a semantically correct, or valid, range
and type).  Obviously passing additional variables by reference up and down
calling chains complicates the code, whereas exceptions are transparent.

As with most everything else, all this (simplifying the code and reducing
code duplication) depends on having a programmer with coding style and
skills that can take advantage of the provided opportunities.

Pascal


___
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] How can we stop the spreading insecure codingexamplesattraining classes, etc.?

2006-08-31 Thread Pascal Meunier
I take exception (haha!) at having them dismissed like this.  It sounds like
you encountered some badly written exception handling code.  Error handling
can also be really bad, where at every call layer the original error gets
filtered or translated to a point where you just know something went wrong
somewhere but have little idea what.  Then you have to trace (yuck) and
waste hours trying to identify the problem.  I'll take limited state over no
state any day (Ruby even tells you which line numbers of which files were
involved).  

Pascal

On 8/31/06 8:29 AM, Gary McGraw [EMAIL PROTECTED] wrote:

 as an industry we did manage to get
 rid of computed gotos, spaghetti code, etc., so maybe there's
 hope.
 
 ever heard of exceptions?  They're basically goto plus limited state.
 Spaghetti lives!
 
 gem
 
 company www.cigital.com
 podcast www.cigital.com/silverbullet
 book www.swsec.com
 
 
 
 
 
 This electronic message transmission contains information that may be
 confidential or privileged.  The information contained herein is intended
 solely for the recipient and use by any other party is not authorized.  If
 you are not the intended recipient (or otherwise authorized to receive this
 message by the intended recipient), any disclosure, copying, distribution or
 use of the contents of the information is prohibited.  If you have received
 this electronic message transmission in error, please contact the sender by
 reply email and delete all copies of this message.  Cigital, Inc. accepts no
 responsibility for any loss or damage resulting directly or indirectly from
 the use of this email or its contents.
 Thank You.
 
 
 ___
 Secure Coding mailing list (SC-L)
 SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 


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


Re: [SC-L] Coding with errors in mind - a solution?

2006-08-31 Thread Pascal Meunier



On 8/30/06 3:46 PM, Tim Hollebeek [EMAIL PROTECTED] wrote:

 
 What you've proposed are exceptions.  They do help (some) in separating
 the normal logic from error handling, but:
 
 (1) they often leave the job half done which has its own risks.
 writing exception safe code can be more of a nightmare than error
 checking.

I can't help noticing...  In Ruby there's an ensure clause that allows you
to bring closure to half-done operations.  Perhaps your point is that some
languages have poor exception support, just like some languages don't
provide safe string handling functions?

 
 (2) in many languages, you can't retry or resume the faulting code.
 Exceptions are really far less useful in this case.

See above.  (Yes, Ruby supports retrying).

 
 (3) you usually end up with some generic clean up code, which generally
 hides more errors than it solves.

I don't think that's fair.  Yes, you can write poor exception handling code,
but it's far easier to simply ignore or overlook errors or write poor error
handling code to the point where the error is effectively ignored (or
hidden) or the cause of the error becomes unidentifiable.  Exceptions
allow me to reduce code duplication (and lower the chance of inconsistent
treatment and bugs), simplify the code (which makes it easier to understand
and therefore audit) as well as handle problems at an appropriate layer in
the code. 

I'm not saying that exceptions are always the best way to handle things, but
they can be part of good programming practices.

Pascal Meunier

 
 Tim Hollebeek
 Research Scientist
 Teknowledge, Corp.
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Michael S Hines
 Sent: Wednesday, August 30, 2006 11:07 AM
 To: sc-l@securecoding.org
 Subject: [SC-L] Coding with errors in mind - a solution?
 
 a simple structure that provides for errors would go a long way...
  
 If - then - else - on error
 Do - end - on error
 Let x = y - on error
 Let x = function() on error
 etc...
  
 The problem is writing code without thinking of the possible
 errors that might arise.   This forces you to think about the
 consequences of executing a command...
  
 Where 'error' is doing something intelligent when the
 original command doesn't work...
  
 Just a brainstorm... any merit to it?
  
 Mike Hines
 [EMAIL PROTECTED]
 
 
 
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Ed Reed (Aesec)
 Sent: Wednesday, August 30, 2006 1:17 PM
 To: sc-l@securecoding.org
 Subject: [SC-L] e: How can we stop the spreading insecure
 coding examples at, training classes, etc.?
 
 
 
 Message: 1
 Date: Tue, 29 Aug 2006 15:48:17 -0400
 From: [EMAIL PROTECTED]
 Subject: Re: [SC-L] How can we stop the spreading
 insecure coding
 examples at training classes, etc.?
 To: Wall, Kevin [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED]
 Cc: SC-L@securecoding.org
 Message-ID: 
 [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED]
 Content-Type: text/plain; charset=ISO-8859-1
 
 Quoting Wall, Kevin [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] :
 
 
  
 
 I think that this practice of leaving out the security
 details to just make the demo code short and
 sweet has got
 to stop. Or minimally, we have to make the code
 that people
 copy-and-paste from have all the proper
 security checks even
 if we don't cover them in training. If we're
 lucky, maybe
 they won't delete them when the re-use the code.

 
 
 I agree, and would like to extend it: security should
 be discussed *at the same
 time* that a topic is.  Teaching security in a separate
 class, like I have been
 doing, reaches only a fraction of the audience, and
 reinforces an attitude of
 security as an afterthought, or security as an option.
 Comments in the code
 should explain (or refer to explanations of) why
 changing or deleting those
 lines is a bad idea.
 
 However, I'm afraid that it would irritate students,
 and make security the new
 grammar and spelling for which points are deducted
 from perfectly valid
 write-ups (i.e., it's my ideas that count, not how
 well I spell). 
 
 The same used to be said about unstructured programming
 examples (computed gotos, spaghetti code, multiple entry and
 exit points from functions, etc).  We got past it.
 
 We need a similar revolution in thought with regard to
 security, and some one to take the lead on providing clear,
 crisp examples of coding style that is more secure by its
 nature.  I don't have one handy - but that's my wish.
 
 Ed
 
 
 
 
 ___
 Secure Coding mailing list (SC-L)
 SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 


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

Re: [SC-L] Coding with errors in mind - a solution?

2006-08-30 Thread Pascal Meunier
Worse is when it works in unintended ways without producing an error.  The
code has to detect whenever something doesn't match a white list of expected
program states and inputs.  I think that in example code, the detection is
more important than the subsequent handling because the handling will vary
depending on the exact application requirements and framework.  The
detection is where contracts and correctness are verified, and I'd like to
leave the handling of violations to some law enforcement module, so to
speak.

Perhaps a good enough approach for teaching would be to raise an exception
(or use assert statements for languages that don't have exceptions) whenever
a problem is detected, and leave it at that.  This way, the handling of the
exception (logging, UI, aftermath, etc...) doesn't bloat the code and
distract from the main subject, yet all unsafe conditions and errors would
be highlighted and caught.  It's not revolutionary, but it's better than
what we have now.  Would it be good enough?  I can picture people deleting
those assert statements that just make their programs crash ;)

Pascal Meunier



On 8/30/06 2:07 PM, Michael S Hines [EMAIL PROTECTED] wrote:

 a simple structure that provides for errors would go a long way...
  
 If - then - else - on error
 Do - end - on error
 Let x = y - on error
 Let x = function() on error
 etc...
  
 The problem is writing code without thinking of the possible errors that
 might arise.   This forces you to think about the consequences of executing
 a command...
  
 Where 'error' is doing something intelligent when the original command
 doesn't work...  
  
 Just a brainstorm... any merit to it?
  
 Mike Hines
 [EMAIL PROTECTED]
 
   _  
 
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 On Behalf Of Ed Reed (Aesec)
 Sent: Wednesday, August 30, 2006 1:17 PM
 To: sc-l@securecoding.org
 Subject: [SC-L] e: How can we stop the spreading insecure coding examples
 at, training classes, etc.?
 
 
 
 Message: 1
 
 Date: Tue, 29 Aug 2006 15:48:17 -0400
 
 From: [EMAIL PROTECTED]
 
 Subject: Re: [SC-L] How can we stop the spreading insecure coding
 
 examples at training classes, etc.?
 
 To: Wall, Kevin  mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
 
 Cc: SC-L@securecoding.org
 
 Message-ID:  mailto:[EMAIL PROTECTED]
 [EMAIL PROTECTED]
 
 Content-Type: text/plain; charset=ISO-8859-1
 
 
 
 Quoting Wall, Kevin  mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]:
 
 
 
 
 
   
 
 I think that this practice of leaving out the security
 
 details to just make the demo code short and sweet has got
 
 to stop. Or minimally, we have to make the code that people
 
 copy-and-paste from have all the proper security checks even
 
 if we don't cover them in training. If we're lucky, maybe
 
 they won't delete them when the re-use the code.
 
 
 
 
 
 I agree, and would like to extend it: security should be discussed *at the
 same
 
 time* that a topic is.  Teaching security in a separate class, like I have
 been
 
 doing, reaches only a fraction of the audience, and reinforces an attitude
 of
 
 security as an afterthought, or security as an option.  Comments in the code
 
 should explain (or refer to explanations of) why changing or deleting those
 
 lines is a bad idea.
 
 
 
 However, I'm afraid that it would irritate students, and make security the
 new
 
 grammar and spelling for which points are deducted from perfectly valid
 
 write-ups (i.e., it's my ideas that count, not how well I spell).
 
 The same used to be said about unstructured programming examples (computed
 gotos, spaghetti code, multiple entry and exit points from functions, etc).
 We got past it.
 
 We need a similar revolution in thought with regard to security, and some
 one to take the lead on providing clear, crisp examples of coding style that
 is more secure by its nature.  I don't have one handy - but that's my wish.
 
 Ed
 
 ___
 Secure Coding mailing list (SC-L)
 SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php


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


Re: [SC-L] secure integer library

2006-08-17 Thread Pascal Meunier
Nice.  I'll mention it in my secure programming class this semester.  I'd be
interested in any exercises/labs based on it, appropriate for undergrads.

Cheers,
Pascal


On 8/17/06 10:04 AM, Robert C. Seacord [EMAIL PROTECTED] wrote:

 
 The CERT/CC has released a beta version of a secure integer library for
 the C Programming Language.  The library is available for download from
 the CERT/CC Secure Coding Initiative web page at:
 http://www.cert.org/secure-coding/
 
 The purpose of this library is to provide a collection of utility
 functions that can assist software developers in writing C programs that
 are free from common integer problems such as integer overflow, integer
 truncation, and sign errors that are a common source of software
 vulnerabilities.
 
 Functions have been provided for all integer operations subject to
 overflow such as addition, subtraction, multiplication, division, unary
 negation, etc.) for int, long, long long, and size_t integers.  The
 following example illustrates how the library can be used to add two
 signed long integer values:
 
 long retsl, xsl, ysl;
 xsl = LONG_MAX;
 ysl = 0;
 retsl = addsl(xsl,ysl);
 
 For short integer types (char and short) it is necessary to truncate the
 result of the addition using one of the safe conversion functions
 provided, for example:
 
 char retsc, xsc, ysc;
 xsc = SCHAR_MAX;
 ysc = 0;
 retsc = si2sc(addsi(xsc, ysc));
 
 For error handling, the secure integer library uses the mechanism for
 Runtime-constraint handling defined by TR 24731 Specification for
 Safer, More Secure C Library Functions available at:
 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1135.pdf
 
 The implementation uses the high performance algorithms defined by Henry
 S. Warren in the book Hacker's Delight.
 
 For more information on vulnerabilities and other problems resulting
 from the incorrect use of integers in C and C++ please read Chapter 5 of
 Secure Coding in C and C++ which is available as a free download from
 the CERT web site:
 
 http://www.cert.org/books/secure-coding/moreinfo.html
 
 Please address any defect reports, comments and suggestions concerning
 the Secure Integer Library or CERT Secure Coding Initiative to me.
 Thanks to Henry and to Juan Alvarado who coded the implementation.
 
 Thanks,
 rCs
 


___
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 Pascal Meunier


On 7/20/06 11:58 AM, Florian Weimer [EMAIL PROTECTED] wrote:

 * der Mouse:
 
 Absolute security is a myth.  As is designing absolutely secure
 software.
 
 I have high hopes in formal methods.
 
 All formal methods do is push bugs around.  Basically, you end up
 writing in a higher-level language (the spec you are formally verifying
 the program meets).  You are then subject to the bugs present in *that*
 program (the spec) and the bugs present in the compiler (the formal
 verifier).
 
 But people are forced to spend more time with the code, which
 generally helps them (in particular smart people) to eradicate bugs.
 Another way to achieve the same thing is to freeze the code base and
 let it mature over decades, but I don't see the business model for
 that.

Also, writing it twice with different languages, especially at different
levels of abstraction, makes it less likely that the same bugs will appear
in both.  You can choose the higher level language so that it has great
expressive power exactly for the things that are a pain to capture and
verify (and thus a source of bugs) in the lower-level language.  Last time I
checked, formal methods were even able to catch design errors in some
networking protocols.  But you're right, they are not absolutely perfect
because the tools and operators aren't, etc...  That doesn't mean they can't
help a great deal.  I have great hopes for their usefulness.  Maybe some day
they will help so much that the distinction between what they can produce
and absolutely secure software will become too small to matter.  Whether
we'll still be alive when that happens is another question.

Pascal



___
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 Pascal Meunier


On 7/20/06 1:57 PM, Gary McGraw [EMAIL PROTECTED] wrote:

 I'm afraid that's not true.  John Knight has a famous paper that shows that
 design/requirements bugs persist in n-version programming paradigms.  I'll let
 the interested people google that one up for themselves.
 
 gem

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.  For design/requirements bugs,
I'm reading:

Why Are Formal Methods Not Used More Widely?
John C. Knight Colleen L. DeJong Matthew S. Gibble Luís G. Nakano
Department of Computer Science
University of Virginia
Charlottesville, VA 22903

http://www.cs.virginia.edu/~jck/publications/lfm.97.pdf

and the evidence is that engineers presented with formal specifications were
able to spot many design errors (Validation by inspection was effective).
Therefore if you have a formal, high-level version it can be validated
better, and formal methods give proof that the lower-level code conforms.

I call that all-around better, and I'm hoping for more of it and better ways
to do it.  Now if you order a cat and needed a dog, nobody can help you.

Pascal


 
  -Original Message-
 From:  Pascal Meunier [mailto:[EMAIL PROTECTED]
 Sent: Thu Jul 20 13:54:42 2006
 To: Florian Weimer; der Mouse
 Cc: SC-L@securecoding.org
 Subject: Re: [SC-L] bumper sticker slogan for secure software
 
 
 
 On 7/20/06 11:58 AM, Florian Weimer [EMAIL PROTECTED] wrote:
 
 * der Mouse:
 
 Absolute security is a myth.  As is designing absolutely secure
 software.
 
 I have high hopes in formal methods.
 
 All formal methods do is push bugs around.  Basically, you end up
 writing in a higher-level language (the spec you are formally verifying
 the program meets).  You are then subject to the bugs present in *that*
 program (the spec) and the bugs present in the compiler (the formal
 verifier).
 
 But people are forced to spend more time with the code, which
 generally helps them (in particular smart people) to eradicate bugs.
 Another way to achieve the same thing is to freeze the code base and
 let it mature over decades, but I don't see the business model for
 that.
 
 Also, writing it twice with different languages, especially at different
 levels of abstraction, makes it less likely that the same bugs will appear
 in both.  You can choose the higher level language so that it has great
 expressive power exactly for the things that are a pain to capture and
 verify (and thus a source of bugs) in the lower-level language.  Last time I
 checked, formal methods were even able to catch design errors in some
 networking protocols.  But you're right, they are not absolutely perfect
 because the tools and operators aren't, etc...  That doesn't mean they can't
 help a great deal.  I have great hopes for their usefulness.  Maybe some day
 they will help so much that the distinction between what they can produce
 and absolutely secure software will become too small to matter.  Whether
 we'll still be alive when that happens is another question.
 
 Pascal
 
 
 
 ___
 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
 
 
 
 
 
 This electronic message transmission contains information that may be
 confidential or privileged.  The information contained herein is intended
 solely for the recipient and use by any other party is not authorized.  If
 you are not the intended recipient (or otherwise authorized to receive this
 message by the intended recipient), any disclosure, copying, distribution or
 use of the contents of the information is prohibited.  If you have received
 this electronic message transmission in error, please contact the sender by
 reply email and delete all copies of this message.  Cigital, Inc. accepts no
 responsibility for any loss or damage resulting directly or indirectly from
 the use of this email or its contents.
 Thank You.
 
 
 ___
 Secure Coding mailing list (SC-L)
 SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 



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


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

2006-07-20 Thread Pascal Meunier



On 7/20/06 3:46 PM, Florian Weimer [EMAIL PROTECTED] 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-)
 
 In most cases, the components that enforces the absence of buffer
 overflows are written in C.
snip

That's irrelevant.  What is important is that some magic formal tool could
say that some code in language A, where bug of type k is possible, is
not equivalent to the version in language B, where type k bugs are
impossible, ergo you have found a type k bug (in the absence of any other
bug in that section of code...).

I know someone is going to ask, why didn't you code it only in language B
then?, to which there can be many different answers, and I don't want to
get into that.


  For design/requirements bugs, I'm reading:
 
 Safety-critical software is a very different beast.  You can make much
 stronger assumptions about the environment.  It's not clear if the
 results apply to software security in open system.
 
 I'm not saying that formal methods have no value.  But I doubt that
 comparisons with projects at completely different
 dollars-per-line-of-code levels give immediate insights.

That's one of the things I'm hoping for:  that more and better formal
methods become more affordable and practical.  Spark, for example,
demonstrated that the costs of some formal methods were much lower than what
people expected, in real projects.  That gives me hope.

Pascal

 


___
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 Pascal Meunier



On 7/20/06 3:11 PM, Florian Weimer [EMAIL PROTECTED] wrote:

 * Pascal Meunier:
 
 Also, writing it twice with different languages, especially at different
 levels of abstraction, makes it less likely that the same bugs will appear
 in both.
 
 Algorithmic issues such as denial of service attacks through
 unbalanced binary trees or hash table collisions are pretty
 independent of the programming language and have been observed in many
 incarnations.
 
 If you implement the same protocol, it's likely that you end up with
 similar bugs.  The DNS compression loop bug was reinvented many times.
 The fundamental mismatch in OpenPGP between key certification (key
 plus user ID) and key usage (just the key alone) affected many
 independently developed implementations.  Chrome spoofing is
 ubiquitous in web browsers.
 
 Most things in this list are implemented in C or C++, but the problems
 are at such a high level that it's unlikely that a different choice of
 wildly different programming language would make a huge difference.
 If you look at lower-level bugs, such as buffer overflows, I hope that
 nobody still thinks that multiple code versions help -- just look at
 the long list (even after discounting direct code copies) of botched
 ASN.1 decoders.
 
 Some protocols are extremly hard to implement correctly, I'm afraid.
 (And not all protocols are unnecessarily complex.)
 

It's obvious that if you just translate a bad, complicated algorithm or
protocol from one language to the next, they'll all be bad.  It remains that
sometimes when you make people say something stupid twice they catch on the
second time, especially during code reviews, because they re-express the
code using natural language.  That's why I said, less likely.  It works
with some and not others.

Pascal


___
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-19 Thread Pascal Meunier



On 7/18/06 11:45 AM, Dana Epp [EMAIL PROTECTED] wrote:

 Or perhaps less arrogance in believing it won't sink.
 
 Absolute security is a myth. As is designing absolutely secure software.

I have high hopes in formal methods.

 It is a lofty goal, but one of an absolute that just isn't achievable as
 threats change and new attack patterns are found. Designing secure
 software is about attaining a level of balance around software
 dependability weighed against mitigated risks against said software to
 acceptable tolerance levels, while at the same time ensuring said
 software accomplishes the original goal... to solve some problem for the
 user. 
 
 On my office door is a bumper sticker I made. It simply says:
 
 0x5
 
 10 points to the first person to explain what that means.

Since you're at Microsoft I'll bet it's related to RPC Layer returned error
0x5 (Access is denied.) This may happen if host security is not installed.
http://support.microsoft.com/kb/216558/en-us

So it would be an oblique way of referring to host security.  If it was on a
motel-style door-handle card it could also mean do not disturb (send
visitors away with an access denied).  Perhaps, go away if you haven't
secured your system.  Who knows besides you ;)

Pascal

 
 
 Regards,
 Dana Epp 
 [Microsoft Security MVP]
 http://silverstr.ufies.org/blog/
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of SC-L Subscriber Dave
 Aronson
 Sent: Tuesday, July 18, 2006 7:53 AM
 To: SC-L@securecoding.org
 Subject: [SC-L] bumper sticker slogan for secure software
 
 Paolo Perego [mailto:[EMAIL PROTECTED] writes:
 
 Software is like Titanic, pleople claim it was unsinkable. Securing
 is   providing it power steering
 
 But power steering wouldn't have saved it.  By the time the iceberg was
 spotted, there was not enough time to turn that large a boat.  Perhaps
 radar, but that doesn't make a very good analogy.  Maybe a thicker
 tougher hull and automatic compartment doors?
 
 -Dave
 
 
 
 
 ___
 Secure Coding mailing list (SC-L)
 SC-L@securecoding.org
 List information, subscriptions, etc -
 http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 
 ___
 Secure Coding mailing list (SC-L)
 SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 


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


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

2006-07-17 Thread Pascal Meunier
I prefer to define the opposite:

Insecure Software is like a joke,
Except others laugh at you

I like it because:
-it captures the notion that vulnerabilities, just like jokes, are very
often made apparent by thinking in a different context from the software's
designers (the straight man).

-It conveys the notion that insecure software is shoddy;

-It conveys the notion that there are people who will find out that you run
insecure software;

-It may motivate some people to care about security by invoking social
stigma ;)


Cheers,
Pascal Meunier
Purdue University CERIAS



On 7/15/06 3:27 PM, Goertzel Karen [EMAIL PROTECTED] wrote:

 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?
 
 --
 Karen Mercedes Goertzel, CISSP
 Booz Allen Hamilton
 703-902-6981
 [EMAIL PROTECTED]
 ___
 Secure Coding mailing list (SC-L)
 SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php


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


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

2006-04-03 Thread Pascal Meunier
AppArmor sounds like an excellent alternative to creating a VMWare image for
every application you want to run but distrust, although I can think of
cases where a VMWare image would be safer.  For example, the
installer/uninstaller may have vulnerabilities, may be dirty (it causes
problems by modifying things that affect other applications, or doesn't
cleanup correctly), or phones home, etc...  I guess you could make a profile
for the installer as well (I'm not very enthusiastic about that idea
though).  Also, I suspect that what you need to allow in some profiles is
possibly sufficient to enable some level of malicious activity.  It's
regrettable that it is only available for Suse Linux.

Perhaps one of the AppArmor mailing lists would be more appropriate to ask
this, but as you posted an example profile with capability setuid, I must
admit I am curious as to why an email client needs that.  I tried looking up
relevant documentation on the Novell site, but it seems I was unlucky and
tried during a maintenance period because pages were loading erratically.  I
finally got to the 3.0 Building Novell AppArmor Profiles page but it was
empty.  I would appreciate receiving more information about it.  I am also
interested in the Linux Security Modules Interface.

Regards,
Pascal Meunier

On 4/2/06 6:49 PM, Crispin Cowan [EMAIL PROTECTED] wrote:

 This is exactly what AppArmor http://en.opensuse.org/Apparmor was
 designed for: conveniently confining applications to only be able to do
 what they need to do. Application's least privilege.
 
 I am running this mail client (Thunderbird) from within a sandbox (we
 call it a profile). I have attached this policy, which should be
 pretty self-explanatory.
 


___
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] eWeek: AJAX Poses Security, Performance Risks

2006-01-30 Thread Pascal Meunier
On 1/30/06 1:09 PM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote:

 Any AJAX experts here want to comment on the eWeek article cited below?
 
 http://www.eweek.com/article2/0,1895,1916673,00.asp
 
 It claims, among other things that, AJAX dramatically increases the amount of
 XML network traffic being transmitted, exposing applications to Web services
 vulnerabilities.
 
 Cheers,
 
 Ken van Wyk

AJAX bothers me strongly for none of the reasons mentioned, which are
curiously limited to the capabilities of the solution from the same
source as the alert.  AJAX:

- Forces people to open their browsers to potentially malicious client-side
scripts from other sites, unless users actively manage their IE zones (I've
rarely found people who even know how to use them) or use something like the
NoScript firefox extension (and even then it needs better SSL support as it
depends and trusts DNS unless you specify the fully-qualified url).
JavaScript is a notorious attack vector.  I have the same issue with Windows
Media Player 10 (the internet radio part requires JavaScript to work) and
any site that forces visitors to use JavaScript to access content.
Requiring JavaScript is unconscionable, security-wise, in my opinion.

- Tempts software developers to assume that it's their code that is running
on the client, and trust it with input validation, access control, and
sensitive values.  This is a repeated, typical mistake in client-side
scripting.  Why tempt people into doing stupid things?

Cheers,
Pascal


___
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