Re: [SC-L] What's the next tech problem to be solved in software security?
First off, many thanks to all who've contributed to this thread. The responses and range of opinions I find fascinating, and I hope that others have found value in it as well. Great stuff, keep it coming. That said, I see us going towards that favorite of rat-holes here, namely the "my programming language is better than yours, nyeah!" path. Let's please avoid that. I'm confident that we've seen it enough times to know that it ends with no clear winners (but plenty of losers). Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com smime.p7s Description: S/MIME cryptographic signature ___ 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?
> 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. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ 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?
On Thu, 7 Jun 2007, Steven M. Christey wrote: | On Wed, 6 Jun 2007, Wietse Venema wrote: | | > more and more people, with less and less experience, will be | > "programming" computer systems. | > | > The challenge is to provide environments that allow less experienced | > people to "program" computer systems without introducing gaping | > holes or other unexpected behavior. | | I completely agree with this. This is a grand challenge for software | security, so maybe it's not the NEXT problem. There's a lot of | tentative work in this area - safe strings in C, SafeInt, | StackGuard/FormatGuard/etc., non-executable data segments, security | patterns, and so on. But these are "bolt-on" methods on top of the | same old languages or technologies, and some of these require | developer awareness. I know there's been some work in "secure | languages" but I'm not up-to-date on it. | | More modern languages advertise security but aren't necessarily | catch-alls. I remember one developer telling me how his application | used Ruby on Rails, so he was confident he was secure, but it didn't | stop his app from having an obvious XSS in core functionality. | | > An example is the popular PHP language. Writing code is comparatively | > easy, but writing secure code is comparatively hard. I'm working on | > the second part, but I don't expect miracles. | | PHP is an excellent example, because it's clearly lowered the bar for | programming and has many features that are outright dangerous, where | it's understandable how the careless/clueless programmer could have | introduced the issue. Web programming in general, come to think of | it. I think this all misses the essential point. Safe strings, stack guards, non-executable data segments - these are all solutions to yesterday's problems. Yes, they are still important; yes, the solutions aren't yet complete. But the emerging problems are exemplified by your comment about XSS. The real issue that we still have not internalized is that the "field of operations" has changed dramatically. We still think of a "program" as something that runs on some box somewhere. The "programming model" is the hardware and software inside that box. "Security" is about making sure that that box does what it's supposed to do - no more and no less. Everything that crosses the boundary of that box is "just I/O". But increasingly that boundary is dissolving. Yes, much of the Web 2.0 rhetoric is overblown, but much of what it's selling you - the applications that live in the network, the storage that lives in the network, etc. - is already here to one degree or another. An XSS attack cannot even be described within the confines of a single box. It's an attack against a distributed "program" running on a distribute "machine" consisting of at least three different "boxes", each doing exactly what it was designed to do. Nothing we do to the hardware in the individual boxes only will make the slightest difference at this higher level of abstraction. Nothing we do in programming languages that only deal with a single box will help. We don't today even have any formalisms for describing these distributed programs - much less safe ways for building them. So I would say that the grand challenge today is to move on. Start thinking about how to secure the global network - not the wires, not the individual boxes, not the API's, but the emergent properties of the whole thing. This will require very different thinking. Some things are clear: We gained safety within the individual boxes only by giving up some freedom. Self-modifying code? No thanks. Unstructured control flow? We can do better. Everything is just bits? No, everything has a type. And so on. Meanwhile, on the network side, what do we have? Untyped byte streams; mobile code; anything-goes paste-ups; no effective, enforced distinction between between code and data; glorification of any hacky means at all that gets something out there *yesterday*. The techniques we are applying with increasing success inside the box today - hardware enforcement of executability constraints and stack overflows; type-safe, memory-safe languages; static analysis; and so on - are ideas that go back 30 years. What's making them practical today is (a) years of refinement on the basic ideas; (b) much faster hardware. I can't recall any really new idea in this area in a *long* time. When it comes to these new problems, we're not much further along than we were in the early 1960's for traditional programming. We don't have any real models for the computation process, so no starting point for defining safe subsets. We don't even know what "safe" means for a global computation: At least for a program I've run on my box, I can in principle write down what I expect it to do and not do. For a "program" using resources on my box and a bunch of other boxes, many belonging to parties I know nothing about and who generally don't know each other
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] What's the next tech problem to be solved in software security?
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. And for this particular vulnerability these languages are effectively catch- alls. (As long as all your code is managed and the runtime implementation itself doesn't contain BO's). The fine grained access control model of the Java runtime (I guess .NET has the same thing?) is also a big win. This is not an add on framework, but is built right into the language. As Ben and Robert have pointed out, we're likely to see similar improvements when developers make more use of frameworks for implementing application tiers. It's a lot harder to introduce XSS issues when using modern MVC frameworks (e.g. .NET's, JSF, WebWork) than cobling a view layer together using JSPs and servlets. It would still be possible for developers to introduce vulnerabilities when using these frameworks, but it's a lot more difficult. > I remember one developer telling me how his application used > Ruby on Rails, so he was confident he was secure, but it didn't > stop his > app from having an obvious XSS in core functionality. It's ironic that RoR is well known for it's policy of preferring sensible defaults instead of extensive configuration, yet you have to explicitly perform HTML encoding of data included in a web page. > PHP is an excellent example, because it's clearly lowered the bar for > programming and has many features that are outright dangerous, > where it's > understandable how the careless/clueless programmer could have > introduced > the issue. Web programming in general, come to think of it. There are also examples of languages/frameworks that get it right, such as JBoss Seam where both SQL injection and XSS are difficult to introduce by default. It's easier to build secure applications when the building blocks themselves provide security by default. Developers will adopt frameworks because they make programming easier - if these frameworks also prevent common security vulnerabilities then that's a big win for more secure applications. Where security pro's can help out is in pointing out poor security defaults in frameworks and getting the owners to change them. Change once, benefit everywhere. regards, Stephen "the glass is half full" de Vries ___ 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?
I've recently been working on providing better secure programming defaults. There's a great opportunity for doing so for applications written on top of frameworks/libraries. See our paper " Towards Security by Construction for Web 2.0 Applications" at a recent W2SP workshop. -Ben On 6/7/07, Steven M. Christey <[EMAIL PROTECTED]> wrote: > > On Wed, 6 Jun 2007, Wietse Venema wrote: > > > more and more people, with less and less experience, will be > > "programming" computer systems. > > > > The challenge is to provide environments that allow less experienced > > people to "program" computer systems without introducing gaping > > holes or other unexpected behavior. > > I completely agree with this. This is a grand challenge for software > security, so maybe it's not the NEXT problem. There's a lot of tentative > work in this area - safe strings in C, SafeInt, > StackGuard/FormatGuard/etc., non-executable data segments, security > patterns, and so on. But these are "bolt-on" methods on top of the same > old languages or technologies, and some of these require developer > awareness. I know there's been some work in "secure languages" but I'm > not up-to-date on it. > > More modern languages advertise security but aren't necessarily > catch-alls. I remember one developer telling me how his application used > Ruby on Rails, so he was confident he was secure, but it didn't stop his > app from having an obvious XSS in core functionality. > > > An example is the popular PHP language. Writing code is comparatively > > easy, but writing secure code is comparatively hard. I'm working on > > the second part, but I don't expect miracles. > > PHP is an excellent example, because it's clearly lowered the bar for > programming and has many features that are outright dangerous, where it's > understandable how the careless/clueless programmer could have introduced > the issue. Web programming in general, come to think of it. > > - Steve > ___ > 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. > ___ > -- Thanks, -Ben ___ 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?
On Wed, 6 Jun 2007, Wietse Venema wrote: > more and more people, with less and less experience, will be > "programming" computer systems. > > The challenge is to provide environments that allow less experienced > people to "program" computer systems without introducing gaping > holes or other unexpected behavior. I completely agree with this. This is a grand challenge for software security, so maybe it's not the NEXT problem. There's a lot of tentative work in this area - safe strings in C, SafeInt, StackGuard/FormatGuard/etc., non-executable data segments, security patterns, and so on. But these are "bolt-on" methods on top of the same old languages or technologies, and some of these require developer awareness. I know there's been some work in "secure languages" but I'm not up-to-date on it. More modern languages advertise security but aren't necessarily catch-alls. I remember one developer telling me how his application used Ruby on Rails, so he was confident he was secure, but it didn't stop his app from having an obvious XSS in core functionality. > An example is the popular PHP language. Writing code is comparatively > easy, but writing secure code is comparatively hard. I'm working on > the second part, but I don't expect miracles. PHP is an excellent example, because it's clearly lowered the bar for programming and has many features that are outright dangerous, where it's understandable how the careless/clueless programmer could have introduced the issue. Web programming in general, come to think of it. - Steve ___ 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?
Kenneth Van Wyk: > What do you think is the _next_ technological problem for the > software security community to solve? PLEASE, let's NOT go down the > rat hole of senior management buy-in, use [this language], etc. (In > fact, be warned that I will /dev/null any responses in this thread > that go there.) So, what technology could/would make life easier for > a secure software developer? Better source code analysis? High(er) > level languages to help automate design reviews? Better security > testing tools? To any of these, *better* in what ways, specifically? I've often said that programming should be a million times more difficult, so that fewer people will be able to write code. However, that is not the direction where things evolve. Instead, more and more people, with less and less experience, will be "programming" computer systems. The challenge is to provide environments that allow less experienced people to "program" computer systems without introducing gaping holes or other unexpected behavior. An example is the popular PHP language. Writing code is comparatively easy, but writing secure code is comparatively hard. I'm working on the second part, but I don't expect miracles. The solution is likely to be a completely different programming model. The spreadsheet is approaching its 30th birthday. That is too long ago. Wietse ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What's the next tech problem to be solved in software security?
you've got a few questions there ... i'll answer the first one. i might copy the suggestion from someone [i can't remember who at the moment] who suggested the next step in programming in-general is more parallel programs [in order to increase speed]. this is obviously complicated and will create new security problems. but i mean (it hardly needs to be said), we have enough trouble with the problems we already have. On 6/6/07, Kenneth Van Wyk <[EMAIL PROTECTED]> wrote: > Hi SC-L, > > [Hmmm, this didn't make it out to the list as I'd expected, so here's > a 2nd try. Apologies for any duplicates. KRvW] > > At the SC-L BoF sessions held to date (which admittedly is not > exactly a huge number, but I'm doing my best to see them continue), I > like to ask those that attend what we can be doing to make SC-L more > useful and meaningful to the subscribers. Of course, as with all > mailing lists, SC-L will always be what its members make of it. > However, at one recent SC-L BoF session, it was suggested that I pose > periodic questions/issues for comment and discussion. As last week > was particularly quiet here with my hiatus and all, this seems like a > good opportunity to give that a go, so... > > What do you think is the _next_ technological problem for the > software security community to solve? PLEASE, let's NOT go down the > rat hole of senior management buy-in, use [this language], etc. (In > fact, be warned that I will /dev/null any responses in this thread > that go there.) So, what technology could/would make life easier for > a secure software developer? Better source code analysis? High(er) > level languages to help automate design reviews? Better security > testing tools? To any of these, *better* in what ways, specifically? > > Any takers? > > Cheers, > > Ken > - > Kenneth R. van Wyk > SC-L Moderator > KRvW Associates, LLC > http://www.KRvW.com > > > ___ > Secure Coding mailing list (SC-L) SC-L@securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > ___ > > > -- mike 68 65 6c 6c 6f 20 74 6f 20 79 6f 75 2c 20 68 65 78 20 64 65 63 6f 64 65 72 2e ___ 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] What's the next tech problem to be solved in software security?
Hi SC-L, [Hmmm, this didn't make it out to the list as I'd expected, so here's a 2nd try. Apologies for any duplicates. KRvW] At the SC-L BoF sessions held to date (which admittedly is not exactly a huge number, but I'm doing my best to see them continue), I like to ask those that attend what we can be doing to make SC-L more useful and meaningful to the subscribers. Of course, as with all mailing lists, SC-L will always be what its members make of it. However, at one recent SC-L BoF session, it was suggested that I pose periodic questions/issues for comment and discussion. As last week was particularly quiet here with my hiatus and all, this seems like a good opportunity to give that a go, so... What do you think is the _next_ technological problem for the software security community to solve? PLEASE, let's NOT go down the rat hole of senior management buy-in, use [this language], etc. (In fact, be warned that I will /dev/null any responses in this thread that go there.) So, what technology could/would make life easier for a secure software developer? Better source code analysis? High(er) level languages to help automate design reviews? Better security testing tools? To any of these, *better* in what ways, specifically? Any takers? Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com smime.p7s Description: S/MIME cryptographic signature ___ 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. ___
