Re: [SC-L] has any one completed a python security code review`
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
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
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?
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.?
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?
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?
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
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
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
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
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
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
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
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
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
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
