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
