Rust, the Mozilla-developed language that recently hit 1.0, emphasizes safety, a potentially large selling point for a language designed for systems-level programming.
But what does it mean to say that a language is "safe" -- even if you're not using it for low-level functions? How much of that safety is the language itself, and how much of it is the programmer (as one blogger noted when attempting to test how the Heartbleed vulnerability might surface in Rust)? I put that question to the folks responsible for developing some of the common languages in use today.
Larry Wall, the inventor of Perl -- set to debut its long-awaited sixth version later this year -- asserted that while "it's possible to write insecure code in any language," the construction of the language is a factor. "In Perl," he stated in an email, "all strings and arrays know their own length, so you can't get the tail ends of old strings showing up by accident in new strings without working at it really hard. Perl 5 also has a tainting mechanism that catches most accidental use of untrusted string data as input to dangerous operations."
Wall also noted that the version of the language and its interpreter or compiler also matter, especially as time and circumstance march on. "[The Perl community] cares about older versions enough that it is willing to issue security patches for them without forcing people to upgrade," he wrote. "We think it's really important to distinguish maintenance upgrades on stable versions from functional upgrades to more modern releases. Certainly the lesson of the recent past is that security is always going to be an arms race, and deploying software that is not field-upgradeable is just an exploit waiting to happen, regardless of the language used."
Zeev Suraski, CTO of Zend, makers of various PHP development tools and solutions, defended PHP as "protected from a very big class of potential vulnerabilities, including vulnerabilities similar to Heartbleed." Because PHP doesn't allow the programmer to perform her own memory management, he noted, developers can never read or write into memory.
He did point out that none of this obviates how PHP can be, and is, used unsafely: "It of course doesn't make PHP code immune to potential security issues – but they're typically applicative, for example, relying on end-user data and plumbing it into database queries or filesystem operations without sanitizing it first." Such security issues are typically exposed when PHP code makes use of system-level calls, as was hypothesized with the recent Ghost vulnerability.
Ruby's creator Yukihiro "Matz" Matsumoto had similar feelings about his language: "Ruby checks [for] memory boundary for every access so that we don't have buffer overflow security vulnerability (if Ruby VM itself does not have [them])," he wrote in an email. "So it must be much safer than C. Ruby also [has] data tracking from [the] outside world, so dangerous operations based on malicious data read[s] can be warned." But as with PHP, the biggest security issues in Ruby these days involve the way software written with it deals with the outside world -- for example, Ruby on Rails, the Web framework, which had to be patched several times in succession in 2013 to deal with remote-code vulnerabilities.
Part of the seductive power of any new language is an assurance it will provide a better, faster, and more inherently secure solution. Higher-level languages -- Perl, PHP, Ruby -- obviate the need to do low-level work to accomplish common tasks, and Rust may address an area where low-level mistakes are easy to make. But "safe" and "unsafe" are moving targets along with the languages themselves and the tasks they're used for. The only barrier between us and the next deadly buffer overflow, Heartbleed, or cross-site scripting issue is the vigilance of the developer herself.
If there's one question Rust may be able to answer, it's whether or not one can have a language that runs both fast and with a modicum of safety -- safer, at least, than C. According to the Computer Language Benchmarks Game site, Python 3, Ruby, PHP, and Perl chalked up a median speed of around 1/50 of C for a set of common numerical benchmarks. Rust, however, proved to be a promising exception: The vast majority of its benchmarks were comparable with C for speed.
[Paul Krill contributed reporting for this story.]