Mailing List Archive

On Mon, Jul 05, 2004 at 03:59:36PM +0200, Jan Fredrik Leversund wrote:
>
> script_xref(name:"OpenPKG-SA", value:"OpenPKG-SA-2004.021");
>
> should probably be...
>
> script_xref(name:"OpenPKG-SA", value:"OpenPKG-SA-2004.021-apache");

Fixed, thanks !

Renaud Deraison wrote:

>On Mon, Jul 05, 2004 at 03:59:36PM +0200, Jan Fredrik Leversund wrote:
>
>
>>script_xref(name:"OpenPKG-SA", value:"OpenPKG-SA-2004.021-apache");
>>
>>
>
>Fixed, thanks !
>
>
>
Maybe it shouldn't have been fixed afterall...

All SUSE references seem to suffer from a similar problem. The
Announcement IDs are formatted like this: SUSE-SA:YYYY:NNN where YYYY is
the yeah and NNN is the announcement number for that year. Trouble comes
when you want to reference it, and all their advisory pages are named
YYYY_NNN_package.html and sometimes the NNN is just NN, depending on
which year YYYY is. On top of that, anything pre-2002 is not to be found
anywhere on their site... It's all very unstructured.

So what it comes down to is this: Should the nessus references try to
compensate for this kind of odd behaviour, or should the references be
as simple as possible? Afterall, it IS possible to find the information
based on the simple form, it just takes a bit of manual searching.

I'm fresh out of silver bullets...

--
Jan Fredrik Leversund <jfl@phalanx.no>
Phalanx Security Services <URL:http://www.phalanx.no/>

On Mon, Jul 05, 2004 at 04:53:15PM +0200, Jan Fredrik Leversund wrote:
> Maybe it shouldn't have been fixed afterall...
>
> All SUSE references seem to suffer from a similar problem. The
> Announcement IDs are formatted like this: SUSE-SA:YYYY:NNN where YYYY is
> the yeah and NNN is the announcement number for that year. Trouble comes
> when you want to reference it, and all their advisory pages are named
> YYYY_NNN_package.html and sometimes the NNN is just NN, depending on
> which year YYYY is. On top of that, anything pre-2002 is not to be found
> anywhere on their site... It's all very unstructured.

Yes, SuSE is nothing but consistent in their security pages - that's
really a pain.

> So what it comes down to is this: Should the nessus references try to
> compensate for this kind of odd behaviour, or should the references be
> as simple as possible? Afterall, it IS possible to find the information
> based on the simple form, it just takes a bit of manual searching.

I don't think it's really our place to do that. As long as OSVDB,
Bugtraq and CVE references are working, I don't care much about the
others.
-- Renaud

On Mon, 5 Jul 2004, Jan Fredrik Leversund wrote:

> script_xref(name:"OpenPKG-SA", value:"OpenPKG-SA-2004.021-apache");
>
> OpenPKG uses a weird format for their security advisory keys; they
> include the name of the package in question.

Do they?

<snip>
Subject: [OpenPKG-SA-2004.026] OpenPKG Security Advisory (apache)
[...]
________________________________________________________________________

OpenPKG Security Advisory The OpenPKG Project
http://www.openpkg.org/security.html http://www.openpkg.org
openpkg-security@openpkg.org openpkg@openpkg.org
OpenPKG-SA-2004.026 27-May-2004
________________________________________________________________________
</snip>

Perhaps they add an extra suffix to a URL when they publish advisories
on their web? Shame on them...if they really do that.

Anyway, the official advisory id appears to be "OpenPKG-SA-200X-YZW"
without the package name. And I think Nessus should use this id and
nothing else.

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

Pavel Kankovsky wrote:

>Perhaps they add an extra suffix to a URL when they publish advisories
>on their web? Shame on them...if they really do that.
>
>
>
That's precisely what they do. The only way to determine the exact URL
for an advisory is to search through an index page, looking for a
reference matching the advisory key. Turns out, they're not the only
ones doing this; SuSE has an even wonkier advisory system on their web site.

And since the validity of such package-specific references are rather
questionable, I'd have to say I agree that Nessus should only store the
key itself.

One can only hope the vendors realize that it's in their own best
interest to provide a uniform way to reference their security advisories. :)

--
Jan Fredrik Leversund <jfl@phalanx.no>
Phalanx Security Services <URL:http://www.phalanx.no/>