NetBSD being a secure OS, yet having a large list of vulnerabilities in its software.

I know that in the NetBSD Guide, it says that NetBSD is a secure operating system, and I've never read anywhere on the internet that it isn't...
But with a huge list of vulnerabilites in its software and nothing being done (at least quickly) to patch them, how secure could it possibly be?
This is what I get when I run pkg_admin audit or audit-packages:

Code:

Package python26-2.6.6nb6 has a sensitive-information-exposure vulnerability, see http://secunia.com/advisories/43463/
Package pango-1.28.3 has a denial-of-service vulnerability, see http://secunia.com/advisories/42934/
Package evince-2.30.3nb5 has a buffer-overflow vulnerability, see https://bugzilla.gnome.org/show_bug.cgi?id=640923
Package samba-3.0.37nb5 has a security-bypass vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0787
Package samba-3.0.37nb5 has a sensitive-information-exposure vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0926
Package samba-3.0.37nb5 has a security-bypass vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0728
Package automake14-1.4.6 has a insecure-file-permissions vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4029
Package rpm-2.5.4nb6 has a privilege-escalation vulnerability, see http://secunia.com/advisories/40028/
Package suse_base-10.0nb5 has a privilege-escalation vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3856
Package suse_freetype2-10.0nb5 has a arbitrary-code-execution vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0946
Package suse_freetype2-10.0nb5 has a buffer-overflow vulnerability, see http://secunia.com/advisories/41738/
Package suse_freetype2-10.0nb5 has a arbitrary-code-execution vulnerability, see http://secunia.com/advisories/41958/
Package suse_libpng-10.0nb4 has a information-disclosure vulnerability, see http://secunia.com/advisories/35346/
Package suse_libpng-10.0nb4 has a unknown-impact vulnerability, see http://lists.opensuse.org/opensuse-security-announce/2010-06/msg00001.html
Package suse_libpng-10.0nb4 has a remote-system-access vulnerability, see http://secunia.com/advisories/40302/
Package suse_libtiff-10.0nb4 has a denial-of-service vulnerability, see http://secunia.com/advisories/40422/
Package suse_gtk2-10.0nb4 has a arbitrary-code-execution vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1194
Package suse_openssl-10.0nb5 has a denial-of-service vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0590
Package suse_openssl-10.0nb5 has a signature-spoofing vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0591
Package suse_openssl-10.0nb5 has a denial-of-service vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0789
Package suse_openssl-10.0nb5 has a remote-denial-of-service vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1377
Package suse_openssl-10.0nb5 has a remote-denial-of-service vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1378
Package suse_openssl-10.0nb5 has a remote-denial-of-service vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1379
Package suse_openssl-10.0nb5 has a signature-spoofing vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5077
Package suse_openssl-10.0nb5 has a denial-of-service vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1386
Package suse_openssl-10.0nb5 has a session-hijack vulnerability, see http://lists.opensuse.org/opensuse-security-announce/2009-11/msg00009.html
Package suse_openssl-10.0nb5 has a man-in-the-middle-attack vulnerability, see http://lists.opensuse.org/opensuse-security-announce/2010-04/msg00000.html
Package suse_openssl-10.0nb5 has a unknown-impact vulnerability, see http://lists.opensuse.org/opensuse-security-announce/2010-06/msg00001.html
Package suse_openssl-10.0nb5 has a remote-system-access vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2939
Package suse_openssl-10.0nb5 has a remote-system-access vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3864
Package suse_openssl-10.0nb5 has a remote-security-bypass vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4180
Package ns-flash-9.0.289 has a remote-system-access vulnerability, see http://www.adobe.com/support/security/bulletins/apsb10-14.html
Package ns-flash-9.0.289 has a remote-system-access vulnerability, see http://www.adobe.com/support/security/bulletins/apsb10-16.html
Package ns-flash-9.0.289 has a arbitrary-code-execution vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2884
Package ns-flash-9.0.289 has a arbitrary-code-execution vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3654
Package ns-flash-9.0.289 has a multiple-vulnerabilities vulnerability, see http://www.adobe.com/support/security/bulletins/apsb11-02.html
Package gimp-2.6.11nb2 has a arbitrary-code-execution vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4540
Package gimp-2.6.11nb2 has a arbitrary-code-execution vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4541
Package gimp-2.6.11nb2 has a arbitrary-code-execution vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4542
Package gimp-2.6.11nb2 has a arbitrary-code-execution vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4543
Package qt4-libs-4.7.1nb1 has a arbitrary-code-execution vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0046
Package qt4-libs-4.7.1nb1 has a arbitrary-code-execution vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0049
Package qt4-libs-4.7.1nb1 has a arbitrary-code-execution vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0050
Package qt4-libs-4.7.1nb1 has a sensitive-information-exposure vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0051
Package qt4-libs-4.7.1nb1 has a arbitrary-code-execution vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0052
Package qt4-libs-4.7.1nb1 has a arbitrary-code-execution vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0054
Package qt4-libs-4.7.1nb1 has a denial-of-service vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2621
Package qt4-libs-4.7.1nb1 has a denial-of-service vulnerability, see http://secunia.com/advisories/40588/
Package ffmpeg-20090611nb8 has a multiple-vulnerabilities vulnerability, see http://secunia.com/advisories/36805/
Package ffmpeg-20090611nb8 has a remote-system-access vulnerability, see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3429
Package ffmpeg-20090611nb8 has a denial-of-service vulnerability, see http://secunia.com/advisories/43197/
Package vlc-1.0.6nb5 has a denial-of-service vulnerability, see http://www.videolan.org/security/sa1007.html
Package vlc-1.0.6nb5 has a remote-system-access vulnerability, see http://www.videolan.org/security/sa1102.html

All that software with vulnerabilities has nothing to do with NetBSD. NetBSD is fairly secure OS probably second only to OpenBSD. Third party software that you installed is neither written nor maintained by NetBSD team. Please de-install that third party crap and you will have perfectly secure system again.

But with a huge list of vulnerabilites in its software and nothing being done (at least quickly) to patch them, how secure could it possibly be?

The flaw in your argument is expecting third-party applications (on any platform) to have been sanitized, cleaned up, & sterilized to the point where no bugs exist. There isn't enough manpower in any Open Source project to make this kind of guarantee. Plus, if one project cleaned up all the vulnerabilities, flaws, & other imperfections found in a software package commonly used across multiple platforms, that sanitized version may not resemble the same package on a different platform.

As an example, look at Firefox -- a commonly used browser which is not terribly secure or well implemented. When I use this application on multiple platforms, I expect it to work reasonably the same. Yes, it would nice if the Open Source projects could figure out all of its ills, & while some bugs probably get reported back to the Mozilla project, OS project developers don't have enough personnel to painstakingly analyze each & every third-party application they host. It simply isn't feasible.

What operating system projects can strive for is to implement a platform where errant applications can't take down the remainder of the system. Hopefully, the programming interfaces exposed to applications is consistent, simple, & works as advertised.

So, when projects state how secure they are, they are referencing the base system which is under the total jurisdiction of the project developers themselves. Good as some projects may be, they have limited resources to dedicate to third-party applications.

The following from OpenBSD says it all and is also applicable to NetBSD:

Quote:

The packages and ports collection does NOT go through the same thorough security audit that is performed on the OpenBSD base system. Although we strive to keep the quality of the packages collection high, we just do not have enough human resources to ensure the same level of robustness and security.

__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump

Net(etc)BSD is right to have non-installation of vulnerable packages as the default. This can be overridden on a per-package basis, or generally. The information to evaluate the risk to a given system is there.

It's possible, and probably not too hard, to script automatic acceptance of packages with certain vulnerabilities and not others. If someone would set it up and make it available on a separate basis that'd be great. But it shouldn't be part of a BSD or its packages or ports system; just "well known" among the community.

As for blocking many of the potential attacks at a system interface level, I suppose it's possible for much of this; but that would be even more annoying, hard to implement and maintain, and less transparent. Often the reason for a particular application's problems would be in this layer, but near-impossible to find.

Microsoft has 10,000 developers working on the next version of Windows, and even though Vista/7 have been a pretty good improvement on Windows security, you need not look any further than your favorite security site to see that even an army of developers cannot possibly write a perfectly secure OS (not that Microsoft is trying for security as a first priority, though).

The OpenBSD team, on the other hand, has 100-150 or so developers and they DO focus on security and code correctness, and yet they still cannot guarantee third party apps will be secure.

The security of the applications people run on your operating system is not an indication of the overall security of the platform.

However, many techniques are in place on several OS's to help mitigate some well known attack vectors.. like buffer overflow protection and memory space protection.

The point is that the base OS is secure, what you choose to run atop of that is your responsibility to maintain.. even if at the end of the day that means you need to go beyond the realm of supported and apply a few patches and build things yourself.

I'm assuming that bugs and security issues would be reacted to more quickly in certain Linux distributions (Fedora, OpenSuse, Ubuntu) than they would be in FreeBSD or NetBSD... Isn't that correct? I'm figuring that the best way to install FreeBSD or NetBSD would be to go for a minimal installation, like Fluxbox and a lightweight browser. It keeps everything tidy and small, and there aren't all the security issues happening from having 500 packages installed. That's not really what I want, since I use *BSD or Linux (for now) as the only operating system I have. Windows bores me to death, but one day when I buy a new computer it'll come with Windows installed, obviously. I like using Windows, but I hate learning about it. I like using Linux/*BSD and I like learning about it. But all the security issues and the slow fixes of them on NetBSD and the very slow compilation and installation time on FreeBSD and NetBSD are really making me use Fedora. I want GNOME and everything and constant security updates and bugfixes. I like the BSD's, but I don't have Windows and I'm only using open source operating systems right now, so I really need Fedora to have everything and not have to wait for updates or live with the security problems when I have 500 packages installed like I do when I use Fedora (which I'm doing now).