Slashdot Mirror

← Back to Stories (view on slashdot.org)

5,198 Software Flaws Found in 2005

Posted by Zonk on from the better-to-find-them-than-not dept.

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.'"

9 of 257 comments (clear)

  1. Axe Grinding by alanw · · Score: 5, Informative
    Brian Krebs is clearly either extremely stupid, or has an axe to grind. If you look at the Cert Cyber Security Bulletin 2005 Summary, you can see that many of the lines in it end in "(Updated)" A simple count of lines gives the results that Brian quotes, however there are far more "(Updated)" entries in the Unix/ Linux Operating Systems section. Removing these lines gives the following results:
    including excluding
    "(Updated)" "(Updated)"
    Windows 813 671
    U/L 2328 891
    Multiple 2057 1512

    (sorry about the spacing - can't find any way of doing it)

    greatly reducing the proportion of Unix/Linux vulnerabilities

    1. Re:Axe Grinding by camcorder · · Score: 2, Informative

      Also from security perspective I would like to know ratio of remote vulnerabilities on these platforms and how much of them DoS vulnerabilities and more critical compromise vulnerabilites.

      It's correct that a DoS vulnerability might be actually more critical as it was thought (as in recent IE bug). I think numbers as such very deceptive. From an user perspective I can say this year brought me lots of stupid worm mails which mostly targeted from Windows platforms.

    2. Re:Axe Grinding by jc42 · · Score: 4, Informative

      Hey, you missed the even bigger method of increasing the unix/linux score: counting each distro separately.

      Thus, if you go to distrowatch.com, you find 100 distros for linux alone. So for most actual kernel bugs, you can count each one at least 100 times. And for apps that run on all unix releases, the multiplier can be a lot higher.

      Of course, there are several distros of Windows, too. But not nearly as many, and the people adding up the bug counts somehow always seem to miss this trick with Windows.

      Anyone else got a favorite way of producing misleading bug scores?

      --
      Those who do study history are doomed to stand helplessly by while everyone else repeats it.
  2. Language choice? by Anonymous Coward · · Score: 2, Informative

    I would like to see some data showing the correlation between applications written in unmanaged languages and those with buffer overflow and similar exploits.

    Modern unmanaged C++ is fine (STL containers instead of arrays, RAII, etc.), but I often wonder why people still write in C at all, particularly when it comes to Open Source software. We are not the bearded heroes of the 70s - it's time to write in a modern language. If you don't want to sacrifice speed and system level programming for a managed environment, write in modern C++.

    1. Re:Language choice? by aaronl · · Score: 2, Informative

      And here is the problem with that:

      PERL - not installed on some UNIXes
      Python - not installed on most UNIXes
      Ruby - not installed on any UNIXes

      If your app won't run in the default environment of your target platform, you create a lot more work to change the environment. Or you could write the app in a way so that it *will* run in the default environment, which means using C or shell. Usually, PERL will work, but there are several places that it isn't installed by default, even today.

    2. Re:Language choice? by YU+Nicks+NE+Way · · Score: 2, Informative
      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.
      No. The decision is made be a manager who needs to balance the business issues of long-term supportability and cost within the current infrastructure against other technical benefits. That decision is not as simple as, say, vi versus Emacs, much less C versus Java versus C# versus Python.
  3. These numbers are meaningless. by master_p · · Score: 4, Informative

    Ok, I've made a 'hello world' program in C++...I had 0 bugs in it, do I win?

    Seriously now, these numbers are useless without mentioning lines of code and programming languages. Suse Linux 9.3, for example, has over 7,000 RPMs, which is an enormous amount of software.

    Absolute bug numbers are meaningless.

  4. Re:Other issues by symbolic · · Score: 2, Informative


    I've noticed that on some of the 'nix-based alerts, the initial "discovery" was made in 2004, but not reported by various distros until after the beginning of 2005. I also noticed that with some of them, ALL of the distros listed reported the problem in 2004, but then, someone else chimes in right after the beginning of 2005 (Avaya Security Advisory), basically restating what has already been announced by several other parties prior to 2005.

  5. Re:The state of security by Decaff · · Score: 2, Informative

    And security problems are not just C problems, any language like Java, .NET, PHP, C# can also have their issues.

    Apart from the fact that .NET isn't a language, I would be interested to know what issues you think Java and C# have. Almost all the problems with C (and almost all problems with security) are due to bounds checking. Java and C# have automatic built-in bounds checking.

    PHP can have issues because it is interpreted, and so you can get code injection. Java and C# aren't interpreted.