The most serious security vulnerabilities I've heard about for 2014 are Apple's SSL/TLS/HTTPS vulnerability, the OpenSSL Heartbleed vulnerability, FreeBSD's TCP bug, and of course the Mt. Gox bug that resulted in the company's bankruptcy.
The Mt. Gox bug was caused by a flaw in the way they designed the software. It did not have anything to do with the programming language used to create it. If you look at Apple's recent SSL/TLS/HTTPS vulnerability, the entire problem was caused by a misplaced goto statement in their C code. Interestingly, the LLVM compiler, which Apple evangelized in their development toolchain, was even capable of detecting and removing the error. Unfortunately, the advanced compiler feature wasn't used, and the vulnerability persisted for a long time in their OS X 10.9 code, breaking all SSL/TLS/HTTPS. The OpenSSL Heartbleed vulnerability that allowed encrypted SSL/TLS/HTTPS sessions to be snooped upon was caused by a lack of bounds checking in the connections heartbeat / keep-alive C code, not in any of the actual validated crypto code. FreeBSD's recent TCP bug that allowed privileged arbitrary code execution on servers was caused by C mishandling of memory references. The question we have to ask is: Would use of a (specific?) functional language prevented these? My opinion: Probably not in the case of Mt. Gox because their problems had more to do with their application design. As for Apple, I think the 'goto' feature is missing from at least Clojure. Both Haskell and Erlang have 'goto', but it's use isn't encouraged. I'm thinking that because these languages are functional, the goto feature works in a safer manner that wouldn't have allowed Apple's code to work with the failed certificate check. But that's just a guess. For OpenSSL's Heartbleed, I'm going to say that this wouldn't have been prevented even with functional programming. The problem lies in the design of the heartbeat code. One thing I do have to wonder about is whether or not this heartbeat code would have been designed differently if it were done in a functional programming language. It's worth keeping in mind that the higher level of abstraction most functional programming languages have would have contributed to a different design. FreeBSD's TCP bug *might* have been prevented if the functional programming language's runtime did effective memory management. I'm going to assume that everyone here agrees that functional programming languages have well-designed memory management. On Sun, May 4, 2014 at 5:40 PM, Magnus Therning <mag...@therning.org> wrote: > On Sun, May 04, 2014 at 09:24:08AM +0200, Cecil Westerhof wrote: > > I heard the stand that functional programming made it difficult to > > write secure programs. I do not know enough of functional > > programming yet to determine the value of a statement like this. > > What is the take here about it? > > It would be interesting to hear WHY functional programming would yield > less secure programs. What would then be the paradigm that results in > most security? Imperative, logical? > > Here is my take on it: > > It's widely acknowledged that writing secure programs is difficult. > I'd even go as far as saying that it's an inherently complex problem > in real-life applications. And as Brooke tells us, if we reduce > incidental complexity we can concentrate on the inherent complexity. > That would point us in the direction of high-level languages that > dispenses with distractions like memory management.[^1] > > Many programs worth writing becomes large, size is in itself a > contributor to complexity. So expressive languages will arguably aid > reducing the size of the code. > > Security and correctness are related, and arguing about correctness in > the face of shared state is tough, so even though Strachey tells us we > can get referential transparency in imperative languages it is my > experience that very few developers write imperative code with shared > state that is easy to argue about. That means we want immutability as > deeply rooted in the language as possible. > > I think this all adds up to pure functional languages being an > excellent choice if you want to write secure code. > > There are of course exceptions, e.g. in some very specialised > applications you need to have extremely fine control over the > behaviour of the computation is carried out. In these cases you'll > need languages that have a computational model that is closer to the > CPU (i.e. imperative). Of course you'll restrict the use of that > language to the "primitives" that require it and then make the jump to > a higher-level language as soon as possible. > > /M > > [^1]: In a reverse-engineering course Halvar Flake told us that the > first thing he looks for when starting to analyse an application is > the memory management. If the developers have decided to roll their > own memory management it's almost certain there's a security bug in > there somewhere. > > -- > Magnus Therning OpenPGP: 0xAB4DFBA4 > email: mag...@therning.org jabber: mag...@therning.org > twitter: magthe http://therning.org/magnus > > Heuristic is an algorithm in a clown suit. It’s less predictable, it’s more > fun, and it comes without a 30-day, money-back guarantee. > -- Steve McConnell, Code Complete > -- - EJR -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
