[SC-L] Containing bad code
Given the recent discussion, I thought the list might be interested in: http://www.links.org/?p=1242. I'm currently working on transparently wrapping libtiff (that is, wrapping it such that the calling application is unaware it is wrapped). Using Capsicum For Sandboxing http://www.links.org/?p=1242 FreeBSD 9.0 http://www.freebsd.org/releases/9.0R/announce.html, released in January 2012, has experimental Capsicumhttp://www.cl.cam.ac.uk/research/security/capsicum/ support in the kernel, disabled by default. In FreeBSD 10, Capsicum will be enabled by default. But unless code uses it, we get no benefit. So far, very little code uses Capsicum, mostly just experiments we did for our paper. I figured it was time to start changing that. Today, I’ll describe my first venture – sandboxing bzip2 http://www.bzip.org/. I chose bzip2 partly because Ilya Bakulin https://github.com/kibab had already done some of the workhttps://github.com/kibab/capsicum/blob/00546c31c6f9681bf045d31219c10a7d8e9e45e9/contrib/bzip2/bzip2.c for me, but mostly because a common failure mode in modern software is mistakes made in complicated bit twiddling code, such as decompressors and ASN.1 decoders. These can often lead to buffer overflows or integer over/underflows – and these often lead to remote code execution. Which is bad. bzip2 is no stranger to this problem: CVE-2010-0405http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0405 describes an integer overflow that could lead to remote code execution. The question is: would Capsicum have helped – and if it would, how practical is it to convert bzip2 to use Capsicum? The answers are, respectively, “yes” and “fairly practical”. First of all, how does Capsicum mitigate this problem? The obvious way to defend a decompressor is to run the decompression engine in a separate process with no privilege beyond that needed to get its job done – which is the ability to read the input and write the output. In Capsicum, this is easy to achieve: once the appropriate files are open, fork the process and enter capability mode in the child. Discard all permissions except the ability to read the input and write the output (in Capsicum, this means close all other file descriptors and limit those two to read and write), and then go ahead and decompress. Should there be a bug in the decompressor, what does the attacker get? Well, pretty much what he had already: the ability to read the input file (he supplied it, so no news there!) and the ability to write arbitrary content to the output file (he already had that, since he could have chosen arbitrary input and compressed it). He also gets to burn CPU and consume memory. But that’s it – no access to your files, the network, any other running process, or anything else interesting. I think that’s pretty neat. But how hard is it to do? I answer that question in a series of diffs on GitHub, showing a step-by-step transformation of bzip2 into the desired form. I used a technique I like to call *error-driven development*; the idea is you attempt to make changes that will cause compilation to fail until you have completely accomplished your goal. This is a useful way to reassure yourself that you have made all necessary updates and there’s nothing hiding away you didn’t take care of. If you follow along by building the various stages, you’ll see how it works. It turns out that in bzip2 this matters – it isn’t very beautifully written, and the code that looks like it might cleanly just take an input file and an output file and do the work in isolation, actually interacts with the rest of the code through various function calls and globals. This causes a problem: once you’ve forked, those globals and functions are now in the wrong process (i.e. the child) and so it is necessary to use RPC to bridge any such things back to the parent process. Error-driven development assures us that we have caught and dealt with all such cases. So how did this work out in practice? Firstly, it turns out we have to give the compressor a little more privilege: it writes to stderr if there are problems, so we need to also grant write on stderr (note that we could constrain what it writes with a bit more effort). The callbacks we have to provide do not, I think, let it do anything interesting: cause the program to exit, make the output file’s permissions match the input file’s, and remove the input or output files (ok, removing the input file is slightly interesting – but note that bzip2 does this anyway). Secondly, because we have not yet decided on an RPC mechanism, this particular conversion involves quite a bit of boilerplate: wrapping and unwrapping arguments for RPCs, wiring them up and all that, all of which would be vastly reduced by a proper RPC generator. Try not to let it put you off [image: :-)] Finally, the system has (at least) one global, errno. I did not deal with that so far, which means some errors will report the wrong error – but it is not particularly hard
Re: [SC-L] SearchSecurity: Badware versus malware
On 11 May 2012 20:07, Gary McGraw g...@cigital.com wrote: The article does not suggest otherwise. Well, it certainly does _suggest_ it: All of the things that we do to improve software security are aimed explicitly at the badware problem. It doesn't say it, though, I agree. gem On 5/11/12 1:51 PM, Ben Laurie b...@google.com wrote: On 8 May 2012 07:18, Gary McGraw g...@cigital.com wrote: hi sc-l, What¹s worse, bad software or malicious software? In fact, what¹s the difference? My second column for SearchSecurity is all about that. Read it today. And pass it on. http://searchsecurity.techtarget.com/opinion/Gary-McGraw-Eliminating-badw are-addresses-malware-problem Bottom line: Talking about malware may be more fun and entertaining than talking about endless security bugs, but if we¹re going to combat malware we have to start with the badware vector. Fixing badware universally would plug one hole - and it's certainly a hole worth plugging. But it won't eliminate malware - it seems it is not hard to persuade users to install it for you, for example. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] Microsoft SDL report card
On 18 April 2011 18:46, Andy Steingruebl stein...@gmail.com wrote: On Fri, Apr 15, 2011 at 7:33 AM, Ben Laurie b...@google.com wrote: Which is why I am interested in and devoting most of my time now to capability systems. Ben, Is your work focused on the technical bits of this, or the human interaction pieces? In short: both. Seems to me that much of the work on technical implementations of capabilities, fine-grained permissions, MAC, etc. have been worked out repeatedly over time and we've never come up with very usable systems. Or ones that stay usable over time I would contend that actually, we haven't really ever tested usability because we've never really used these systems except in the lab. One of the things I'm excited about in our recent work is that we've started to make progress on hybrid models where capability stuff can coexist with existing stuff. For example, Caja and FreeBSD Capsicum. Try setting the permissions for an application when you install it, or figure out whether it is asking for more permissions than it really needs, etc? The underlying problem with these questions right now is that permissions are expressed in terms of low-level system services (e.g. file read/write), but actually we should be making decisions at higher levels where the permission correspond to things the user understands (e.g. my account at Google or my Flickr photos or this album in Picasa). Capabilities seem well suited to this level of permission management. Thoughts? - Andy ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] Microsoft SDL report card
On 4 April 2011 16:45, Gary McGraw g...@cigital.com wrote: In my opinion, the most interesting thing about stuxnet was the payload. So what was the huge stride made since Code Red wrt Stuxnet? See: How to p0wn a Control System with Stuxnet http://www.informit.com/articles/article.aspx?p=1636983 (September 23, 2010) You might also listen to Langner on Silver Bullet (the longest episode ever, but a good one): http://www.cigital.com/silverbullet/show-059/ gem On 4/1/11 9:16 AM, Ben Laurie b...@google.com wrote: On 31 March 2011 13:03, Gary McGraw g...@cigital.com wrote: hi sc-l, Yesterday, Microsoft released an SDL report card of sorts called The SDL Progress Report. It covers the history of the SDL from 2004-2010. You should read it. http://www.microsoft.com/downloads/en/details.aspx?FamilyID=918179a7-61c9 -487a-a2e2-8da73fb9eade For some reason the tech press is mostly discussing DEP and ASLR adoption (covered on pages 18 and 19). Though I guess that is the news hook the PR flacks are hyping, I think there are many other parts of the report that have plenty to teach about how a software security initiative evolves. (WRT the two anti-exploit tactics, see an article I co-authored with Ivan Arce from Core Assume Nothing: Is Microsoft Forgetting a Crucial Security Lesson?http://www.informit.com/articles/article.aspx?p=1588145 (April 30, 2010).) Microsoft has made huge strides since the days of CodeRed, NIMDA and Slammer. Stuxnet? The best part of what they're doing is being very open about the progress they are making and the approach that seems to be working for them. I, for one, would love to see other reports like this issued by software vendors. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] InformIT: comparing static analysis tools
On 3 February 2011 16:02, Jim Manico jim.man...@owasp.org wrote: Chris, I've tried to leverage Veracode in recent engagements. Here is how the conversation went: Jim: Boss, can I upload all of your code to this cool SaaS service for analysis? Client: Uh no, and next time you ask, I'm having you committed. I'm sure you have faced these objections before. How do you work around them? Don't use SaaS, obviously. I'd rather see LLVM's static analysis tools get improved (the framework, btw, is really nice to work with). -Jim Manico http://manico.net On Feb 3, 2011, at 1:54 PM, Chris Wysopal cwyso...@veracode.com wrote: Nice article. In the 5 years Veracode has been selling static analysis services we have seen the market mature. In the beginning, organizations were down in the weeds. What false positive rate or false negative rate does the tool/service have over a test suite such as SAMATE. Then we saw a move up to looking at the trees. Did the tool/service support the Java frameworks I am using? Now we are seeing organizations look at the forest. Can I scale static analysis effectively over all my development sites, my outsourcers, and vendors? This is a good sign of a maturing market. It is my firm belief that software security has a consumption problem. We know what the defects are. We know how to fix them. We even have automation for detecting a lot of them. The problem is getting the information and technology to the right person at the right time effectively and managing an organization-wide program. This is the next challenge for static analysis. bias-alertI think SaaS based software is more easily consumed and this isn't any different for software security/bias-alert -Chris -Original Message- From: sc-l-boun...@securecoding.org [mailto: sc-l-boun...@securecoding.org] On Behalf Of Gary McGraw Sent: Wednesday, February 02, 2011 9:49 AM To: Secure Code Mailing List Subject: [SC-L] InformIT: comparing static analysis tools hi sc-l, John Steven and I recently collaborated on an article for informIT. The article is called Software [In]security: Comparing Apples, Oranges, and Aardvarks (or, All Static Analysis Tools Are Not Created Equal) and is available here: http://www.informit.com/articles/article.aspx?p=1680863 Now that static analysis tools like Fortify and Ounce are hitting the mainstream there are many potential customers who want to compare them and pick the best one. We explain why that's more difficult than it sounds at first and what to watch out for as you begin to compare tools. We did this in order to get out in front of test suites that purport to work for tool comparison. If you wonder why such suites may not work as advertised, read the article. Your feedback is welcome. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC ( http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC ( http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow
