Re: [SC-L] Compilers
| ...P.S. Please watch for the unfortunate word wrap in the URL of my | original post. The broken link still works but goes to thw wrong place! Now, *there's* an interesting hazard! One can imagine some interesting scenarios where this could be more than "unfortunate". At the least, it could be (yet another) way to hide the true target of a link. -- Jerry ___ 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
Hi all, Very good questions. I think a service like the one you describe would be useful mostly as a way of identifying the depth of the problem. Simply wielding a tool as a consultant does nothing to train the guys creating bugs not to do so in the future...and so the market will correct that over time in an efficient way. But the fact remains that many potential customers and users of static analysis tools have no idea how much of a mess they have. An outsourcing approach could help with that. They'll find out they need em. I believe so strongly in the "do anything to get started" thing that I also endorse the use of (really amazingly silly) application security testing tools. I call these badnessometers (see chapter 1 of "software security"...and ken's slides for that matter). But knowing that your web code sucks is better than remaining completely clueless. In the end, tool integration *into dev* is the key to success with static analysis. Many of our customers are having huge enterprise-wide success because they are learning to use, feed, tune, and train dev about these tools. The best are recycling the things they learn about their code back into training (and into better rules to enforce). gem company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com. -Original Message- From: McGovern, James F (HTSC, IT) [mailto:[EMAIL PROTECTED] Sent: Tue Jan 02 12:23:50 2007 To: sc-l@securecoding.org Subject:[SC-L] Building Security In vs Auditing 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 - It didn't mention any notion of training all developers within the outsourcing firm on secure coding practices - It did hint that one time periodic audits from a metrics perspective would be useful to clients that wanted this new service but didn't say how developers would be able to iterate on the code and reduce bugs. I would think that any offering that removes developers from the feedback loop while developing code and instead focusing on management-oriented (non-developer metrics) is generally a bad idea. - It didn't mention even how many folks from their security practice were to receive training in secure coding practices - Should we think of security as an extra "service" or something that should be incorporated into the SDLC in a consistent sustainable manner? I am far offbase and drunk too much of Ken Van Wyk's Kool-aid from his wonderful training course by thinking that this type of initiative does more harm than good? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php 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. ___ 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 f
Re: [SC-L] Compilers
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of ljknews > Sent: 02 January 2007 14:20 > To: Secure Coding > Subject: Re: [SC-L] Compilers > > At 2:18 PM + 1/2/07, Peter Amey wrote: > > [snip] > > > > > > 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, I don't think I was intending to disagree with you! The right languages /allow/ demonstrable secure coding. Conversely, without them, secure coding is reduced to a fairly weak coding standard level. Peter P.S. Please watch for the unfortunate word wrap in the URL of my original post. The broken link still works but goes to thw wrong place! ___ 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
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
Florian Weimer: > > 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 .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.) With NFS over UDP under heavy load, operations can succeed and return an error result anyway. When the server's reply is lost, the client retransmits the request. That is no problem with idempotent operations such as read or write that can be repeated an arbitrary number of times without changing the state of files. However, with non-idempotent operations such as mkdir, create, link, remove or rename, a retransmitted operation will fail (file exists, file not found). To remedy these false errors, the server maintains a cache of recent RPC replies to skip repeated operations; this RPC reply cache is finite and non-persistent across reboot. Application programmers can program around many but not all of these false errors. In particular there is no workaround for false failure of open(..O_CREAT|O_EXCL..). With the deployment of NFS over TCP these errors are less likely to happen. Wietse ___ 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] Building Security In vs Auditing
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 - It didn't mention any notion of training all developers within the outsourcing firm on secure coding practices - It did hint that one time periodic audits from a metrics perspective would be useful to clients that wanted this new service but didn't say how developers would be able to iterate on the code and reduce bugs. I would think that any offering that removes developers from the feedback loop while developing code and instead focusing on management-oriented (non-developer metrics) is generally a bad idea. - It didn't mention even how many folks from their security practice were to receive training in secure coding practices - Should we think of security as an extra "service" or something that should be incorporated into the SDLC in a consistent sustainable manner? I am far offbase and drunk too much of Ken Van Wyk's Kool-aid from his wonderful training course by thinking that this type of initiative does more harm than good? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php 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
I think my perspective is not just about overlap in terms of an abstract syntax tree but more in terms of usability. Security warnings should appear inline with other types of warnings from a developers perspective. When the information is presented separately, it will be an opportunity to ignore. It is harder to ignore compiler output. Likewise, one of the lifecycle oriented things I have seen in several shops is that source code gets moved through environments and gets recompiled. So if I check in code to the integration environment, the build "tool" will extract and compile. Likewise, when code gets promoted to say QA environment, the code is extracted again and recompiled. This allows for build tools that emit metrics and track warnings in a centralized place to take advantage of security considerations as well. Of course, some shops when they promote code move binaries which invalidates the above. -Original Message- From: Temin, Aaron L. [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 1:38 PM To: McGovern, James F (HTSC, IT); Secure Coding Subject: RE: [SC-L] Compilers It would be worth knowing more about the basis you use for drawing the conclusion, but if it's just the overlap between compilers and static analyzers represented by the abstract syntax tree, I don't think that's enough to warrant building one into the other (it might argue for having a shared parser, but I don't think parsers are hard enough to build to make that worthwhile). I would also suggest that looking for security weaknesses fits more into the unit testing part of development rather than the compiling part. As for "standalone," I think Jtest is built as an Eclipse plug-in; I don't know if you'd consider that standalone or not, but at least the developer doens't have to start up another shell to run it. Also, depending on the customer's organization, it might not be the developer who is running the security static analysis. I was talking with an organization that was thinking of having the security group run the static analysis, as part of the acceptance phase of an iteration. - Aaron _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James F (HTSC, IT) Sent: Thursday, December 21, 2006 10:31 AM To: Secure Coding Subject: [SC-L] Compilers I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what large vendors ignore, how far off base in my thinking am I? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php 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
[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. What SPARK allows is very effective secure coding (what this list is all about). There is an entry on this subject on the Build Security In website: https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/sdlc/61 3.html. regards Peter ___ 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
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] temporary directories
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 .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 ). > > 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] temporary directories
> 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 .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 ). 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-/ > 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. ___ 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
[MJoderator: This is likely beyond the point of general interest to sc-l] On Fri, 29 Dec 2006, ljknews wrote: | Date: Fri, 29 Dec 2006 20:49:01 -0500 | From: ljknews <[EMAIL PROTECTED]> | To: sc-l@securecoding.org | Subject: Re: [SC-L] temporary directories | | 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. The way one would get the effect of TMD on Unix is to create the file normally and, while keeping a descriptor open on it, delete it. The file will then "live" and be completely usable to this process or to any other process that either (a) already has it open (legitimately or because they snuck in on the race condition); (b) receives the open dexriptor by inheritance after a fork(); (c) receives the open descriptor by an explicit pass through a Unix-mode socket (a relatively little used facility). However, no one would be able to find the file through any file system entry, and no user-land code could get to it through its inode number even if it got its hands on that number. | > 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 .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 think the last VMS version I actively used was 5.4 or so. | 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 .CREATE . The Ada implementation | could rely on exclusive access to the file (surely Unix has that, right?) Not typically, no. (There are extensions, but standard Unix has only advisory locking - i.e., locking enforced between processes that choose to make locking calls.) | coupled with whatever Unix has that passes for the FAB$V_DLT bit to | delete the file on Close (such as at ). There's no direct analogue. Unix inode's are reference-counted - a directory entry is a reference. There's no explicit way to delete a file - all you can do is get rid of all the references you can. If that gets the ref count down to 0, the file will disappear "eventually". (There's a separate count of open file descriptors to implement that "sticks around while open" semantics.) | 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.) 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.) -- Jerry | -- | 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
[SC-L] Luis Miras on automated exploit detection in binaries at CCC
CCC was amazing, and here is the video for one of the lectures. http://video.google.com/videoplay?docid=-5897236579900914407&q=23c3 ___ 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
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. ___
