On Sun, Jan 30, 2011 at 7:30 PM, Korny Sietsma <ko...@sietsma.com> wrote: > (this was a draft I started and abandoned when this post was new; but given > the ongoing discussion I thought I'd post at least my initial thoughts) > > This article took me down memory lane to a dark corner I don't really want > to re-visit - the world of C and C++, languages with no memory management, > no array size checking, and no exception mechanism. > > A lot of the sort of bugs he describes are familiar to me, from the dark > past - but haven't hit me in about 15 years. Why? Because to some extent, > when you are in a VM or using a modern "slow" language, you *are* in a jail; > at least, a jail that protects you from buffer overruns, and from unhandled > exceptions, and (in some) from integer overruns.
Right, but those aren't the majority of vulnerabilities in the that are inevitably in the types of programs coming from the languages I'm talking about (C#/Java). > Also a modern language drastically shrinks the amount of code, which (as the > author states) reduces the number of bugs as well. And it often means you > have real, significant peer review of every line of code, as well as (gasp) > unit tests - again, narrowing down the risk areas dramatically. > > You _can_ add extra security jail stuff to these languages - but I'm not so > sure it's necessary, beyond the obvious things like running the absolute > minimum as root, locking down filesystem permissions appropriately, etc. Are you suggesting that there isn't a good class of restrictions to try and place? What if you could limit per-table usage, say (via some schema arrangement or what-have-you as per your DB allowances); surely that's a benefit? And I would say it's far from trivial to lockdown the filesystem "appropriately" in sufficiently large projects. You'll sometimes find things running as users that they shouldn't, or some config change will change something in the wrong way, etc. > I wonder if it's worth re-visiting the core languages we use at the system > level - is it still true that system-level work needs to have the 100% > efficiency gained from using these horrible languages? I don't think so, because I don't think this is really the point. Clearly, there won't be a major re-write of everything into some new framework we deem secure. I guess I am more interested in, are there practical benefits to be gained from implementing the sort of 0+exactly-what-i-ask-for security policy. It may be that it's meaningless to have this embedded inside only .NET, and the benefits could only be realised from an OS-wide point of view. But I don't think that will be the case; I do think there could be some general benefits between .NET calls and things it interacts with (DBs, etc). > Has anyone done any > statistics on the root-causes of security issues, and how many of them would > be avoided by using a smarter language? And how much "critical" code would > still perform perfectly adequately in a language like, say, Google Go ? Lets define some things: JF = Jailing framework on top of existing language HA = Helpful API changes would be enough OS = OS buy-in would be required And then take a look at the OWASP Top 10 (for web applications), and see which of these would be required to completely (and directly) mitigate. * A1: Injection > Fixed by: HA, JF Injection would be used to "do something unexpected", so, if the given area is restricted to only do what it specifically states, we can imagine a RF helping. HA could be used in some fashion to take context and then determine invalid/valid on the basis of that (i.e. SqlParameter in C#, PreparedStatement in Java). * A2: Cross-Site Scripting (XSS) > Fixed by: HA, JF As above, API's do try and help here, but they require a bit of thought. That's because you need to also instruct it on the context. If, say, the language were constructed such that it could always recognise context, this would be less of an issue. It's possible to imagine this being technically achievable (perhaps), but it doesn't exist currently. Otherwise, you'll need to pass the context, and if you get it wrong, it will lead to a security issue. * A3: Broken Authentication and Session Management > Fixed By: HA, JF * A4: Insecure Direct Object References > Fixed By: HA * A5: Cross-Site Request Forgery (CSRF) > Fixed By: HA * A6: Security Misconfiguration > Fixed By: OS, JF * A7: Insecure Cryptographic Storage > HA * A8: Failure to Restrict URL Access > Fixed by: HA * A9: Insufficient Transport Layer Protection > Fixed by: HA * A10: Unvalidated Redirects and Forwards > Fixed by: HA, JF So, it seems that an better language (HA) would help, but it would take a lot of effort to get right. And you'd need to make people use it. And you'd need to update it when you notice a new security issue. JF would still be useful, and helps also *after* these vulnerabilities occur. That is to say, the point of Bernstein (if I may interpret it as so) is not 0 bugs (that's a goal), but resistance to bugs > 0. The jailing means that even when something does go wrong (say, you get an XSS vulnerability) you have layers of security such that that you can't do anything useful with it. New languages that avoid common bugs are clearly "good", but the general purpose of a jailing framework is still applicable. Which kind of implies it should be at an OS level, but even so, as above, I do think there is some value in JFs built into popular languages. > (disclaimer - having fled from the C/C++ world quite a while ago, I haven't > really looked at system-level languages for ages; there may have been > massive improvements that make my prejudices less accurate. Or maybe not.) FWIW, I'm not quite sure what your position is. Are you advocating strictly the invention and focus on new languages, and not at all interested in a jailing framework because you think what we have is enough? > - Korny (language bigot) -- Noon Silk http://dnoondt.wordpress.com/ (Noon Silk) | http://www.mirios.com.au:8081 > Fancy a quantum lunch? http://www.mirios.com.au:8081/index.php?title=Quantum_Lunch "Every morning when I wake up, I experience an exquisite joy — the joy of being this signature."
