The upcoming security fight [LWN.net]

Security is an important issue. Software users have been bitten by enough security incidents now that they are beginning to really think about whether a system they are considering deploying is sufficiently secure or not. As a result, software vendors are beginning to feel some heat from their customers on security. Among other things, security concerns have led directly to two new initiatives from Microsoft: the payment of bounties on information leading to the arrest of virus authors, and (apparently) an upcoming publicity campaign which will try to demonstrate that Microsoft products have a better security record than Linux.

Strangely enough, neither of those efforts will make Windows more secure in any way. But they will raise the stakes with regard to security issues. We should expect that, in the future, Linux-related security problems will receive much more attention than they have in the past. If Microsoft is out to prove itself more secure than Linux, it certainly will not waste any PR opportunities resulting from Linux vulnerabilities.

There are many implications to note from an increased emphasis on the perceived security of software products. Both developers and users of free software will want to redouble their efforts to tighten up security. The free software community may be better at the creation and deployment of secure software than just about anybody else, but our record is still far from good enough.

There is nothing new in the statement above. But consider for a moment the recent attempt to insert a backdoor into the Linux kernel. There is no way of knowing who was responsible for that attack, but it is worth thinking about who might have benefitted from it. The attempted back door - which did not enable remote attacks - would have been more useful for publicity than for actual exploits. Somebody wanted to be able to say that a vulnerability had been successfully planted in the Linux kernel. Any company with an interest in attacking the security record of free software - and there is more than one such company - would have gotten great mileage out of this kind of demonstration. It is safe to assume that there will be other attempts to insert malicious code into free software releases; a high level of vigilance will be required to detect and defeat those attempts.

The public perception of the relative security of operating systems has become an issue that means real money to the companies involved. When free software starts to eat too far into its competitors' bottom line, those competitors can be expected to fight back. Not all of them will choose to fight fairly; a quick look at the SCO case will verify that fact. Without giving in to absolute paranoia, we should expect the debate around security issues to take on a harsher edge. Things could get interesting, but this is a fight we should win decisively by doing what we always do: developing the best software we can with our users' needs in mind.

to post comments

The upcoming security fight

Posted Nov 13, 2003 2:30 UTC (Thu) by oloryn (guest, #7408) [Link] (1 responses)

Strangely enough, neither of those efforts will make Windows more secure in any way.

I'm not sure it's strange at all. Just another indication that Microsoft is more serious about security PR than it is about security itself. And I don't think it's peculiar to Microsoft either. "Prioritizing PR above actual effectiveness" is a common failing in both business and politics nowadays.

The upcoming security fight

Posted Nov 13, 2003 12:11 UTC (Thu) by rknop (guest, #66) [Link]

I'm not sure it's strange at all. Just another indication that Microsoft is more serious about security PR than it is about security itself.

...and Microsoft is far from alone. Indeed, I think in our society today, PR is far more important than anything real.

Consider airport security. The most important thing about all of that is to make everybody think that we're more secure, so that we'll all keep flying and flowing money into the airlines. Is it really more secure? Well, probalby a little, but that's not the main point.

Consumer Confidence is more important than Corporate Honesty or even Corporate Efficiency. And, if you have a convenient target that's communistic or easily equated with stealing music, put them down in order to make yourself appear better by comparison; that just makes your PR easier.

All very sad, really.

-Rob

The upcoming security fight

Posted Nov 13, 2003 3:51 UTC (Thu) by dkite (guest, #4577) [Link]

I wouldn't worry too much. As soon as there is a lull in the security problems, the subject will be
changed.

Remember, security is a non sell. It is a pain in the a**, expensive to create and maintain, and
impossible to sell. The best programming talent is taken away from more important (from a
marketing perspective) pursuits to do something that is invisible. It is all negative. Any sales
person will say that negatives cost sales, even when it makes you look good.

Another way to look at this is to consider it a blessing. Sortof a darwinian process. Any who
fall for a Microsoft "Security" sales pitch, well, deserve what they get. That leaves the rest as
good smart customers.

Oops. That wasn't very respectful, was it.

Derek

Virus authors are not a target

Posted Nov 13, 2003 6:16 UTC (Thu) by jreiser (subscriber, #11027) [Link]

Microsoft's reward is for information resulting in arrest and conviction of those who "illegally release" or who are "responsible for launching" damaging software; see http://www.microsoft.com/presspass/press/2003/nov03/11-05AntiVirusRewardsPR.asp. It will be interesting to see how or if a distinction will be made between writing and/or publishing such software (source code), versus actually deploying it (unleashing an executable instance.)

The upcoming security fight

Posted Nov 13, 2003 7:21 UTC (Thu) by ken (subscriber, #625) [Link] (11 responses)

What tools dose exist to detect security bugs in the software?

Time for a "how to write secure c/c++ with open source tools" article series.

Some tools for code security checking

Posted Nov 13, 2003 7:59 UTC (Thu) by eru (subscriber, #2753) [Link] (3 responses)

Some free code analysis tools I have seen and evaluated:

Flawfinder: http://www.dwheeler.com/flawfinder/

RATS: http://www.securesoftware.com/download_form_rats.htm

These are both somewhat conceptually similar code scanners, about equal in power, but one may catch things the other misses. Paranoid people might want to run both. These are very easy to use.

Splint: http://splint.org/

Splint is quite a bit more complex tool, and for maximum benefit you need to add some annotations to your code to describe expectations about what functions do. Handles C only (Flawfinder and RATS do both C and C++.)

Jlint: http://artho.com/jlint/

This one is for Java.

Some tools for code security checking

Posted Nov 13, 2003 8:36 UTC (Thu) by proski (guest, #104) [Link] (2 responses)

Valgrind can also be used to find security holes. Many errors in memory usage are exploitable. Valgrind 2.0.0 was released two days ago.

Some tools for code security checking

Posted Nov 13, 2003 14:31 UTC (Thu) by stijn (subscriber, #570) [Link] (1 responses)

I use valgrind and like it a lot. It is incredibly easy to use and quite powerful. Anyone know how valgrind, RATS, and flawfinder compare to each other?

Some tools for code security checking

Posted Nov 13, 2003 15:55 UTC (Thu) by eru (subscriber, #2753) [Link]

Comparing Valgrind to Flawfinder and RATS is a bit of an apples-and-oranges comparison, because Valgrind tries to spot errors at run-time, but the others try to analyze the source code. Both approaches have advantages and disadvantages. A run-time checker like Valgrind can see a problem only if your test case performs a sequence that involves it. A statical checker can potentially spot errors in places your test cases forget to visit. On the other hand, a statical checker may not be able to detect more complicated data-dependent errors. This is especially true of Flawfinder and RATS that do rather simple analysis. Splint is more powerful.

I would recommend that both kinds of tools be used.

The upcoming security fight

Posted Nov 13, 2003 9:39 UTC (Thu) by brouhaha (subscriber, #1698) [Link] (5 responses)

One of the best ways to "write secure c/c++ with open source tools" is to ditch C/C++ entirely and use a language that actually tries to promote reliable software. It's certainly possible to write secure code in C or C++, but it's way too much work, so it almost never is done in practice.

Some languages I recommend for this are Ada, Eiffel, Java, Modula 3, Python, Sather, Scheme, or Smalltalk. Ada, Eiffel, Modula 3, and Sather generally have little or no performance penalty compared to C or C++. That's true of Java as well, if it's compiled to native code.

C and C++ are like table saws missing their finger guards. If you're careful you can get away with it for a while, but it's eventually going to cause you a problem.

The upcoming security fight

Posted Nov 13, 2003 10:18 UTC (Thu) by jonth (guest, #4008) [Link] (1 responses)

And while we're at it, let's all speak Esperanto - English is inherently irregular, open to misunderstanding and difficult to learn. Look how easily lawyers can twist English to their own ends: it must be bad ;-)

I write low level software for very small embedded systems (mobile phones, to be precise); for the time being there is no alternative to C as an efficient, highly portable high level language for these devices. It is the lingua franca of the low level computing world: it's the first compilable language made available for almost every new processor. For anything that gets reasonably close to hardware, there just isn't any choice to C. (Even C++ is a stretch too far in this case.) Java for a device driver? Don't make me laugh.

The Linux kernel is itself written in C, and it's pretty secure. It's not perfect (nothing is), but for something that complicated, it's damn good. It got that way not because of the language in which it's written, but the process by which it's written. Trusting a language to be "inherently secure" is damn dangerous. Ask any Java developer.

cheers,

Jonth

The upcoming security fight

Posted Nov 14, 2003 2:29 UTC (Fri) by brouhaha (subscriber, #1698) [Link]

I respectfully disagree. I have written code in Ada and Modula 3 for small embedded systems, and it worked just fine. I didn't find any area in which they were deficient as compared to C. But the compiler was able to catch errors that would only have been found at runtime if I'd used C instead.

I also develop for Microchip PIC processors, and for those, I use assembly language, because even C isn't a good fit for them, though the newer PIC18 architecture is somewhat better suited to C.

Trusting a language to be "inherently secure" is damn dangerous.

I never said that you should trust a language to be inherently secure. Just because a table saw has a finger guard, you don't trust it to be perfectly safe. You still use it cautiously. That doesn't mean that a finger guard is useless.

The upcoming security fight

Posted Nov 13, 2003 13:22 UTC (Thu) by rmstar (guest, #3672) [Link] (1 responses)

You are completely right.

How many large security holes could have been avoided, for instance, if strings and arrays were propperly bound-checked? Certainly thousands. How many if assignment were not allowed in conditional clauses? etc.

C/C++ are error prone, and thus insecure, in every respect. From memory management all the way to their insane and barroque syntax.

Regards,
rmstar

The upcoming security fight

Posted Nov 13, 2003 18:00 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

You confuse C and C++. C++ has a standard string class that is properly bounds checked, and a standard vector class that can grow to unlimited size. However, too many C++ programmers are really C programmers and use the C mechanisms that they are more familiar with, instead of the safer classes that take care of memory management properly.

secure programming languages

Posted Nov 13, 2003 17:10 UTC (Thu) by zooko (guest, #2589) [Link]

The E language has been carefully engineered through and through to maximize security. It also features the unification of object-oriented programming and capability-security programming, which is a really neat idea.

Secure Programming HOWTO available, and use multiple tools

Posted Nov 13, 2003 17:45 UTC (Thu) by dwheeler (guest, #1216) [Link]

Actually, your request has been answered on several fronts.

The most important tool is the one between your ears. If you develop software, run, don't walk, to a book that will help you understand how to write secure programs. This stuff certainly isn't taught in schools. I give away a free book (both senses) that specifically discusses how to write secure programs: Secure Programming for Linux and Unix HOWTO at http://www.dwheeler.com/secure-programs.

There are various computer tools too, including my own flawfinder. My book lists many other tools tool (including RATS, splint, etc.). I agree with the other posters that using a collection of tools is far more effective than using just one tool. Each tool has its weaknesses, so using a combination of those tools will be far more effective.

The upcoming security fight

Posted Nov 13, 2003 9:20 UTC (Thu) by pointwood (guest, #2814) [Link]

Generally, I would consider more focus on security to be a good thing. That MS is focusing more on security is a good thing! Bad security in MS products doesn't just affect MS users.

I don't think MS's security push is all PR and I believe those saying that, is basically spreading FUD.

No, I'm not a MS fanboy, far from it, but I'm not a Linux zealot either.

Just the other day, I witnessed the CTO (or whatever he was) from MS Denmark, give a short speech about what MS is doing (hey, they gave me free ticket to the movie theater). I was actually expecting the "usual" MS sales speech with nothing interesting being said, but it wasn't. It was a pretty good overview of the problems they and others are facing in regards to security. He also showed how Windows 2003 was different from their previous OS'es in that regard. Windows doesn't automatically start all kinds of services and ports by default anymore, the user/administrator now have to do it themselves. That makes the systems much more secure by default and makes they much harder targets for crackers. Of course, it'll take many years before people upgrade their OS - lots of people are still running Win98 and so on.

Microsoft *is* able to turnaround, just look at what they did when they "discovered" the internet.

One of the big problems is getting people to apply the security patches. The world would look much better if people actually updated their systems, but many don't. The sad part of course, is that there is no easy solution.

Linux backdoor not just a marketing stunt

Posted Nov 13, 2003 15:26 UTC (Thu) by kfox (guest, #4767) [Link] (1 responses)

I find it disingenuous to blame this backdoor attempt on someone hoping to discredit Linux. The backdoor was clever and useful -- especially if it had been widely deployed by, for example, web hosting companies. The most obvious conclusion to draw is that someone wanted a silent backdoor to uid 0.

The structure of free software works both for us and against us. On the one hand, it forces us to create modular, independent services. On the other hand, it encourages uncontrolled copying and the false belief that services really are independent. Injecting a bug through a low visibility project is a good way to attack us.

Microsoft is smart to draw us into a fight on their terms. Microsoft is also smart to fan the paranoia of SCO and anti-Linux conspiracy. I think the window of opportunity to kill off Linux has closed. The right strategy now is to keep building community ownership of distributions (like Debian and Fedora) and stay focused on the thing we love: free software.

Linux backdoor not just a marketing stunt

Posted Nov 13, 2003 15:46 UTC (Thu) by zone (guest, #3633) [Link]

> Somebody wanted to be able to say that a vulnerability had been successfully planted in the Linux kernel.

That statement is as bad as those in the FUD we love so much. For all we know, the person who tried to get the exploit in wasn't planning on telling anyone, and was happy to stay silent and exploit the vulnerability. I would have expected LWN to take a more balanced approach to writing that paragraph-- state that planted exploits for PR reasons are a possibility, but that there is no evidence in this case.

Unsigned Java Web Start seems the most secure

Posted Nov 26, 2003 2:37 UTC (Wed) by MarkSwanson (guest, #9328) [Link] (2 responses)

Please correct me if I'm wrong, but is there anything even remotely as secure as
unsigned Java Web Start (JWS) applications?

Unsigned JWS applications have a few limitations (and there were some security holes
in versions released a year ago) but you can do pretty much anything you need to in
this environment except for access serial/parallel ports or native code. It seems to be
the most powerful/secure environment but seems to get the least mention. I wonder
why that is...

Unsigned Java Web Start seems the most secure

Posted Nov 26, 2003 8:14 UTC (Wed) by dvdeug (subscriber, #10998) [Link] (1 responses)

There are many forms of sandboxing that are just as secure as JWS, but without the speedhit of interpreted code. There are many that are more secure; if a program has internet access, it can be a jumping point for an attack on another system.

Unsigned Java Web Start seems the most secure

Posted Nov 26, 2003 20:56 UTC (Wed) by MarkSwanson (guest, #9328) [Link]

You say there are others, but why don't you name any?

Inquiring minds would like to know:
1. Name one that is as secure.
2. Name one that is more secure.

Perhaps I left things too open-ended. F.E. I don't consider the chroot
environment (or the capabilities settings Linux provides) as usable for
the masses as they require too much work to set up.