My first call would be to wait, on the presumption that the window is usually small enough to not be an issue. In fact, in many cases, important fixes (think Bind, SSH, Apache) are rolled out before the vulnerabilities are even reported.
Does anyone have any evidence to suggest that the wait time between vulnerability report and update availability is long enough to justify carving out that niche with OpenVAS? Thomas Chandrashekhar B wrote: > I agree to the points here. If we assume that all are using distribution > specific packages (that makes it easy), problem is solved. I have one > question though, when vulnerability is reported in a package and vendor > hasn't released an update, there's a time window where user is unaware that > vulnerability exist. Do we have to report or wait till update is released? > > Chandra. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Thomas > Reinke > Sent: Wednesday, October 22, 2008 8:00 PM > To: [email protected] > Subject: Re: [Openvas-plugins] How to handle some linux vulnerabilities > > Carsten Koch-Mauthe wrote: >> Hello List, >> >> Chandra and i had a disscusion how to handle linux tests. The problem is, > that >> most linux distros provides patches for vulnerabilities which not change > the >> version of the fixed program. So local security checks are not useful in > that >> case. For example cups package on Suse linux 10.3 which is version >> 1.2.12-22.17 . Last Security announcement for cups says that every version > >> below 1.3.9 is vulnerable. But this Suse Version is a patched non > vulnerable >> version. So checking for Version < 1.3.9 will give a false positive. I > think >> it is nessesary to check which distro is used and the script then have to >> check for distro specific version numbers like the securityspace debian >> scripts are doing. >> Chandra has made the following proposals. >> >> === Schnipp === >> Hello Carsten, >> >> This is one of the issue with Linux based scripts. I raised this in IRC, > no >> response came. >> >> The issue is, >> >> 1. As you have pointed, most of the Linux distros have their own packages >> and versions and updates are released much later than vulnerabilities are >> disclosed to the public. >> >> 2. There are tar package installations (some might prefer downloading and >> installing on their own) that are actual package versions. To these, most > of >> the time, as soon as vulnerabilities are disclosed to the public, patch is >> made available. >> >> In my view, both these have to be verified. The way to go about it would > be, >> Option 1: >> 1. Release the plugin assuming the public release version (not distros >> package version). > > Many false positives will ensue. > >> 2. When updated packages are made available by each vendor, develop local >> checks (automated checks) and add a check in #1 to see which Linux distro > it >> is and based on that, either, >> a) exit() if the local check is available. If not, proceed with >> checking. >> or >> b) Launch the local check for the specific distro by adding that as a >> dependency > > A maintenance headache, to say the least. > >> Option 2: >> 1. Maintain a backport version of each package for each Linux distribution >> in an inc. > > You're kidding, right? > >> 2. Check for the backported version based on the Linux distribution >> 3. Towards the end of the plugin, we can check for manually installed >> original version. >> >> Option #2 would be ideal to do, but requires good amount of work initially >> to capture versions for each package and keep that up to date every time > an >> update is released. > > It's more than just a good amount of work initially, it's a huge amount > of work on an ongoing basis. > >> Please let me know your views. > > I understand the motivation for doing the above, but have to admit, I > don't like the approaches, nor do I necessarily agree with the rational. > > First, to make it clear, local security checks for distributions can > be written in a way that there are no false positives. As understood, > this requires us to assume the user is using a distribution specific > package. The only two reasons to write scripts that go beyond this > is because we think > > a) distributions are late in their delivery of patches, AND > that their tardiness is a sufficient security issue to warrant > us addressing it. > > b) enough users build their own software from source and that it > warrants us checking for these situations. > > Re assumption of late delivery of patches: do we really want to be > in the business of reporting the tardiness of all packages in all > distributions? I wouldn't want to do it for 1 distribution, > let alone for 10. > > Re users building their own packages: I suspect this has become > much _less_ common these days than it used to be in the past > as software and distributions become more specialized and mature. > You probably don't, for example, run Debian if you want the latest > and greatest of any and every package, you probably go something > like Fedora. If you are looking for long term support and stability, > you probably don't go Fedora. Users will probably gravitate to the > distribution that meets their needs and use the prebuilt packages > that come with that distribution (IMHO). > > That all being said, you can relatively painlessly check for > self-installed packages simply by first checking that the distribution > package is NOT installed before proceeding with any specific > check for a source built binary. It's going to be a safe bet > that distribution binaries and self-built binaries are mutually > exclusive in terms of their presence on a system. Thus, use the > information already collected by gather-package-list.nasl before > proceeding with a source built binary check. > > Thomas > _______________________________________________ > Openvas-plugins mailing list > [email protected] > http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins > > _______________________________________________ > Openvas-plugins mailing list > [email protected] > http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins > _______________________________________________ Openvas-plugins mailing list [email protected] http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins
