Paranoid Penguin - Interview with Marcus Meissner
MB: In my own day job at the bank, I frequently interact with software developers who have very little understanding of security or of secure coding. Although ignorant is the last word that I, being a humble nonprogrammer, would use in this context, it seems that security has not traditionally been an important part of programming culture and training. Have you found that to be the case yourself? Has this situation changed in recent years?
MM: I have found this to be the case, yes. In former times, it was mostly “get things working”. Now, it is a bit better. Everyone knows about viruses, worms, trojans and so forth. However, it is not optimal yet; the hard part is convincing people that their code might be exposed to such problems.
I am regularly hearing, “but then it will just be broken into the user account, not root” or “it will run behind the firewall here” as excuses. But, I see definite improvements.
MB: We seem to be stuck in an endless parade of security vulnerabilities in the full range of applications on which we depend—graphics editors, compression libraries, server dæmons, even security tools. I think some of us assumed that over time, as security awareness in the development and user communities increased, the rate of security bugs would decrease. Why, do you think, it hasn't? Or, is this rate, in fact, decreasing?
MM: This has several factors at play.
First, the classes of problems have changed due to security research over time.
The trivial exploit technologies, like stack and heap overflows and format string problems, are explored and can be captured by technology today, and programmers understand them.
But, integer overflows still are an uncharted sea for most—“Why is there a difference between 'signed' and 'unsigned'? Why is this multiplication bad?”—and are hard to find using today's compiler technology.
The new kind of applications on the Web has brought entirely new problems for things like SQL injection, command injection, cross-site scripting and others. Due to the startup boom, lots of those applications were not designed with security in mind. Here, the easy Web development languages are a bit at fault too—on one hand, allowing beginners to develop applications easily, but on the other hand, making it trivial to make mistakes.
Also, the increased integration of the network and Internet has brought more code up to the light, as in “can now be accessed from the network”. Just think of all the image libraries written with a command-line local user in mind that now run as a back end to Web galleries.
I personally see no reduction of security problems in the near future. At most, it will level off.
MB: It might seem non-intuitive for developers of non-networked desktop applications, like gPhoto, to have to worry about security. But, of course, such applications frequently are used as stepping-stones in attacks against other processes and for gaining access to system data or other local resources. Do you ever find yourself lecturing other developers on threat scenarios like that?
MM: Hmm, not for gPhoto or Wine at least, but for other distribution-related packages.
MB: What changes, especially improvements, have you seen lately in application architecture? What changes would you like to see?
MM: I see different languages being used, which bring different architecture concepts. The trend away from C toward Java, C#, Ruby and so on with stricter typing is helpful.
I would like to see people not re-inventing/reprogramming everything existing anew, but trying more to reuse existing, proven code.
MB: How do you think the race to Web-oriented application architectures has affected application and operating system security?
MM: It makes securing the process more difficult. As an OS vendor, we now are just one part of the chain—the secure base system used to browse the Web.
MB: Is it just me, or has the emergence of cross-site scripting (XSS) added a whole new dimension to the security landscape? I don't remember many pre-Web attack vectors that allowed you to use one person's server to attack other users. The older paradigm was that you attacked the system, not the users per se.
MM: Definitely, the advent of Web applications has brought new problems, and seeing that there still are dozens of XSS issues fixed per week shows that the problems are not contained yet.
And yes, when interacting between the network, the user is way more interactively involved than before. Consider phishing problems, for instance, which even though they fall under social engineering, do endanger system security.
MB: How has the emergence of Web services affected the SUSE Security Team's work? Is it easier to isolate and address bugs in Web applications, which are usually written in scripting languages, than in compiled applications?
MM: Fortunately, not much, as we do not include very many. Quite a lot of fixes went into the PHP core packages in the last few years, and the Web applications we include had their share of problems.
What we also shipped is an increasing rate of Web browser security fixes, as the browsers now get good reviews too. More than a hundred Mozilla bugs were fixed in the last few years, for instance.
As for isolating and addressing bugs, it's still at the same difficulty level. You need to understand the code and fix the problem. Also, as we usually back-port patches, we need to understand those, and there the language does not matter much. Plus, Web applications usually are not smaller than regular programs.
- Server Hardening
- Unikernels, Docker, and Why You Should Care
- diff -u: What's New in Kernel Development
- 22 Years of Linux Journal on One DVD - Now Available
- Controversy at the Linux Foundation
- Giving Silos Their Due
- Non-Linux FOSS: Snk
- Don't Burn Your Android Yet
- What's New in 3D Printing, Part III: the Software