Slashdot Mirror


5,198 Software Flaws Found in 2005

An anonymous reader writes "Security researchers uncovered nearly 5,200 software vulnerabilities in 2005, almost 40 percent more than the number discovered in 2004, according to Washingtonpost.com. From the article: 'According to US-CERT...researchers found 812 flaws in the Windows operating system, 2,328 problems in various versions of the Unix/Linux operating systems (Mac included). An additional 2,058 flaws affected multiple operating systems.'"

8 of 257 comments (clear)

  1. The state of security by Ckwop · · Score: 4, Insightful

    There's two ways to look at this. I would say that it is quite unlikely that the quality of software with respect to security went down in 2005. Computer Security now has such high profile that software houses across the world are spending many dollars trying to provide better security.

    If you accept that security quality has not gone down, then you must conclude our ability to detect vulnerabilites is getting better. This is universally a good thing. Every vulnerability the "good guys" find before the "bad guys" is one we can have fix for before the bad guys take over our system.

    Then there's the other side of these figures. That's alot of vulnerabilities. Now, fair enough not all vulnerabilities are created equally but I'd bet at least 10% are serious enough to get your system taken over if you're not careful. That's a lot of ways to break in to my system and it's a lot of work to make sure you're not vulnerable.

    We have such a long way to go. For example, in PHP if they'd just follow Microsoft's example and put a SQL injection and XSS attack filter on information passed to web-pages we could close a serious hole in many web-applications. I've not looked at Ruby on Rails but I bet it fails this test too.

    For gods sake, if you're not writing an operating system you have no business using C. Read me lips: YOU CAN'T WRITE SECURE C. Not now, not after 20 thousand hours of training, not ever. Sure, it's possible to write secure C in theory but the difference between theory and practice is that in theory they're the same and in practice they are not. In practice, you have deadlines, in practice you have people on the team who have less security training than others, in practice you have developers who have just had children and don't get a lot of sleep. In practice, people make mistakes. Code reviews may help but they wont remove everything. If you write your software in C you're doomed to having silly security bugs. If you want to remove most of the worry about overflows, use a language that rules them out.

    Another thing, why should code we execute on our computers run at the maxmium privellege set of the user who's running it? Suppose my program checks a HTTP page against an MD5 hash periodically and sends an SMS through an internet based SMS gateway. Why should that program, if it wants to, be allowed to access the disk? I don't know about Java but C# has got a set of attributes that can control this type of behaviour. Really, we should be forcing declarations at the language level about what permissions each method of the program needs - the default being none of course.

    Simon.

  2. Re:Axe Grinding by ginotech · · Score: 5, Insightful

    That is messed up. You're right, simply updating a vulnerability doesn't make it a new one. You know why Linux and co. have more updated ones, though? Because people can actually see the bugs in the code!

  3. Umm am I stupid or something? by bogie · · Score: 4, Insightful

    Because I know I just woke up but that CERT page is listing APPLICATIONS FLAWS and NOT OS flaws.

    Is a flaw in "Gold FTP explorer" or Photoshop a Windows OS flaw?

    Am I the only one seeing this?

    --
    If you wanna get rich, you know that payback is a bitch
  4. Re:Language choice? by penguin-collective · · Score: 3, Insightful

    Modern unmanaged C++ is fine (STL containers instead of arrays, RAII, etc.),

    Modern unmanaged C++ is NOT fine; STL permits many kinds of bugs that are analogous to buffer overflows. Furthermore, modern software systems are composed of many different modules, and just because you happen to be careful in your modules doesn't mean others are careful in theirs. Finally, without full garbage collection, you cannot have full runtime safety.

    but I often wonder why people still write in C at all, particularly when it comes to Open Source software.

    People prefer C to C++ because for the small increase in safety that C++ gives, it's far too complicated and complex a language. People don't use languages other than C/C++ because those languages interoperate poorly with existing C/C++-based libraries (this is C/C++'s fault), tend to have bloated runtimes, and have only a tiny user community. And, yes, many people don't even realize that there is a problem.

    We are not the bearded heroes of the 70s - it's time to write in a modern language.

    The bearded heroes of the 70s actually knew better. Back in the 1970's and 1980's, C was of no significance. When people were using HLLs back then, those languages were generally a lot safer than C. The rise of C was a historical accident, related to the rise of BSD UNIX and microcomputers.

    But, yes, I share your sentiment: it would be good to see security bugs by language choice. And I'll give you this much: C++ is an improvement over C, but it's not a solution.

  5. Re:Language choice? by jc42 · · Score: 4, Insightful

    I often wonder why people still write in C at all, ...

    Well, my last big project was written almost entirely in C for the simple reason that that's what the client wanted. We did a lot of prototyping in perl and python, but that code wasn't acceptable for delivery; we had to rewrite all the production code in C. If not, it wouldn't be accepted.

    Much of the explanation was that the client had accepted C++ and java in earlier projects, and they were disasters for all the familiar reasons. They were determined that this wouldn't happen again, so they went with a "proven" language with a track record of use in major successful systems.

    Similarly, I have a couple of friends who recently did a project in Cobol. They hated it, but they wanted to get paid, and that's what the client would accept.

    In the Real World[TM], the decision about which language to use is very often made by managers who aren't programmers and don't have a clue about the real issues. So they make decisions based on things that they can understand and measure.

    --
    Those who do study history are doomed to stand helplessly by while everyone else repeats it.
  6. Not so shocking ... by lasindi · · Score: 4, Insightful

    "researchers found 812 flaws in the Windows operating system, 2,328 problems in various versions of the Unix/Linux operating systems (Mac included). "

    If we listened to just the media you would have thought Windows has thousands and the others only had a few dozen. I promise I'm not trolling, but do those numbers stop and make anyone on the site re-think stances? We all saw the numbers that put Firefox with more holes then IE earlier this year too. Could MS be doing a better job, but just getting hammered in the press (who are mostly Apple users by the way)? MS holes get lots of press while other operating systems get a free pass.


    If you look at the first post, you'll see that the real count of vulnerabilities isn't so shocking after all:

    Windows 671
    UNIX/Linux 891
    Multiple 1512


    Also, when you consider the fact that "UNIX/Linux" includes many different operating systems (e.g., GNU/Linux, *BSD, OS X, etc.), you can't give any one Unix operating system the blame. Remember that although some code is shared between projects, GNU/Linux and the *BSD are more or less completely different code bases. In any case, the simple counts of vulnerabilities don't take into account the severity of each, so the real winner is even more ambiguous.

    I find myself defending MS allot on this site, and it's nice to have some numbers from a respected neutral organization to debate some of you guys with. I'm sure after this piece they will be re-classified as MS zealots, but what can ya do.

    While Brian Krebs might be tainted by his misrepresentation (see the post I got the numbers from), I can't imagine anyone here claiming that US-CERT is somehow a bunch of MS zealots. In fairness to Microsoft, they've definitely come a long way with SP2, and I don't feel nearly as vulnerable when using an SP2 machine as I did with previous Windows versions (though the recent WMF hole makes me a bit more worried). without considering the severity of each vulnerability. But they're still no where near the point where I would switch from Linux.

    --
    I have discovered a truly remarkable proof of this theorem that this sig is too small to contain.
  7. Unfair by Kaelthun · · Score: 4, Insightful

    "The ignorant define themselves" why is there even a discussion going on about the essence of the word "flaw"? Fact is that this research has not been fair because all Linux distro's, UNIX variants (such as BSD) and Mac are counted as one, and MS Windows as another. You cannot compare the multitude of Linux distro's to the one-man platform of MS Windows. If there would have been a tally between, say, Redhat, Ubuntu, FreeBSD, NetBSD, OpenBSD, Mac OS (I dunno what version it is in atm) and MS Windows, and all stats would have been listed seperately ... that would have been fair and clear. Now it's just a mash of all these stats with just one simple query on it SELECT bugs FROM stats WHERE os = Windows. THey just mashed the rest together and called it "the rest".

    --
    -------
    Userfriendly? Sure it is, unless you aren't computerfriendly!
    /me to a classmate on FreeBSD
    1. Re:Unfair by ComputerizedYoga · · Score: 4, Insightful

      thing is, all of those distros use the same software base. Redhat, Ubuntu, *BSD, they're all host to apache, samba, bind, openssh, php, gcc ... they're all essentially the same, once you get past package management, the kernel and the c libraries.

      If you want to count "OS" flaws, you need to remove ALL the third-party apps. That means in linux, you'd JUST be counting the flaws in the kernel and glibc, and in BSD only the core system as well. And those aren't even going to be distro-specific.

      While you're right that it's probably not fair to shove os-x vulns in with the unix/linux category (os-x is its own unique animal and has a lot of things that no other *nix has) I think it is fair to mash together the F/OSS nixes. Or at least to mash together their non-os-specific parts.

      Of course, these comparisons are inherently unfair, if they're used as a metric for "which OS is more secure". That's become something of a moot point. No matter how someone calculates their metrics, someone or another is going to be displeased with their methodology. What's more interesting, and more to the point, is the sheer number of vulns found across the board, and that's the whole point of the story.