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: schmidt at ze.tum.de Technische Universit?t M?nchen | Jabber: estartu at ze.tum.de WWW & Online Services | Tel: +49 89 289-25270 | PGP-PublicKey Fax: +49 89 289-25257 | on request -- ------------------------------------------------- Gerhard Schmidt | E-Mail: schmidt at ze.tum.de TU-M?nchen | Jabber: estartu at ze.tum.de WWW & Online Services | Tel: 089/289-25270 | Fax: 089/289-25257 | PGP-Publickey auf Anfrage
> Is an outdated (EOL) port a vulnerability? I don't think so. It's a > possible vulnerability, but not a real one.Exactly. The meta-discussion we're having is regarding the word 'audit' (in 'pkg audit'). When you or I audit a server or a site the client always wants to know about potential vulnerabilities as well as known ones. This is because the deliverable is a measure of risk, not just proven risks but also potential risks. Even the commercial scanning tools (Tripwire, Qualis ...) report on potential vulnerabilities as well as those documented in CVEs.> 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.If my reading of <www.cvedetails.com/vulnerability-list/vendor_id-1238/Python-Software-Foundation.html> is correct python24 has documented vulnerabilities. This is expected of deprecated software and the reason many of us want to know which installed packages are deprecated when we run 'pkg audit'.> Sure i can filter python24 from the pkg audit output so it doesn't trigger > the warning.Why not just 'grep vulnerable' if that's your goal, or 'grep -v deprecated' (or use a pkg flag to that effect if and when one becomes available)?> They are a different kind of Security risk and pkg audit should report > them by default as that, but not as vulnerability.But it's not reporting them as vulnerable, it is reporting them as deprecated or unmaintained.> There should be a way to state that the sysadmin is aware of the > outdated port and prevent pkg audit from reporting itAgreed though I expect such a report would see little use. Roger
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. 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. Cheers, -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20160824/cb546097/attachment.sig>