Re: [SC-L] SC-L Digest, Vol 6, Issue 56
At 7:56 PM +0200 3/19/10, AK wrote: It is way easier for attackers to reverse engineer desktop applications than web applications. Assuming proper server configuration, it is next to impossible for an attacker to get the server side source code or compressed form (e.g WARs) for a web application and proceed with disassembly/decompilation/patching. Assuming proper _desktop_ configuration, the user does not have the ability to modify the programs they will execute, nor change the protections of objects on the system. http://nvd.nist.gov/fdcc/fdcc_faq.cfm Yes, physical access to a computer means ultimately it is possible to gain control, but the necessary measures to not constitute easier, and given control of one test machine it is not at all trivial to transfer that to control of another machine, especially if the machines are not connected to a common network. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] market for training CISSPs how to code (Matt, Parsons)
At 7:36 PM +0200 3/18/10, AK wrote: Who says so, in the context of web applications? I can see it (somewhat) from a desktop application perspective, but how is this relevant in web apps? Why should standards for a web application be different than for a desktop application ? -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] 2010 bug hits millions of Germans | World news | The Guardian
At 10:43 AM -0600 1/7/10, Stephen Craig Evans wrote: I am VERY curious to learn how these happened... Only using the last digit of the year? Hard for me to believe. Maybe it's in a single API and somebody tried to be too clever with some bit-shifting. My wife says that in the lead-up to the year 2000 she caught some programmers fixing Y2K bugs by continuing to store year numbers in two digits and then just prefixing output with 19 if the value was greater than some two digit number and prefixing output with 20 if the value was less than or equal to that two digit number. Never underestimate programmer creativity. Never overestimate programmer precision. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] 2010 bug hits millions of Germans | World news | The Guardian
At 2:37 PM -0600 1/7/10, Wall, Kevin wrote: Larry Kilgallen wrote... At 10:43 AM -0600 1/7/10, Stephen Craig Evans wrote: I am VERY curious to learn how these happened... Only using the last digit of the year? Hard for me to believe. Maybe it's in a single API and somebody tried to be too clever with some bit-shifting. My wife says that in the lead-up to the year 2000 she caught some programmers fixing Y2K bugs by continuing to store year numbers in two digits and then just prefixing output with 19 if the value was greater than some two digit number and prefixing output with 20 if the value was less than or equal to that two digit number. Never underestimate programmer creativity. Never overestimate programmer precision. While I never fixed any Y2K problems I worked next to someone who did for about 6 months. What you refer to is pretty much what I mentioned as the fixed window technique that was very common to those developers who were addressing the problems at the time. IIRC, it was a particularly popular approach for those who waited until the last moment to address Y2K issues in there systems because it still allowed for 2 digit year fields in all their forms and databases and output. Going back to the original Y2K issue, within the past 5 years my wife and I visited a friend of my late father. This friend had retired as somewhat of a bigwig at an industrial giant that formerly was in the business of manufacturing their own line of computers. He admitted that back in the day they had set up things to use two digits for storing year numbers, knowing that before the year 2000 came around, _they_ would all be retired. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Provably correct microkernel (seL4)
At 4:33 PM -0500 10/1/09, Wall, Kevin wrote: Professor Gernot Heiser, the John Lions Chair in Computer Science in the School of Computer Science and Engineering and a senior principal researcher with NICTA, said for the first time a team had been able to prove with mathematical rigour that an operating-system kernel -- the code at the heart of any computer or microprocessor -- was 100 per cent bug-free and therefore immune to crashes and failures. Reading nothing beyond what was posted, the problem I see is to provide a complete specification against which to prove correctness. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Inherently Secure Code?
At 8:47 AM -0700 8/27/09, Benjamin Tomhave wrote: Should any sort of overflow really be allowed? It is not, except by management decision (in choosing an unsafe language). -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] informIT: attack categories
At 6:36 PM -0400 8/25/09, Steven M. Christey wrote: Gary, You said in the article: The next category of attacks to expect are attacks that target defects in design and architecture - which I call flaws. I think it's already happening. I think it has been happening for years. I use Microsoft Word V5.1a from 1992, because Microsoft followed that with Word 6.0 which introduced the design defect allowing Macro Viruses. Of course this was not actually an innovation, as IBM had previously introduced _and_withdrawn_ a similar vulnerability in their CMS operating environment (the mail program would automatically call a text formatter which could call the operating system under the direction of the sender. Those who do not study history are condemned to repeat it. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] IBM Acquires Ounce Labs, Inc.
At 8:39 AM -1000 7/28/09, Jim Manico wrote: A quick note, in the Java world (obfuscation aside), the source and binary is really the same thing. The fact that Fortify analizes source and Veracode analizes class files is a fairly minor detail. It seems to me that would only be true for those using a Java bytecode engine, not those using a Java compiler that creates machine code. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Insecure Java Code Snippets
At 9:15 AM -0400 5/8/09, SC-L Reader Dave Aronson wrote: ljknews ljkn...@mac.com wrote: At 12:47 PM -0500 5/7/09, Brad Andrews wrote: Quoting ljknews ljkn...@mac.com: At 5:49 PM -0500 5/6/09, Brad Andrews wrote: Try a few of the PC-Lint bugs, if you ever wrote C/C++ code. They can be really hard to figure out, And yet people keep choosing those programming languages. They offer quite a bit of power in exchange for the danger. I would be interested in hearing what they can do that cannot be done in Ada. It's rarely (I won't say never!) a question of what *can't* be done in language X or Y. Usually, it's about what's *easier* to do in X or Y. Sometimes the security tradeoff is worth taking the hard way, but sometimes the choice is to the point of being at all practical or not. Well the _easiest_ development comes from not worrying about security. So tell me what you think is easier in C/C++. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Insecure Java Code Snippets
At 12:47 PM -0500 5/7/09, Brad Andrews wrote: Quoting ljknews ljkn...@mac.com: At 5:49 PM -0500 5/6/09, Brad Andrews wrote: Try a few of the PC-Lint bugs, if you ever wrote C/C++ code. They can be really hard to figure out, And yet people keep choosing those programming languages. They offer quite a bit of power in exchange for the danger. I would be interested in hearing what they can do that cannot be done in Ada. My bias is based on my experience. I am sure somebody who knows Eiffel would be interested in hearing what C/C++ can do that cannot be done in Eiffel. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)
At 1:00 PM -0700 3/25/09, Andy Steingruebl wrote: On Wed, Mar 25, 2009 at 10:18 AM, ljknews mailto:ljkn...@mac.comljkn...@mac.com wrote: Worry about enforcement by the hardware architecture after you have squeezed out all errors that can be addressed by software techniques.\ Larry, Given the focus we've seen fro Microsoft and protecting developers from mistakes through things like DEP, ASLR, SEH, etc. why do you think that these can't be done in parallel? I don't know any of those acronyms, and I have very little to do with Microsoft. The last software of theirs I bought was Microsoft Word V5.1a, the last one _before_ they introduced Macro viruses. I mean, we used to not have Virtual Memory or real MMUs and the developer had to make sure they didn't step on other people's pages. Hardware support for protection on pages has helped with a lot of things right? Yes, but for me that was prior to 1978, and the benefit of hardware protection pales by comparison to the benefit of not programming everything in assembly language. I'm not saying I'm holding out hope for hardware to solve all our problems (that would be silly) but I do think it can be fairly useful for some classes of problems and a lot more scalable/repeatable. Practical right now, no. But we're sort of in the realm of fantasy in this discussion already if we think the general mass of people writing software are going to switch languages because certain ones are more reliable I don't expect programmers to make that decision - I expect astute management to make that decision (wherever astute management happens to surface). Management has a lot easier time changing languages than changing hardware architectures. Sometimes the hardware is even dictated by the customer (such as when trying to sell into a particular market). -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] How Can You Tell It Is Written Securely?
At 9:03 PM -0500 11/26/08, Mark Rockman wrote: OK. So you decide to outsource your programming assignment to Asia and demand that they deliver code that is so locked down that it cannot misbehave. How can you tell that what they deliver is truly locked down? Will you wait until it gets hacked? What simple yet thorough inspection process is there that'll do the job? Doesn't exist, does it? Certainly it exists. Rerun the verification of the formal proof, as used in the Tokeneer project I mentioned earlier. Of course a formal proof only proves that software conforms to a specification, so unless you have a specification you have nothing, and that is what a lot of software is lacking. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security
At 9:32 PM -0800 11/25/08, Brian Chess wrote: Larry, I'm not sure I get your meaning. You say you don't think it's a dry well, but then you say programmers ignore the privilege management facilities at their disposal. I mean they ignore it until security overseers (800.53a, PCI DSS, 8500.2 evaluators) come by and force them to fix it. At 10:57 AM -0800 11/25/08, Andy Steingruebl wrote: On Tue, Nov 25, 2008 at 9:48 AM, Gunnar Peterson mailto:[EMAIL PROTECTED][EMAIL PROTECTED]mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote: but actually the main point of my post and the one i would like to hear people's thoughts on - is to say that attempting to apply principle of least privilege in the real world often leads to drilling dry wells. i am not blaming any group in particular i am saying i think it is in the too hard pile for now and we as software security people should not be advocating for it until or unless we can find cost effective ways to implement it. Certainly it is not a dry well. For the operating system I deal with, application programmers _consistently_ ignore the facility provided for fine-grained access to files and leave users with coarse-grained access as their only recourse. So attempting to apply it is not a dry well and not too hard - just typically done as a retrofit due to political rather than techical circumstance. I had a friend who was working on software where multi-million dollar accounts failed to balance correctly. That defect got considerable management attention. The same _could_ be done for security. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Software Assist to Find Least Privilege
At 12:26 PM -0500 11/25/08, Mark Rockman wrote: It be difficult to determine a priori the settings for all the access control lists and other security parameters that one must establish for CAS to work. Perhaps a software assist would work according to the following scenario. Run the program in the environment in which it will actually be used. Assume minimal permissions. Each time the program would fail due to violation of some permission, notate the event and plow on. Assuming this is repeated for every use case, the resulting reports would be a very good guide to how CAS settings should be established for production. Of course, everytime the program is changed in any way, the process would have to be repeated. The approach my company recommends is intended to minimize any possible impact on existing operations (we deal exclusively with existing installations). 1) Enable auditing for use of privilege. 2) Wait for a period of normal operation (time period depends on the nature of the business). 3) Remove privileges from any user who never used a particular privilege. Of course that must be accompanied by an aggressive policy of requiring justification of every assignment of privilege to an individual. In many cases, permissions have been given for an individual to modify particular data when in fact they should only be authorized to do that when using a particular program. Tightening that up uses a mechanism whose name will vary depending on the operating system in use, but it is bound to require modification and security analysis of applications. The context in which we are recommending this is typically where external security requirements are suddenly raised, e.g. 800-53a, PCI DSS, 8500.2. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Cat out of the bag?
At 11:09 AM -0600 10/30/08, Jonathan Leffler wrote: Content-Type: multipart/signed; protocol=application/x-pkcs7-signature; micalg=sha1; boundary=---z22511_boundary_sign Gary McGraw [EMAIL PROTECTED] wrote: Here is a pointer to an article... I'm getting 404 errors? I backed up the chain of directories in the URL and the link is broken on the page: http://www.cigital.com/papers/ http://validator.w3.org shows that page has 25 HTML errors. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Human Elements of Security Survey
At 8:40 PM -0400 10/8/08, Sammy Migues wrote: JavaScript is required on SurveyMonkey. Thank you for the warning. It is amazing the number of people who presume that security people are willing to go to a website enabling cookies or JavaScript or worse. Of course it is also amazing the number of web sites that silently fail in some bizarre fashion if reached by a secured browser. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Survey
At 7:21 PM -0400 8/24/08, [EMAIL PROTECTED] wrote: The publisher of the web page is not in the security business, they are in the publishing business. But how can I respect their publishing expertise if they fail a simple automatic test. Well, I guess that most of web developers are not validating with tools such as w3 validators, but more interesting, validating with different browsers... My experience is that browsers succeed on standards-compliant pages. Standard compliance should be the first test. If it subsequently fails on a particular browser, it is a browser defect which may or may not be of interest to the publisher. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Survey
At 9:12 AM -1000 8/26/08, Jim Manico wrote: How does xHTML help stop access control vulnerabilities? Authorization issues? CSRF problems? It is indicative of the caliber of the people who built the site. My immediate interest is that validation combats browser crashes. I am not interested in dealing with people who cannot get the simple things right. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Root Canal Treatment vs Source Code Review
At 10:43 PM -0400 6/30/08, Mary and Glenn Everhart wrote: There is another reason I have seen quite often: you can't readily ask the designer of the code what it does when he is dead, or when he has left the company (esp. if he works for a competitor). When I participated (as author) in formal inspection there were as many defects found (and fixed) in the comments as in the code. And most people think my comments are better than average. I have left the company but still have some access to see what defects they have found since. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] InternetNews Realtime IT News - Merchants Cope With PCI Compliance
At 9:44 AM -0400 6/30/08, Kenneth Van Wyk wrote: Happy PCI-DSS 6.6 day, everyone. (Wow, that's a sentence you don't hear often.) http://www.internetnews.com/ec-news/article.php/3755916 In talking with my customers over the past several months, I always find it interesting that the vast majority would sooner have root canal than submit their source code to anyone for external review. I'm betting PCI 6.6 has been a boon for the web application firewall (WAF) world. The Note: at the end of PCI DSS (v1.1) 6.6 talks about this method but typographically seems to apply to both bullets. Does anyone know what the authors had in mind ? -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] GCC and pointer overflows [LWN.net]
At 1:00 PM -0400 5/1/08, Epstein, Jeremy wrote: Ken, a good example. For those of you who want to reach much further back, Paul Karger told me of a similar problem in the compiler (I don't remember the language) VAX Pascal, before VMS was on Alpha (and long before Itanium). used for compiling the A1 VAX VMM kernel, that optimized out a check in the Mandatory Access Control enforcement, which separates information of different classifications (*). [For those not familiar with it, this was a provably secure kernel on which you could host multiple untrusted operating systems. Despite what some young-uns seem to think, VMs are not a new concept - they go back at least three decades that I know of, and possibly longer. The A1 VAX effort ended roughly 20-25 years ago, to give a timeframe for this particular compiler issue.] -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] GCC and pointer overflows [LWN.net]
At 3:12 PM -0400 5/1/08, Leichter, Jerry wrote: The VAX VMM effort died with the announcement of the Alpha, in late 1992 - though obviously the death was decided internally once the move to Alpha was decided, which would have been somewhat earlier. The origins of the VAX VMM effort date back to the early 80's. My understanding is that DEC pulled the plug on the VMM project (called SVS) during a successful field test when they discovered that while the NSA division that handled trusted computing was really gung ho about the project, none of the government units which might actually make purchases were interested in multilevel secure machines. Remember that the MicroVAX II was available at the time and from many perspectives (including that of taxpayers) it was a lot nicer to use separate machines for various security classifications. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] InformIT: budgeting for software security
At 8:14 AM -0500 4/11/08, Wall, Kevin wrote: In the context, I think his concern was that in the past, the RSA conferences were focused on infosec, and on cryptography in particular. Apparently, based on Stephen and gem's comments, it seems to have lost its focus. I think that's all that was being implied here. Some years ago at an RSA Conference I recall seeing Jefferson Starship. At least one song had altered lyrics for the GAK issue of the year, but that was not a whole lot of security content in a general session. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Code review pool
At 12:50 PM +0100 11/5/07, Paolo Perego wrote: Hi guys, trying to improve Owasp Orizon project in a better way, I released a poll over my blog here: http://thesp0nge.livejournal.com/5687.html It would be great having your feedback about your vision to code review and safe coding as developers and security specialist. I see a bunch of links called View Answers along with a link called Poll #1083138. Clicking on the Poll #1083138 link takes me to a page of answers. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] COBOL Exploits
At 12:13 AM -0400 11/2/07, Mark Rockman wrote: The adolescent minds that engage in exploits wouldn't know COBOL if a printout fell out a window and onto their heads. I'm sure you can write COBOL programs that crash, but it must be hard to make them take control of the operating system. Of course if a program is able to take control of the operating system, either: A. The operating system is at fault (typically not COBOL) B. The program is installed with special privileges Just feeding bad parameters to a system call is inadquate to suborn a well-constructed operating system. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Mainframe Security
At 4:11 PM +0100 11/2/07, Johan Peeters wrote: Let me offer a little variant on the previous theme though to illustrate, hopefully more convincingly, why I find COBOL worrisome: ... 01 txtpic x(2). move 'hi' to txt call 'evil-code' using txt IDENTIFICATION DIVISION. PROGRAM-ID. evil-code. DATA DIVISION. linkage section. 01 assetPIC X(1200). procedure division using asset The author of evil-code now has a selection of the contents of the caller's data segment at his disposal. Are you saying that evil-code is written in some language that allows it to take advantage of by-reference semantics to go outside the nominal boundaries of 2 bytes presumed by COBOL ? If so, this is hardly an issue specific to COBOL. Presuming evil-code can play address arithmetic issues, any situation where the caller's address space is visible to evil-code is similarly vulnerable. Clearly evil-code should be in a separate address space to defend against such an attack. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Mainframe Security
At 2:16 PM +0100 11/2/07, Johan Peeters wrote: I have been looking at an IBM system. If I do something like this ... 01 txt PIC X(120) string '**' into txt end-string display txt I get to see ** on sysout followed by what appears to be selected contents of the data section. This strikes me as somewhat worrysome - it reminds me of the format string vulnerabilities in C. Am I just being paranoid? A program that improperly releases data due to programmer error is beyond what I consider to be the realm of security. To me that is merely bad programming. To me the criterion is whether an outsider can cause a program to do something other than what it does for normal users. Some secret back door password that causes organizational secrets to be released would be a Trojan horse. A typical method of controlling that is with the security controls on a database, so only authorized users can read the company secret field, no matter how badly the application programmer messes up. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Mainframe Security
At 11:45 PM +0100 11/2/07, Florian Weimer wrote: My limited exposure to Cobol makes me think it is as unlikely to have a buffer overflow as PL/I or Ada. Usually, Ada programmers switch off bounds checking before shipping code. I don't know why Ada has such a reputation for robustness. Can you provide a pointer to the study showing that ? Certainly none of the Ada I ship has bounds checking disabled. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Mainframe Security
At 9:16 PM +0100 11/1/07, Johan Peeters wrote: I think this could do a great service to the community. Recently I was hired by a major financial institution as a lead developer. They said they needed me for some Java applications, but it turns out that the majority of code is in COBOL. As I have never before been anywhere near COBOL, this comes as a culture shock. I was surprised at the paucity of readily available information on COBOL vulnerabilities, yet my gut feeling is that there are plenty of security problems lurking there. Since so much of the financial services industry is powered by COBOL, I would have thought that someone would have done a thorough study of COBOL's security posture. I certainly have not found one. Anyone else? Can anyone point to stories about Cobol exploits ? I mean exploits that have to do with the nature of the language, not social engineering attacks that happened to take place against a Cobol shop. My limited exposure to Cobol makes me think it is as unlikely to have a buffer overflow as PL/I or Ada. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
[SC-L] Dilbert Does Software Testing
http://www.dilbert.com/comics/dilbert/archive/images/dilbert2007071745828.gif -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] how far we still need to go
At 2:03 AM +0100 7/26/07, Dinis Cruz wrote: It's a simple economics problem. The moment these companies and developers lose sales (or market share) because their products require admin / root privileges to run, is the moment they start to REALLY support it. For Windows that day might be when they have to run under the new US federal government standard Windows configuration, due out any month now. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Resources to fix vulns
At 8:53 AM -0700 7/18/07, McCown, Christian M wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary=_=_NextPart_001_01C7C953.D03CBE5C What do you tell a C-level exec in terms of h/c and time it will take to fix web app vulnerabilities discovered in a website? X number of vulnerabilities = Y h/c and Z time. Of course there's a host of factors/variables involved that could wind up looking like actuarial tables or DNA sequences (!), but what we'd like to be able to do is sum it up as an initial swag and let the app owners use it as a factor in calculating the actual time to remediate. Look at the track record for _that_organization_ fixing previous vulnerabilities. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Resources to fix vulns
At 9:50 AM -0400 7/19/07, McGovern, James F (HTSC, IT) wrote: I would actually recommend AGAINST using prior track records for fixing previous vulnerabilities because in all honestly they probably don't track it. Most enterprises prioritize any type of defect based on the importance as declared by business users whom traditionally would prioritize a spelling error on a web page of higher importance than a buffer overflow. Security stuff may get addressed while the developer has the patient open and therefore there is no real transparency in terms of the numbers. If investigation of prior security vulnerability remediation shows it is skewed by low organizational priority, then that _is_ an indication of how fast _that_organization_ will fix a security vulnerability. It seems much more honest that guesses about how long it would take if it were high priority. As for record keeping, the source code archives should show the date a change was made (even if bundled with other changes). -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] The Next Frontier
At 4:38 PM -0400 6/27/07, Paco Hope wrote: On 6/26/07 5:00 PM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: Would there be value in terms of defining an XML schema that all tools could emit audit information to? You might want to take a look at what the Fortify guys already do. Their FVDL (Fortify Vulnerability Description Language) is XML written to a specific schema In the US, the federal government has a lot of that going on: http://nvd.nist.gov/scap.cfm but they only support certain platforms, like Windows. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Harvard vs. von Neumann
At 9:00 AM -0400 6/11/07, Gary McGraw wrote: If we assumed perfection at the implementation level (through better languages, say), then we would end up solving roughly 50% of the software security problem. Clearly we need to make some progress at the architecture/design level to attain reasonable levels of software security. Perfect languages won't solve the software security problem. And neither will perfect designs. Both approaches needed. But a large percentage of failures that result from weak languages are already categorized in standard terms like buffer overflow. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] FW: What's the next tech problem to be solvedin softwaresecurity?
At 9:51 PM +0100 6/9/07, David Crocker wrote: If instead we pay people to perform the more skilled tasks of establishing requirements and specifying the systems to meet them, and use computers to generate programs that meet the specifications, then such things as freedom from buffer overflow come free of charge. By freedom here, I don't mean the sort of freedom that comes in safe languages such as Ada and Java - in which the buffer overflow raises an exception, probably requiring a restart of the subsystem In my experience with Ada 83, the potential for buffer overflow is detected at compile time. When I get an unexpected runtime exception, it is almost always at the interface to another language. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] FW: What's the next tech problem to be solvedin softwaresecurity?
At 9:16 AM -0400 6/10/07, Robert C. Seacord wrote: ljknews, Yes, it is virtually impossible to get a serious runtime error in an Ada program. For example: http://www.youtube.com/watch?v=kYUrqdUyEpI It amazes me that someone in a discussion of software security would point to a page that requires Javascript to be viewed. But I see the topic of the page was Ariane 5, a well known case of running software in an environment other than that specified in the design of the software. That is a management issue - my comments were about buffer overflows, as were the comments of David Crocker which I quoted. If you have secret knowledge that the Ariane 5 failure was related to buffer overflows, please share it. Not reading what was going on, in fact, was the cause of the Ariene 5 failure. At 9:51 PM +0100 6/9/07, David Crocker wrote: If instead we pay people to perform the more skilled tasks of establishing requirements and specifying the systems to meet them, and use computers to generate programs that meet the specifications, then such things as freedom from buffer overflow come free of charge. By freedom here, I don't mean the sort of freedom that comes in safe languages such as Ada and Java - in which the buffer overflow raises an exception, probably requiring a restart of the subsystem In my experience with Ada 83, the potential for buffer overflow is detected at compile time. When I get an unexpected runtime exception, it is almost always at the interface to another language. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What's the next tech problem to be solved in software security?
At 8:33 AM -0400 6/9/07, der Mouse wrote: Immunity from buffer overflows has been around for 30 years. The fact that some set of developers choose to ignore the languages that provide it does not make the next environment that provides it an improvement for the industry. I'd disagree - if it means a significant increase in people actually using such environments (languages, whatever), then it's an improvement for the industry, even if it's no theoretical advance. A law which outlawed unsafe languages could also be effective, but it would not solve a tech problem, which is the basis for this thread. At best these are solutions to social problems or education problems. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What's the next tech problem to be solved in software security?
At 9:53 AM +0200 6/8/07, Stephen de Vries wrote: On 8 Jun 2007, at 02:23, Steven M. Christey wrote: More modern languages advertise security but aren't necessarily catch-alls. At the same time, the improvements in security made by managed code (e.g. the JRE and .NET runtimes) for example, should not be understated. The fact that apps written in these languages are not susceptible to buffer overflow issues is a HUGE improvement. An improvement only for those who have previously chosen lowest common denominator languages. Immunity from buffer overflows has been around for 30 years. The fact that some set of developers choose to ignore the languages that provide it does not make the next environment that provides it an improvement for the industry. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Best practices for encrypting client-side data
At 12:01 PM +1200 5/10/07, Robin Sheat wrote: Content-Type: multipart/signed; boundary=nextPart1622971.NJ1973Q3ia; protocol=application/pgp-signature; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit On Wednesday 09 May 2007 02:11:05 ljknews wrote: I would suggest two factor authentication, requiring some smart card (with built-in keypad, to prevent intercept of the pin) that actually provides the decryption. Make the user keep the smart card with them, such as by requiring it for entrance to the cafeteria or rest room. That's not possible in this case. Mostly because it would involve more investment on our part than the customers would be willing to pay for. However, I'm interested in generalising the ideas in this thread to go beyond my particular situation; if you were storing data in an application on a laptop, how would you keep it as safe as is feasible? The tension between as safe as is feasible and not willing to pay for is not susceptible to generalization. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Darkreading: compliance
At 9:29 AM -0400 3/30/07, Benjamin Tomhave wrote: SOX has been a complete waste, imo. First, the majority of it was already covered in existing law. Second, it really has nothing to do with security from a practical standpoint. The only purpose SOX has served is to give auditors another source of revenue. And, worse than that, it initially gave auditors the appearance of more power and responsibility, which I saw carried out in external auditors trying to dictate to businesses how the business should operate (and not in a good way). Talk about a fundamental violation of independence and objectivity. The pendulum has fortunately swung back on that trend. PCI DSS, on the other hand, has been a very good effort with real, meaningful results. Why is this? Well, for one thing, it's specific. As opposed to SOX, which paints with broad strokes and focuses on truth in reporting (gross oversimplification), PCI DSS goes into technical detail on what activities must be implemented, what minimum measures are for adequate security in a system, etc. Perhaps the best example of this thought is section 3.6 in DSS v1.1, where it details the minimum requirements for key management. It makes my job much easier having this level of detail, with much less left to interpretation (again, unlike SOX, where almost everything is open to interpretation and the whim of your auditors). That parenthetical comment is almost verbatim the description of SOX I received from someone who is subject to SOX audits. My own nomination for specificity in security standards is NIST Special Publication 800-53 (currently at Revision 1). http://csrc.nist.gov/publications/nistpubs/index.html#sp800-53-Rev1 Through all the controls there is only one requirement with which I disagree. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Economics of Software Vulnerabilities
At 8:55 AM -0400 3/20/07, Michael S Hines wrote: I'm not sure what your sources are but from what I'm hearing and reading the problem is that there are many missing drivers for what have become standard peripherals that people are used to - and some of the vendors are reluctant to develop new drivers (the driver technology changed in Vista - so all drivers have to be reworked). MP3 players, ePhones, PDA's, etc. have become standard components in many places... and they don't work with Vista - yet (if ever). That is because the features provided by many add-on products depended on the longstanding loose state of security on Microsoft Windows. It's the feature thing not that users are shunning security. And, at least to me, it is an indication that M$ did not understand the marketplace or rushed the (incomplete) product to market. There's more than one way to foul up a new product launch. The previous Microsoft mode had been to favor anything that would ease feature implementation over anything that would provide security. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Dark Reading - Discovery and management - Security Startups Make Debut - Security News Analysis
At 5:20 PM +1100 1/25/07, Crispin Cowan wrote: ljknews wrote: My guess is that if a company actually is capable of analyzing binary code they only do it for the highest volume instruction sets. They certainly will focus on larger markets first. If you want them to focus on *your* market, make it worth their while :) So I should pay to have them check the work of my vendors ? Or I would convince my vendors to pay them ? Sorry, my business is not that large a fraction of my vendors' customer base. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Dark Reading - Discovery and management - Security Startups Make Debut - Security News Analysis
At 1:52 PM -0500 1/22/07, Kenneth Van Wyk wrote: Content-Type: multipart/signed; protocol=application/pgp-signature; micalg=pgp-sha1; boundary=Apple-Mail-12-58709954 Content-Transfer-Encoding: 7bit Ok, last software security news item for today, I promise. :-) This article (see http://www.darkreading.com/document.asp?doc_id=115110WT.svl=news1_1http://www.darkreading.com/document.asp?doc_id=115110WT.svl=news1_1) is about a couple of new startup companies. One of them in particular, Veracode, may be of some interest here. The article says, Veracode, founded by Chris Wysopal and other former executives of @stake, is now offering patented binary-code analysis of software for enterprises that want to analyze their software's security on a regular basis. The ASP will also offer security reviews of enterprise products and security analysis of third-party apps for software developers. The article also provides some counterpoints, including some from Gary McGraw, that are worth reading. Among other things, Gary says, However, if you want real security analysis you have to go past the binary, past the source code, and actually consider the design. Opinions on binary vs. source code (and design!) analysis, anyone? Analyzing source code is independent of machine architecture. My guess is that if a company actually is capable of analyzing binary code they only do it for the highest volume instruction sets. My guess is that attackers will go after machines they feel are less protected. Efforts which merely change attacker behavior are a waste of time. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Dark Reading - Discovery and management - Security Startups Make Debut - Security News Analysis
At 3:10 PM -0800 1/22/07, Blue Boar wrote: ljknews wrote: Analyzing source code is independent of machine architecture. My guess is that if a company actually is capable of analyzing binary code they only do it for the highest volume instruction sets. My guess is that attackers will go after machines they feel are less protected. Efforts which merely change attacker behavior are a waste of time. Nope. If I'm running x86 boxes, I'd be more than happy to have to attackers move to SPARC. Those of us _not_ running X86 do not feel that way. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] temporary directories
At 8:45 AM -0500 12/30/06, Leichter, Jerry wrote: [MJoderator: This is likely beyond the point of general interest to sc-l] Actually, I disagree, in that it seems to expose a set of vulnerabilities not known even to language implementors. On Fri, 29 Dec 2006, ljknews wrote: | But these are problems that have been solved by those who provided the | Ada implementation (ACT and Aonix come to mind for Unix), and thus are | not an issue for the high level language programmer. Presumably they do the create-the-file-and-immediately-delete-it trick. Since the file must, however briefly, have an entry in some directory. General purpose code can't make assuptions about what directories are available for writing, so pretty much has to put the entry in a known, public place - almost always /tmp or /var/tmp. Unless one does this very carefully, it's open to various attacks. (For one trivial example, there is no way to tell the open() call to *always* create a new file - you can only tell it if the file already exists, don't open it, return an error instead. The code had better check for that error and do something appropriate or it can be fooled into using a file an attacker created and already has access to.) Certainly code that does not check for errors is inadequate. The techniques for doing this are complex enough - and the attacks if you don't do it *exactly* right obscure enough - that after all these years, attacks based on insecure temporary file creation are still reported regularly. (Frankly, even though I know that these problems exist, if you were to ask me to write a secure temporary file creator right now, I wouldn't try - I'd look for some existing code, because I doubt I'd get it right.) Which is what one does when using the existing language implementation (except for the defect reported by Florian Weimer in this thread. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] temporary directories
At 5:11 PM +0100 12/30/06, Florian Weimer wrote: I gather you are saying that the innards of Unix will force creation of an unwanted directory entry on the Ada implementation of the required null name support for packagename.CREATE . The Ada implementation could rely on exclusive access to the file (surely Unix has that, right?) You can create files in a way that fails if the file already exists, using the O_EXCL flag. (Rumors have it that this won't work reliably over NFS, though, but I don't see why.) coupled with whatever Unix has that passes for the FAB$V_DLT bit to delete the file on Close (such as at insert Unix words for image rundown). You can delete open files on Unix, so you could in theory unlink it after creation. But the whole discussion is moot because existing Ada code seems to require that temporary files have names. 8-/ The Ada language does not have such a requirement, and in fact has a requirement that names are _not_ required for temporary files. But these are problems that have been solved by those who provided the Ada implementation (ACT and Aonix come to mind for Unix), and thus are not an issue for the high level language programmer. AdaCore's implementation used mktemp and featured the usual race condition. Yucko !!! -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
At 2:18 PM + 1/2/07, Peter Amey wrote: [snip] Isn't the whole basis of Spark a matter of adding proof statements in the comments ? I don't think the general compiler marketplace would go for that built-in to compilers. After all: 1. The Praxis implementation can be used with multiple compilers 2. The compiler market is so immature that some people are still using C, C++ and Java. But for the high-integrity market, Spark seems to fit the bill. -- Larry Kilgallen We think so! However, like everything else, it is how you use things that matter most. How you use things may be an essential aspect, but so is the nature of things. Achieving the same quality by toggling the machine code into the front panel is only possible on a theoretical basis, and getting the same results with a long strand of limp spaghetti is just impossible. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Building Security In vs Auditing
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
At 6:56 PM -0500 12/29/06, Leichter, Jerry wrote: | Not on Unix, but I tend to use temporary names based on the Process ID | that is executing. And of course file protection prevents malevolent | access. | | But for a temporary file, I will specify a file that is not in any | directory. I presume there is such a capability in Unix. You presume incorrectly. You're talking about VMS, where you can open a file by file id. Actually, I was talking about using the FAB$V_TMD bit when creating the file. One can argue this both ways, but on the specific matter of safe access to temporary files, VMS code that uses FID access is much easier to get right than Unix code that inherently has to walk through directory trees. On the other hand, access by file id isn't - or wasn't; it's been years since I used VMS - supported directly by higher-level languages (though I vaguely recall that C had a mechanism for doing it). In Ada invoking packagename.CREATE with a null name will do the trick, although if your VMS experience ended before 1983 you would not have run into that. But how to program easily against VMS V4.1 when the latest version is VMS V8.3 is not a typical problem. I gather you are saying that the innards of Unix will force creation of an unwanted directory entry on the Ada implementation of the required null name support for packagename.CREATE . The Ada implementation could rely on exclusive access to the file (surely Unix has that, right?) coupled with whatever Unix has that passes for the FAB$V_DLT bit to delete the file on Close (such as at insert Unix words for image rundown). But these are problems that have been solved by those who provided the Ada implementation (ACT and Aonix come to mind for Unix), and thus are not an issue for the high level language programmer. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Could I use Java or c#? [was: Re: re-writingcollege books]
At 3:44 PM + 11/15/06, Pete Shanahan wrote: ljknews wrote: At 8:18 PM -0600 11/14/06, Wall, Kevin wrote: That makes a Java inappropriate for a lot of system-level programming tasks. Simple example: There's no way in pure Java that I can lock a process in memory. Wrt this list, that has a lot of security ramifications especially on shared processors. Sure makes hiding secrets a lot harder. I did not write any of that. It's an operating system feature where you can lock a chunk of the memory of a process such that it is not swapped out at any time. see the specs for mlock, madvise. Those words mean nothing to me, but I presume you are talking about either locking a page into memory: http://h71000.www7.hp.com/doc/83FINAL/4527/4527pro_081.html#jun_369 or locking a page into the working set: http://h71000.www7.hp.com/doc/83FINAL/4527/4527pro_082.html#jun_373 or preventing an entire process from being swapped out: http://h71000.www7.hp.com/doc/83FINAL/4527/4527pro_105.html#jun_526 None of those resolve the responsibility of the operating system to remove residue from memory before transferring it to another user. That is true regardless of whether the process is running compiled code or a bytecode engine (which is the real issue, not the implementation language). win32, I believe has an even more feature ridden facility for secure memory. on the receipt of abnormal termination signals this memory can be cleared, thus keeping the secret safe, so you could produce a process crash dump that is sanitized for sending to a support group. Yes, that is present in my environment as well. Is the problem that the bytecode engine used with languages like Java do not have a function to exclude certain parts of memory from process crash dumps ? That was not clear from the prior statement. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writingcollegebooks]
At 10:55 AM -0600 11/15/06, Wall, Kevin wrote: Larry Kilgallen wrote: At 8:18 PM -0600 11/14/06, Wall, Kevin wrote: That makes a Java inappropriate for a lot of system-level programming tasks. Simple example: There's no way in pure Java that I can lock a process in memory. Wrt this list, that has a lot of security ramifications especially on shared processors. Sure makes hiding secrets a lot harder. Please explain that issue. Is there some multiuser operating system that does not clear memory before retasking it for another process ? I wasn't referring to the OS not clearing memory between use by different processes. Instead consider a case where there's a secret such as an encryption key, password, etc. in a chunk of memory that has been paged out to a swap device (*nix) or pagefile.sys (Windows). The process them terminates abnormally because of a signal, abrupt power outage, etc. From a security POV, this is a bad thing since now your secret is somewhere on the hard drive. But a cryptographic secret should not be in user-readable memory in the first place, due to the risk of a trojan horse. That belongs in OS memory dedicated to the user but protected from them (i.e., inner mode) and at that point the operating system can mark such memory as not being subject to dumping. The user might enter a password to _unlock_ that secret key, and some trojan horse (or wiretap) might intercept that password and use it in a malicious fashion, but the trojan horse cannot export the secret key to another machine. (By secret key, I mean the secret half of a public key pair.) Overall, I find these types limitations with Java or C# more frustrating than I do with the performance issues. A native compiler should have no problem calling any system service. It would seem your objection is really to the bytecode engine version of Java rather than to the language itself. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
At 10:31 PM +1100 11/13/06, mikeiscool wrote: On 11/13/06, Glenn and Mary Everhart [EMAIL PROTECTED] wrote: If there is some construct that NEEDS to be interpreted to gain something, it can be justified on that basis. Using interpretive runtimes just to link languages, or just to achieve portability when source code portability runs pretty well thanks, seems wasteful to me. You think source code portability is good enough such that runtime portability isn't really needed? Anything beyond source code portability tempts the customer into use on a platform where the developer has not tested. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
At 10:47 AM -0500 11/6/06, der Mouse wrote: I read this thread and I little be afraid. I'm just ahead of a complete rewriting of my program. The previous code was written in pure C (with an OOP looks-like somewhere). Perhaps I'm missing something. Why do you have to abandon C? You mention C++, C#, and Java, but no other languages; is there some reason you have to use a language that tries to be object-oriented? Is there some reason you have to use a language that looks like C ? -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Why Shouldn't I use C++?
At 9:08 PM -0500 10/31/06, Ben Corneau wrote: C and C++ are very different. Using C++ like C is arguable unsafe, but when it's used as it was intended can't C++ too be considered for secure programming? What assurance does upper management have that C++ was used as it was intended rather than like C ? -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]
At 12:11 PM -0400 10/13/06, James Walden wrote: you really have to use C because it's the only thing that will do, That seems extremely improbable. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] bumper sticker slogan for secure software
At 9:46 PM +0200 7/20/06, Florian Weimer wrote: * Pascal Meunier: But it's true for stupid bugs like buffer overflows and format string vulnerabilities, in which we're still swimming, and the proof is the fact that those aren't possible in some languages. Could you name a few such language implementations? 8-) Ada ! In most cases, the components that enforces the absence of buffer overflows are written in C. Not in VAX/DEC/Compaq/HP Ada, which is the one that I use. But the components that enforce the absence of buffer overflows are not written in Bliss (the language of the Ada RTL for that compiler) either. They are in the code that is generated, or the failure to generate that code because the problem was caught at compile time. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Bumper sticker definition of secure software
At 3:27 PM -0400 7/15/06, Goertzel Karen wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary=_=_NextPart_001_01C6A844.D6A28B6B I've been struggling for a while to synthesise a definition of secure software that is short and sweet, yet accurate and comprehensive. Here's what I've come up with: Secure software is software that remains dependable despite efforts to compromise its dependability. Agree? Disagree? I disagree about that being bumper-sticker size, and I think we really need bumper stickers. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
RE: [SC-L] RE: Comparing Scanning Tools
At 2:32 PM -0400 6/9/06, Jeremy Epstein wrote: Having said that, it's completely at odds compared to what I see working for an ISV of a non-security product. That is, I almost never have prospects/customers ask me what we do to assure our software. I don't even get those questions for our security product ! -- Larry Kilgallen LJK Software ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Hiring folks that are familar with SC practices
At 10:38 AM -0400 6/2/06, McGovern, James F (HTSC, IT) wrote: Figured I would ask the list a question that I haven't figured out the answer to. How have other enterprises that seek architects and developers knowleedgable in secure coding software development practices articulated it to their internal HR recruiting arm? We have been seeking candidates with this background but haven't ran across much on our side of town. Are you bringing something to the table to attract such people ? Or have you preconstrained the programming languages and techniques to be used ? -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] HNS - Biggest X Window security hole since 2000
At 11:12 AM -0400 5/4/06, Kenneth R. van Wyk wrote: Content-Type: multipart/signed; boundary=nextPart1887150.2DlSXmIMA5; protocol=application/pgp-signature; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Stories about this (below) X bug and the DHS-sponsored project that found it have been floating around the net all week. This story caught my eye, though: http://www.net-security.org/secworld.php?id=3994 The author claims, This flaw, caused by something as seemingly harmless as a missing closing parenthesis, allowed local users to execute code with root Certainly that part is OS-specific. On my VMS machine, X-windows processes do not run as root. privileges, giving them the ability to overwrite system files or initiate denial of service attacks. So, it sounds like a single byte change in the entire X src tree could fix a bug that could give an attacker complete control of a system. Lovely... -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Segments, eh Smithers?
At 9:02 AM -0700 4/3/06, Crispin Cowan wrote: That second question is actually pretty technically deep. What is so different about paged memory systems that makes them harder to secure than segmented memory systems? My conjecture: it is the granularity of the memory blobs. Consider: * In a segmented system, you have a small number of fairly large memory objects (segments). Segments are hefty enough that they can be of variable size, and also can have security tags describing their security level at multiple levels. So a given segment can be tagged as being security level 1, 2, 3, and so forth, and the TCB need only check the level before granting or denying access. * In a paged system, in contrast, you have a very large number of much smaller memory objects (pages). Pages are simple, even having fixed size. Fixed size wastes memory, but no one cares because the pages are small enough that it doesn't hurt much. Because pages are simple, you cannot tag them with a bunch of different security levels. For that matter, x86 architectures only recently got a (kind-of) ability to distinguish between read and execute permissions per page, so asking associate and store security levels per page in hardware is likely more than the TLB can handle. I will admit to not knowing much about hardware, but you seem to be discussing a TCB implemented in software. Consider the VAX/Alpha/Itanium on which VMS runs. As a user program I access pages, but I don't think of them in those terms. I think of them as Sections (some are Global) which contain the read-only part of one shareable image, my own DCL symbols, etc. Those sections to which I have access are in my virtual address space protected so I have that access to which I am entitled. What is disturbing about that hardware ? Is it the fact that the operating system is really setting individual page protections rather than a whole segment at a time ? I realize you probably want more levels and compartments, but that does not seem to me to make the task untenable. Educate me. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code
At 2:34 AM +0100 3/27/06, Dinis Cruz wrote: PS: For the Microsofties that are reading this (if any) sorry for the irony and I hope I am not offending anyone, but WHEN are you going to join this conversion? (i.e. reply to this posts) I can only see 4 reasons for your silence: a) you are not reading these emails, b) you don't care about these issues, c) you don't want to talk about them or d) you don't know what to say. e) Your employer has a company policy against such participation. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, User vs Admin risk profile, and browsers coded in 100% Managed Verifiable code
At 11:39 AM + 3/25/06, Dinis Cruz wrote: 3) Since my assets as a user exist in user land, isn't the risk profile of malicious unmanaged code (deployed via IE/Firefox) roughly the same if I am running as a 'low privileged' user or as administrator? (at the If the administrator's assets are compromised, all users of the system will have their assets compromised. end of the day, in both cases the malicious code will still be able to: access my files, access all websites that I have stored credentials in my browser (cookies or username / passwords pairs), access my VPNs, Certainly users should not store credentials in software on a computer. attack other computers on the local network, install key loggers, If one is not the administrator, there should be no way to install software. If there is, the operating system is underprotected. establish two way communication with a Internet based boot net, etc ... At least one aspect of that is a design defect in TCP/IP, allowing unprivileged users to create a port to receive inbound connections. Other networking protocols avoid that flaw. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Question about the terms encypt and secure
At 12:35 PM -0500 3/5/06, William L. Anderson wrote: My question is whether it's more accurate to say secure their network rather than encrypt. I'm not clear myself about the meaning of these terms; I think of encryption as being one way to make a network secure. Another way that was described some years ago was Marine Guards every 5 feet down the Thick Ethernet cable to prevent unauthorized taps. Of course that was by someone in the cryptographic business :-) -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
RE: [SC-L] Question about the terms encypt and secure
At 6:04 AM -0800 3/6/06, Jeremy Epstein wrote: Encryption is one way to secure the *transport* on the network (subject to various caveats about appropriate use of crypto, trust issues, etc.). I'd strongly disagree with anyone who says that encryption makes a network secure - because people interpret that to mean if I encrypt the network, I don't need to do anything else. I cannot think of any other _network_ security mechanisms that do not also apply to securing a single multiuser machine. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
[SC-L] Where to read about construction quality software
The US Department of Homeland Security seems to be sponsoring a web site at https://buildsecurityin.us-cert.gov/portal/ , devoted to construction of quality software. But feeding that URL to http://validator.w3.org/ produces a list of 277 HTML errors on that software quality page :-) No, I don't go checking such stuff just to be ornery - it produced a blank screen on the first browser I tried. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Intel turning to hardware for rootkit detection
At 1:33 AM -0800 12/14/05, Crispin Cowan wrote: Smashguard, if I recall correctly, offers approximately the protection of existing compiler methods, but with the added fun of requiring modified (non-existent) hardware. The referenced hardware in the IEEE article and the intel.com pages appears to be some descendant of Palladium; it is a hardware integrity checker/attestation mechanism. A small, hardware-enforced core performs a chain of crypto-checks prior to boot strapping the BIOS, and then the OS, and makes itself available to applications. Thus an application can (more or less) prove to a remote machine that the BIOS, kernel, and application are in fact the approved versions that the remote machine wants to see. The closest published work would be Bill Arbaugh's dissertation and associated papers. That sounds very much like DEC's Distributed Systems Security Architecture, which was never an implemented product. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Intel turning to hardware for rootkit detection
At 9:28 AM -0800 12/13/05, Ron Forrester wrote: On 12/13/05, Kenneth R. van Wyk [EMAIL PROTECTED] wrote: The detection mechanism seems to primarily be looking primarily for non-OS software modifying OS inhabited memory blocks. Wonder how they're definining (and maintaining the definition) of each... I also wonder how it'll impact near-OS software installations like, say, device drivers, authentication plug-ins, and other things that need to poke pretty deeply into the OS in order to install. I have to admit, when I initially read about this I immediately dismissed it as nothing but marketing hype -- what little details they gave for the solution seemed to me to be less than practical and certainly would have issues adapting to targeted attempts to deceive the mechanism. I'd love to hear other peoples thoughts on the matter. For a test of their generalized characterization of the problem, consider how well they might do analyzing VMS running on Itanium. If the non-OS software attempted to trick the OS software into doing something from an inner mode, their external approach seems intractable. On the other hand, non-OS software calls to OS software regularly result in changes to memory protected against outer mode access. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] New TC poll: Was Lynn right?
At 11:54 AM +0100 8/9/05, Nick Murison wrote: (Yes, this is a shameless plug) Good morning everyone, Seen as the storm after BlackHat has settled a little, I thought it'd be nice to see what people had decided about Michael Lynn's presentation. Was he right to go ahead with it, or was it really not his call? Judging from the security mailing lists, everyone and their dog has now had the opportunity to ramble on about the finer details of the situation. At www.ThreatsAndCountermeasures.com, we just want some straight answers, so we made it the topic of our latest poll :) So go along to https://www.threatsandcountermeasures.com and submit your vote: Was Lynn right to hold his BlackHat talk? a) Yes, information should be free b) Yes, to safeguard infrastructure c) No, to safeguard infrastructure d) No, he violated IP e) Don't care You omitted: f) Not enough information provided to know what on earth you are discussing. -- Larry Kilgallen [Ed. *grin* There were numerous media accounts of the uproar that Michael Lynn generated at the BlackHat conference a week+ ago by disclosing a heap overflow vulnerability (that can lead to execution of arbitrary code on a target system) in Cisco's IOS. Check out http://www.esecurityplanet.com/patches/article.php/3524701 for a short overview, for example. KRvW]
Re: [SC-L] Spot the bug
At 9:55 AM -0400 7/19/05, Mark Curphey wrote: If you fancy yourself as a good code reviewer you can play spot the bug at MSDN. They will be getting harder ! http://msdn.microsoft.com/security/ The overarching bug seems to be the assertion that there is only one bug, since those offering comments found two right off. The less excusable of the two bugs appears at first glance to be an out of bounds reference to an array, but on reflection is an error in choice of programming language. -- Larry Kilgallen
RE: [SC-L] Credentials for Application use
At 11:00 AM -0500 5/11/05, Gizmo wrote: Maybe I don't fully understand the concept of Single Sign-On. As I understand it, SSO allows a user to login to an application portal, and all of the applications that user accesses via that portal know who the user is and what rights they have within their respective application realms. As such, it is a front-end technology; the back-end applications don't know anything about this. That is _one_ (relatively insecure) method of implementing single sign-on. The general definition of single sign-on is that a user only logs on once to access a variety of computer applications. For some applications, relying entirely on Microsoft's credentials is adequate. For some applications, relying on the TSO login is adequate. For some applications, relying on Kerberos credentials is adequate. etc. -- Larry Kilgallen
RE: [SC-L] Credentials for Application use
At 11:28 AM -0400 5/11/05, Goertzel Karen wrote: Of course, and SSO is only as secure as (1) the assurance of the credential on which it bases its authentication decisions (a static password with an SSO is a really STUPID idea); That depends on the security of the channel between the user and the entity authenticating the password. A fixed password used to unlock a token by entering it into keys on the token is not bad. Use the keyboard associated with a programmable computer, and you increase the risks monumentally. -- Larry Kilgallen
Re: [SC-L] Why Software Will Continue to Be Vulnerable
At 8:05 AM -0400 5/2/05, Kenneth R. van Wyk wrote: Yet, despite that pessimistic outlook -- and the survey that forked this thread -- I do think that companies are demanding more in software security, even though consumers are not. Companies value time spent on cleanup more than consumers do. -- Larry Kilgallen
Re: [SC-L] Re: Application Insecurity --- Who is at Fault?
At 4:21 PM -0400 4/11/05, Dave Paris wrote: Joel Kamentz wrote: Re: bridges and stuff. I'm tempted to argue (though not with certainty) that it seems that the bridge analogy is flawed in another way -- that of the environment. While many programming languages have similarities and many things apply to all programming, there are many things which do not translate (or at least not readily). Isn't this like trying to engineer a bridge with a brand new substance, or when the gravitational constant changes? And even the physical disciplines collide with the unexpected -- corrosion, resonance, metal fatigue, etc. To their credit, they appear far better at dispersing and applying the knowledge from past failures than the software world. Corrosion, resonance, metal fatigue all have counterparts in the software world. glibc flaws, kernel flaws, compiler flaws. Each of these is an outside influence on the application - just as environmental stressors are on a physical structure. Corrosion and metal fatigue actually get worse as time goes on. Software flaws correspond more to resonance, where there is a defect in design or implementation. -- Larry Kilgallen
Re: [SC-L] Open Source failure analysis tool released for Linux
At 8:23 AM -0400 10/15/04, Kenneth R. van Wyk wrote: I believe that we don't do enough to analyze and learn from software failures. I believe the industry as a whole does plenty to analyze software failures, particularly considering how little is done to avoid those errors. Added analysis in the face of near-zero remediation would be useless. How many times do we see buffer overflow as the cause, yet even on this mailing list people still defend the use of languages that not only permit but actually promote such errors. -- Larry Kilgallen
Re: [SC-L] ComputerWorld interview with Theo de Raadt on Software Security
At 10:37 AM -0400 9/10/04, Kenneth R. van Wyk wrote: FYI, ComputerWorld is running an interesting interview with Theo de Raadt, on the state of software security, and OpenBSD in particular. See http://www.computerworld.com.au/index.php/id;1498222899;fp;16;fpid;0 for the complete text. He seems to never have hear of operating systems besides those that look like Unix or come from Microsoft. -- Larry Kilgallen
RE: [SC-L] Programming languages -- the third rail of secure coding
At 2:25 PM +0930 8/2/04, Nick Lothian wrote: What features make Ada safer than Java/C#? (I only have limited experience with Ada but from memory there was nothing that jumps out at me as something that Java lacks) Quoting from Tucker Taft in http://www.google.com/groups?selm=FD85Lq.Hyp.0.-s%40inmet.camb.inmet.com Integer conversion (casting) in Java is truncating. Integer conversion in Ada is value-preserving, with a run-time check on overflow (note that GNAT in some configurations suppresses overflow checks by default, which is naughty in some people's view ;-). To get truncation in Ada, you need to use an explicit mod/rem or Unchecked_Conversion. Markus Kuhn has a general comparison between Ada, Java and C++ at http://www.google.com/groups?selm=77nhuv%2429c%243%40pegasus.csx.cam.ac.uk Real-time aspects of Java garbage collection are discussed at http://www.google.com/groups?selm=a3eaa964.0304162240.540962aa%40posting.google.com Enumerated types are discussed at http://www.google.com/groups?selm=sbrvtvgdcdjps866mbuonffsl816ucgipd%404ax.com Comparing the Ada protected object to the Java monitor http://www.google.com/groups?selm=82347202.0305061140.53347ae1%40posting.google.com and other synchronization issues http://www.google.com/groups?selm=3D0CA980.5050505%40worldnet.att.net Strong typing of scalars http://www.google.com/groups?selm=254c16a.0305190830.21c61eca%40posting.google.com Lack of generics means containers are not type-safe in Java http://www.google.com/groups?selm=ba162549.0301052052.5a03f7a7%40posting.google.com Reference to a general comparison document from ACT Europe http://www.google.com/groups?selm=W0er9.42832%24qb.14876%40nwrddc01.gnilink.net -- Larry Kilgallen
RE: [SC-L] Programming languages -- the third rail of secure coding
At 1:03 PM +0930 8/1/04, Nick Lothian wrote: IMHO, though, any such effort is pointless. The reality is that we're going to be stuck with C/C++, Java, C#, FORTRAN, COBOL, and various interpreted/scripting languages for a very long time. What are peoples opinions of the languages listed above? Would I be overly controversial in saying: C/C++: Unsafe (for most people) It is possible to code correctly in (almost) any language, but the likelihood of success varies. To me the big issue of C* languages has to do with what assurances _management_ has that the effort will result in correct code. The C++ compilers I know of allow a programmer to drop into raw C, and given the low level of understanding safety and security issues across the programming population there will be a strong temptation to do that. Java/C#: Reasonably safe (both provide protection against buffer overflows, are type safe and provide built-in security mechanisms) FORTRAN/COBOL: Don't know - my impression is that COBOL is fairly safe Scripting Languages: Depends on the language. Lack of type safety can be a problem, but on the other hand they are usually safe from buffer overflows and the fact they you can do a lot more in fewer lines of code can make the code safer by making errors more obvious. Are there other languages in widespread use (ie, the language must be used more than - say - Python) that are safer than those listed above? Certainly Ada is a lot safer than those above, and the SPARK subset we have discussed here is even safer (not just by being a subset but also by supporting proofs of correctness). SPARK is much less widely deployed that whatever was used to implement Internet Explorer, but I have strong preference as to which of the two I would want used in the programming of fly-by-wire for an airplane on which I fly. -- Larry Kilgallen
RE: [SC-L] Programming languages -- the third rail of secure
coding Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Secured by aspStation Sender: [EMAIL PROTECTED] Precedence: bulk Mailing-List: contact [EMAIL PROTECTED] ; run by MajorDomo List-Id: Secure Coding Mailing List sc-l.securecoding.org List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: http://www.securecoding.org/list/ List-Unsubscribe: http://www.securecoding.org/list/ List-Help: http://www.securecoding.org/list/charter.php List-Archive: http://lists.virus.org Delivered-To: mailing list [EMAIL PROTECTED] Delivered-To: moderator for [EMAIL PROTECTED] At 3:14 PM -0400 7/30/04, Jeremy Epstein wrote: IMHO, though, any such effort is pointless. The reality is that we're going to be stuck with C/C++, Java, C#, FORTRAN, COBOL, and various interpreted/scripting languages for a very long time. Rather than argue about what makes something good/better, we'd be better off figuring out how to use them more effectively. The problem is that some people persist in using less-safe languages for new code. When put into a discussion (here) with those who say Use the best tool, a non-conversation takes place. If the list were retitled to be Secure Coding in Unsupportive Languages or Secure Coding with Approprate Languages then half of us would leave and the rest could actually conduct a discussion. -- Larry Kilgallen
Re: [SC-L] Programming languages used for security
At 10:39 AM -0700 7/14/04, Blue Boar wrote: ljknews wrote: At 11:38 AM -0700 7/13/04, Blue Boar wrote: ljknews wrote: The environment with which I am most familiar is VMS, and tradition is what guides secure interfaces. Inner mode code _must_ probe any arguments provided from an outer mode, probe the buffers specified by descriptors provided, etc. What do you do when you're handed a bad pointer? Return SS$_ACCVIO. So you put in an error handler that catches access ciolation before you try to use the pointer? OK, fair enough. What if the pointer points to memory you own, but not the right kind? The inner mode code probing ensure that the calling mode has the ability to read and/or write the memory (according to the semantics of the particular interface. The inner mode code does not distinguish between stacks and various heaps, just that the memory is readable or writable by the calling process in the mode from which the call is made. I have always been under the impression that raw pointers could always cause you problems. I've assumed that a secure language would have to eliminate that as a type. As have I. -- Larry Kilgallen
Re: [SC-L] Risk Analysis: Building Security In #3
At 5:30 PM -0600 7/12/04, Jared W. Robinson wrote: I read the paper, and found it interesting. I read the statistic 50 percent of security problems are the result of design flaws. Where does that number come from? Experience? I would say it comes from sloppy wording. At best, the author might discuss 50 percent of security problems discovered to date -- Larry Kilgallen
Re: [SC-L] Programming languages used for security
At 3:55 PM -0700 7/10/04, Crispin Cowan wrote: However, I think I do see a gap between these extremes. You could have a formal specification that can be mechanically transformed into a *checker* program that verifies that a solution is correct, but cannot actually generate a correct solution. Isn't that pretty much what the SPARK Inspector does ? -- Larry Kilgallen
Re: [SC-L] Programming languages used for security
At 8:49 AM -0500 7/9/04, Wall, Kevin wrote: If a GENERAL PURPOSE programming language were designed by scratch by someone who was both a security expert and programming language expert, what would this language (and it's environment) look like? More specifically, + What set of features MUST such a language support (e.g., strong static typing, etc.)? Such typing should include specification by the programmer of the range of values allowed in variables: -32767 to +32767, 0 to 100, 1 to 100, Characters a-z only, characters A-Z only, -10.863 to +4.368, etc. The language should also support exact specification of arithmetic operations to be performed for various types (overflow semantics, precision, decimal vs. binary arithmetic, etc.). This is important to ensure the desired behavior is obtained when one changes to a new compiler/interpreter, if only to have a program rejected as requiring behavior not supported on the new compiler or operating system. + Perhaps just as importantly, what set of features should the language omit (e.g., pointer arithmetic, etc.)? + What functionality should the accompanying libraries support (e.g., encryption, access control, etc.)? + What would be the optimal paradigm (from a theoretical, rather than pragmatic perspective) that such a language would fit into (e.g., object-oriented, functional, imperative, logic programming, etc.)? [Note: I mention theoretical, rather than pragmatic so that such a language would be unduly influenced by the fact that presently developers familiar with OO and imperative styles vastly out number all the others, with functional coming up a distant 3rd.] + (Related to the previous item) Would such a language be compiled or interpreted or something in between. -- Larry Kilgallen
RE: [SC-L] Education and security -- another perspective (was ACM Queue - Content)
At 2:26 PM +0100 7/9/04, David Crocker wrote: And much as I dislike Ada, I have to admit that if you don't intend to use dynamic binding and don't need the low-level features of C,... Which are those low-level features not available with Ada ? The C compilers I have used claim to be ANSI-compliant but lack anything equivalent to Ada's representation clauses. -- Larry Kilgallen
Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)
At 9:40 AM -0400 7/7/04, James Walden wrote: Dana Epp wrote: Of course, I also think students should have to take at least one course in ASM to really understand how computer instructions work, so they can gain a foundation of learning for the heart of computer processing. And I think they should be taught the powers and failures of C. Since I know many of you think I'm nuts for that, you might want to look at this outline with the same amount of consideration. I agree with you on both of those requirements. You need to have a basic understanding of assembly and how C is translated into assembly to understand the most common types of buffer overflow attacks. There are better languages for secure programming than C, but students are almost certainly going to have to read or write C at some point in their careers, so they need to understand it. What is wrong with this picture ? I see both of you willing to mandate the teaching of C and yet not mandate the teaching of any of Ada, Pascal, PL/I etc. This seems like the teaching of making do. -- Larry Kilgallen
Re: [SC-L] ACM Queue article and security education
At 1:02 PM -0700 7/1/04, Blue Boar wrote: ljknews wrote: I think it will be properly considered when the most strict portion of the software world is using language X. I have used many programs where the flaws in the program make it clear that I care not one whit about whether the authors of that program have opinion about anything I might use. They are simply not competent, either as individuals or else as an organization. By most strict portion, do you mean people that care most about correct code, proofs, and such? And organizations that hire the people you describe below to test the software they build. I don't deny that the bulk of the heavy lifting will be done by people well-qualified to do so. However, I'm of the school of thought that certain types of people who like to break things, and whose chief skill is breaking things, will always have a decent shot at finding a problem. There are people who couldn't build it, but they can sure break it. You don't typically get their attention until something is really, really popular. Lots of people bring their attention to issues they are paid to test. -- Larry Kilgallen
Re: [SC-L] ACM Queue article and security education
At 9:10 AM -0700 7/1/04, Blue Boar wrote: Language X may very well be a much better starting point, I don't know. I do believe that it will never be properly looked at until the whole world starts using it for everything, though. I think it will be properly considered when the most strict portion of the software world is using language X. I have used many programs where the flaws in the program make it clear that I care not one whit about whether the authors of that program have opinion about anything I might use. They are simply not competent, either as individuals or else as an organization. -- Larry Kilgallen
Re: [SC-L] ACM Queue article and security education
At 8:10 PM -0400 6/29/04, James Walden wrote: While there are non-university classes and workshops that teach software security, I doubt that a majority of developers have attended even one such class. Software security has to be integrated into the CS curriculum before we can expect a majority of developers to have the appropriate skills, and then there will still be the issue of applying them under deadline pressure. That said, I agree with most of the article. We can't wait for years to software security to become a standard part of the curriculum, and most of his suggestions, such as turning C compiler warnings into errors, are good ideas no matter what the current status of security education. I also second his enthusiasm for perl's taint mode. Teaching students how to avoid problems in C should be a separate (optional) course. Dealing with issues that have _not_ been solved in higher level languages should be a required course not burdened by the baggage of C. And whether something is a warning or an error is outside the scope of the programming language itself and into the build process which would allow completion in the face of warnings.
RE: [SC-L] Interesting article on the adoption of Software Security
At 9:16 AM -0500 6/11/04, Michael S Hines wrote: IBM had Language Environment (LE) before .NET come along. What is Language Environment (for either of those) ?
Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness
At 9:11 AM -0400 6/9/04, Gary McGraw wrote: Language makes a huge difference, eapecially in the realm of bugs. So not using C and C++ is smart. Use Java or C# instead. Or Ada, or PL/I, or Pascal, or Eiffel, etc. There are _lots_ of choices out there.
Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness
At 1:10 PM -0400 6/8/04, Jose Nazario wrote: thought some of you may find this editorial from the May 04 ACM Queue worth a read. ACM Queue is an interesting magazine and has a website at acmqueue.org. Buffer Overrun Madness ACM Queue vol. 2, no. 3 - May 2004 by Rodney Bates, Wichita State University Why do good programmers follow bad practices? In January 2003, the Slammer worm was reported to be the fastest spreading ever. Slammer gets access by exploiting a buffer overrun. If you peruse CERT (Computer Emergency Readiness Team) advisories or security upgrade releases, you will see that the majority of computer security holes are buffer overruns. These would be minor irritations but for the world's addiction to the weakly typed programming languages C and its derivative C++. And yet this mailing list, supposedly devoted to secure coding, seem polarized around the notion of shoring up those languages.
Re: [SC-L] Change of position
At 10:09 AM -0500 4/1/04, Gary McGraw wrote: Hi all, I have done lots of soul searching lately and have come to the conclusion that trying to make software secure is not worth the effort. I think instead we should concentrate more effort on protection technologies such as advanced stateful firewalls, intrusion detection mechanisms, host-based behavior control, and above all policy. We simply can't make software work effectively in a cost effective manner. I hope all of you will agree. I realize it is April Fools day, but all the host-based behavior control I have encountered is implemented by operating system software. If that software cannot be made secure, there is no hope. The major timewasting I see in software security is the leap of faith from: theoretically, safe code can be written in any language to: using any language to write safe code can be done within real-world economic constraints.
[SC-L] Re: Application Sandboxing, communication limiting, etc.
At 11:14 AM -0700 3/10/04, Jared W. Robinson wrote: Seems to me that the average user application doesn't need to open TCP/UDP ports for listening. Fixed in a previous major protocol stack. Doing the equivalent on DECnet requires privilege.
RE: [SC-L] Any software security news from the RSA conference?
At 5:58 PM -0600 2/27/04, Alun Jones wrote: Microsoft has a lot of code to contend with, and much of it is old - so a lot of it has had to be scrubbed clean of imperfections, and some has had to be re-written. A few years ago I heard the problem described as the opposite - that for Windows V.something about 30% of the existing code was entirely replaced (compared to corrected), which is more than _any_ organization can handle safely on a project of that size.
