Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Hi, Michael here.
A few weeks ago, my boss, Steve Lipner placed a copy of eWeek on my desk opened to an article entitled, “Java Security Traps Getting Worse.” In summary, the article, which is also available online (http://www.eweek.com/article2/0,1895,2128071,00.asp) lamented the state of security in applications written using Java. I’ll let you read the article and draw your own conclusions, but I have my own thoughts on the problem, and I want to explain my position by way of example.
In 2003, I presented a paper on the SDL at the Workshop on Software Security (http://dimacs.rutgers.edu/Workshops/Software/abstracts.html) and the topic of conversation turned quickly to how bad the C and C++ programming languages are from a security perspective. Someone from the audience shouted out that “We should just ban C and C++ and replace it with Java.” I replied that we could ban <insert programming language of choice> and replace it with <another programming language of choice> and we’d still have lots of security bugs. I said this because programming languages by themselves don’t make secure code, but I believe that a number of people believe they will. I think a good many people believe that so long as the language is not C or C++, then the code is inherently secure.
This belief in a programming security silver bullet is very dangerous, and I believe we address this nicely in the SDL. In fact, a lack of a silver bullet is a core principle of the SDL. We teach people, actually, no we don’t teach people: we ram it down engineer’s throats: the number one skill a person designing, building or testing software should learn is that input should never be trusted. Regardless of OS or programming language. Ever.
Don’t get me wrong, I’m not bagging the data in the article; I’ve seen people believe that .NET code is a security panacea, and it’s not. In all of our SDL education we stress the point that .NET code is not a security cure-all, and we make sure that developers understand that if you choose to ignore the golden rule about never trusting input no language or tool will save you. Using safe string functions can help mitigate risks of buffer overruns in C/C++, but won’t help with integer arithmetic, XSS, SQL injection, canonicalization or crypto issues.
The key point is that languages are just tools; anyone using a tool needs to understand the strengths and limitations of any given tool in order to make informed use of the tool.
One final thought; in my opinion, well-educated software developers using C/C++ who follow secure programming practices and use appropriate tools will deliver more secure software than developers using Java or C# who do not follow sound security discipline.
Care to speculate on the costs of the SDL as applied to managed code vs. C/C++?
I know your general distaste for analogies so I can't resist throwing one out there.
You can shave safely with a straight razor. People did it for years. I does take a lot of skill to get right though, plenty of practice, etc. Or, you could use a safety razor and get the job done without taking nearly as much risk. You can still cut yourself but probably not a several inch deep gash...
Yes, I know this isn't a perfect example. Part of replacing one programming language with another is to gain efficiency. We replaced assembler with C and other languages for efficiency in the coding aspects. We replace C with C++ for efficiency in both coding and design. We replace them with C# and/or Java to get better efficiency in frameworks, modeling, etc.
If I get rid of C/C++ and/or ban certain function calls I remove whole classes of potential vulnerabilities. Of the classes left I'm equally susceptible to these types of flaws in C, C++, Java, and C#. But does that really mean I haven't gained anything from an assurance perspective?
I think you're setting up a straw-man here. Sure lots of people think that replacing C/C++ with Java/C# will automatically make me secure, but just because some people believe that position doesn't mean you won't get measurable benefit from moving to managed code.
Thank you for saying this. I hope more people are reading this blog. Coincidentally, I <a href="recently'>http://www.splatteredbits.com/tp/articles/writing-secure-code">recently posted an article on my own blog about not trusting input</a>. It can be a hard message for developer's to preach, though.