Re: Ports EOL vuxml entry

[Gerhard Schmidt]

Am 22.08.2016 um 15:54 schrieb Roger Marquis:
>> today there was a new entry added to the vuxml file including all
>> outdated ports. Where is the value in this Entry.
>
> This is good news for many of us Gerhard, who depend on the output of
> 'pkg audit' for vulnerability information.

Is an outdated (EOL) port a vulnerability? I don't think so. It's a
possible vulnerability, but not a real one.

>> In this file should only are real vulnerabilities and not maybe
>> vulnerable not existing ports.
>
> You raise two issues here, A) what constitutes a 'real' vulnerability
> and B) how else would you be warned of probable vulnerabilities (due to
> unmaintained and unaudited code). There is 'pkg version' of course but
> few sites use this flag and fewer still use it for vulnerability
> information.

A real vulnerability is a bug in the software that allows a attacker to
gain access to a system or a higher level of access on a system.

Most code is really unaudited. Many of the recent security problem where
in well maintained code. So saying that unaudited and unmaintained code
is a vulnerability is wrong. It's a security risk.

But the vuxml database is not about security risks. It's about actual
and proven vulnerabilities.

>> Right now this breaks my system to find vulnerable ports on my systems
>> because all systems with legacy code show up with this entry.
>
> Can you post details of how it breaks your system?

I'm monitoring my FreeBSD Servers (about 60 of them) with icinga an have
a test that queries pkg audit if any of the installed packages are
vulnerable. I have some servers that run legacy code that still needs
python24. Every one of this machines reports right now that there is a
vulnerable package installed and there is no way to tell pkg audit to
stop reporting it. Sure i can filter python24 from the pkg audit output
so it doesn't trigger the warning. But if a real vulnerability is
reported for python24 i don't get it. I know that's a theoretical
possibility, but still it reduces my systems reliability.

>> Maybe pkg audit should be print a warning (suppressible by a commandline
>> switch or a whiltelist in the config file) when discontinued ports are
>> installed.
>
> A command line switch to ignore deprecated, discontinued and otherwise
> unadited ports is an excellent idea though I don't think there will be
> much demand for it. A default 'warn if deprecated' will no doubt be the
> modal usage and benefit the larger community (who have until now been
> mislead by the output of 'pkg audit').

As stated in the original mail. Outdated unmaintained ports should not
be part of the vulnerability Database because they are no vulnerability.

They are a different kind of Security risk and pkg audit should report
them by default as that, but not as vulnerability.

There should be a way to state that the sysadmin is aware of the
outdated port and prevent pkg audit from reporting it over and over
again. We could do that easily in the pkg.conf. A line like
ignore_outdated=python24 would be sufficient.

Regards
Estartu


--
----------------------------------------------------------
Gerhard Schmidt | E-Mail: sch...@ze.tum.de
Technische Universität München | Jabber: est...@ze.tum.de
WWW & Online Services |
Tel: +49 89 289-25270 | PGP-PublicKey
Fax: +49 89 289-25257 | on request

--
-------------------------------------------------
Gerhard Schmidt | E-Mail: sch...@ze.tum.de
TU-München | Jabber: est...@ze.tum.de
WWW & Online Services |
Tel: 089/289-25270 |
Fax: 089/289-25257 | PGP-Publickey auf Anfrage

_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[Weldon Godfrey]

Gerhard Schmidt <sch...@ze.tum.de> wrote:

> Is an outdated (EOL) port a vulnerability? I don't think so. It's a
> possible vulnerability, but not a real one.

An EOL product is typically no longer tracked, analyzed, and corrected
for security vulnerabilities. With this higher risk profile, it is
correct to assume it is vulnerable or at least a higher security risk.
Since a clean report from pkg audit with EOL packages on the system will
mislead the vast majority of end-users that they have a lower risk
security profile. It is correct for pkg audit to warn on EOL packages.
Especially since any actual vulnerabilities, that is almost certain to
come up, will likely never show on a future report.

[Kubilay Kocak]

On 23/08/2016 11:08 PM, Weldon Godfrey wrote:
> Gerhard Schmidt <sch...@ze.tum.de> wrote:
>
>> Is an outdated (EOL) port a vulnerability? I don't think so. It's
>> a possible vulnerability, but not a real one.
>
> An EOL product is typically no longer tracked, analyzed, and
> corrected for security vulnerabilities. With this higher risk
> profile, it is correct to assume it is vulnerable or at least a
> higher security risk. Since a clean report from pkg audit with EOL
> packages on the system will mislead the vast majority of end-users
> that they have a lower risk security profile. It is correct for pkg
> audit to warn on EOL packages. Especially since any actual
> vulnerabilities, that is almost certain to come up, will likely never
> show on a future report.

This (good) argument sounds primarily about classification and/or the
ability or lack thereof to distinguish between types-of-things, which
are not identical:

* Explicit vulnerability ("Active", Official record (CVE, etc), will or
likely/expected to be fixed)
* Implicit (probable) vulnerability (by way of EoL, no fixes/support,
may have CVE (forever), port/pkg deleted, etc)

VuXML is about declaring/documenting vulnerabilities yes, but it's also
about arming users with the information they need to make sound security
decisions. Being prescriptive in *either* case is not really telling the
full truth and feels unsatisfying.

If and when we delete ports/packages of still-upstream-supported
software (say they are BROKEN in latest FreeBSD versions) that have an
active CVE's now or ever in the future, are they "vulnerable" according
to what we want if a user has them installed? Should they be listed?

Having said that, VuXML is a 'vulnerability markup language', and
without an actual and explicit 'vulnerability', should it be listed?

On solutions, perhaps this is a simple matter of
--exclude-{deleted,eol,<type>} or similar in pkg audit to tell the
difference, allowing the user to make *note* of differences, and decide
accordingly. I shall avoid the bikeshed on what the default should be.

Or maybe an EoLXML. Read this generically as: a second or multiple data
'sources' for pkg audit, for auditing different things. Just free
thinking here.

/koobs

[Tim Zingelman]

On Tue, 23 Aug 2016, Roger Marquis wrote:

>> There should be a way to state that the sysadmin is aware of the
>> outdated port and prevent pkg audit from reporting it
>

> Agreed though I expect such a report would see little use.

I maintain a local patch to preserve this functionality which was in
portaudit but not in pkg audit. Perhaps not bullet proof, but simple
enough to be sure it does what I want it to do.

Just drop the attached file into /usr/ports/ports-mgmt/pkg/files/ and put
the VuXML ID's you want ignored into /usr/local/etc/portaudit.conf.
(easy enough to edit the patch if you prefer pkg.conf or other)

This allows the administrator to evaluate each vulnerability entry,
decide if it affects a system or not, and document that decision.

There are issues with this solution when VuXML entries are edited after
the fact to add new packages to the list, but it is better than nothing.
(I'd argue that any such edits should require a new VuXML ID to be used.)

Hope this helps,

- Tim

[Garrett Wollman]

<<On Tue, 23 Aug 2016 11:37:18 -0500, Tim Zingelman <zing...@fnal.gov> said:

> I maintain a local patch to preserve this functionality which was in
> portaudit but not in pkg audit. Perhaps not bullet proof, but simple
> enough to be sure it does what I want it to do.

I have an open bug against pkg that it doesn't have this feature.
Would you consider submitting your patch on bugs.freebsd.org/186497 so
it doesn't get lost? bapt@ has already said in response to my bug
that he would be happy to accept a contribution of this nature.

-GAWollman

[Gerhard Schmidt]

Am 24.08.2016 um 11:36 schrieb Xin Li:

>
>
> On 8/23/16 14:23, Gerhard Schmidt wrote:
>> Is an outdated (EOL) port a vulnerability? I don't think so. It's a
>> possible vulnerability, but not a real one.
>

> Do you have an exact VuXML ID? I don't think vuxml actually warns about
> EoL'ed software, and it's likely that you have an actual issue, and
> choose to ignore it (probably for legitimate reason). If it's just
> reporting a software being outdated (rather than really vulnerable to
> something), then we should change the entry, I doubt that this is not
> the case, though.

python24-2.4.6 is vulnerable:
End of Life Ports
WWW:
https://vuxml.FreeBSD.org/freebsd/7fe7df75-6568-11e6-a590-14dae9d210b8.html

I Lists a number of ports that are outdated. Not actual vulnerability
mentioned.

> It seems to be sensible to implement Tim's suggestion, however, that
> allows the system administrator to explicitly override certain VuXML
> IDs, if they really knows what they are doing.

That would be really helpfull.

Regards
Gerhard Schmidt

--
----------------------------------------------------------
Gerhard Schmidt | E-Mail: sch...@ze.tum.de
Technische Universität München | Jabber: est...@ze.tum.de
WWW & Online Services |
Tel: +49 89 289-25270 | PGP-PublicKey
Fax: +49 89 289-25257 | on request

[Dag-Erling Smørgrav]

Kubilay Kocak <ko...@FreeBSD.org> writes:
> This (good) argument sounds primarily about classification and/or the
> ability or lack thereof to distinguish between types-of-things, which
> are not identical:
>
> * Explicit vulnerability ("Active", Official record (CVE, etc), will or
> likely/expected to be fixed)
> * Implicit (probable) vulnerability (by way of EoL, no fixes/support,
> may have CVE (forever), port/pkg deleted, etc)

In theory, these are not identical. In practice, there is no way to
tell the difference given the sources and resources we have.

DES
--
Dag-Erling Smørgrav - d...@des.no