olafz

Member


Messages: 26

#1
Good morning,

when I try to build libressl-2.8.2, I get

Code:
libressl-2.8.2 has known vulnerabilities:
libressl-2.8.2 is vulnerable:
OpenSSL -- Multiple vulnerabilities in 1.1 branch
CVE: CVE-2018-0734
CVE: CVE-2018-0735

1 problem(s) in the installed packages found.
=> Please update your ports tree and try again.
I have no idea why CVEs from OpenSSL show up here. Any ideas?
 
Last edited by a moderator:

usdmatt

Daemon

Thanks: 482
Messages: 1,325

#2
As far as I can see this is correct, as libressl is based on OpenSSL and obviously still has a large amount of shared code.

https://vuxml.freebsd.org/freebsd/238ae7de-dba2-11e8-b713-b499baebfeaf.html

Alleged is 2.8 is affected because it shares the same qualities as OpenSSL 1.1.x.
security/libressl in FreeBSD's ports tree is 2.8.2 and is vulnerable.
I don't know what the official answer is when a current package is vulnerable though...
The port hasn't been updated in 5 weeks so clearly hasn't been fixed yet.
 
OP
OP
olafz

olafz

Member


Messages: 26

#3
Hmm... I just found this strange thing: on another machine, also 11.2-RELEASE-p5 x64,
portupgrade -f security/libressl works fine. So there must be something wrong with the port build system.
 

ShelLuser

Son of Beastie

Thanks: 1,569
Messages: 3,411

#4
Hmm... I just found this strange thing: on another machine, also 11.2-RELEASE-p5 x64,
portupgrade -f security/libressl works fine. So there must be something wrong with the port build system.
A very far fetched and dumb conclusion. Especially if you consider that portupgrade is nothing more but a front end for that very same port build system.

There's a flag which you can use to bypass security warnings, see ports(7), and this is also mentioned whenever the building process stops due to vulnerability warnings.
 

usdmatt

Daemon

Thanks: 482
Messages: 1,325

#5
There's definitely a security issue with the version of libressl currently in ports/pkg. The vuxml page linked above shows that versions <2.8.3 are affected, which is interesting as the main libressl website lists 2.8.2 as the latest. I assume it has been fixed in the src, but that the fix won't appear in a release until 2.8.3 comes out, at which point hopefully the port will be updated. This will likely also be merged to the quarterly (default) pkg branch so everyone sees the update as soon as possible seeing as it has security vulnerabilities.

For the time being there doesn't seem to be an option other than to use the vulnerable version.
 

gessel

Member

Thanks: 15
Messages: 98

#7
Between this and the still open vulns in graphics/openjpeg, I find that -m DISABLE_VULNERABILITIES=yes is an ongoing requirement. There may be more expert advice, but mine is to check any reported vulnerabilities and evaluate whether updating reduces or increases the attack surface. It may be that the new version has fewer vulnerabilities than what is installed; current vulns can be found with pkg audit. If that is true, then it is up to the administrator to decide if the port should be left at current (with some vulns), updated (with different vulns), or disabled until the vulns are fixed. It is likely that the latter is not a realistic option in most installs, though it may be better to temporarily disable some key software function than to get p0wned.

Checking the details of the vuln at the NIST database might help guide risk assessment: https://nvd.nist.gov/vuln/search
 

Vull

Member

Thanks: 18
Messages: 61

#9
Between this and the still open vulns in graphics/openjpeg, I find that -m DISABLE_VULNERABILITIES=yes is an ongoing requirement. There may be more expert advice, but mine is to check any reported vulnerabilities and evaluate whether updating reduces or increases the attack surface. It may be that the new version has fewer vulnerabilities than what is installed; current vulns can be found with pkg audit. If that is true, then it is up to the administrator to decide if the port should be left at current (with some vulns), updated (with different vulns), or disabled until the vulns are fixed. It is likely that the latter is not a realistic option in most installs, though it may be better to temporarily disable some key software function than to get p0wned.

Checking the details of the vuln at the NIST database might help guide risk assessment: https://nvd.nist.gov/vuln/search
Thanks for the links. The graphics/openjpeg port vulnerability also showed up in my first effort to compile the x11/mate-1.20.3 port, and I'm using the DISABLE_VULNERABILITIES flag to compile mate-base-1.20.3 right now. Notable coincidence to see it reported for libressl since I never heard of it before encountering it myself two day ago. But then again I'm pretty new at this compiling from ports business.
Edited to add:
Code:
openjpeg-2.3.0_2 is vulnerable:
OpenJPEG -- multiple vulnerabilities
CVE: CVE-2018-6616
CVE: CVE-2018-5785
CVE: CVE-2018-5727
CVE: CVE-2017-17480
CVE: CVE-2017-17479
WWW: https://vuxml.FreeBSD.org/freebsd/11dc3890-0e64-11e8-99b0-d017c2987f9a.html

1 problem(s) in the installed packages found.
=> Please update your ports tree and try again.
=> Note: Vulnerable ports are marked as such even if there is no update available.
=> If you wish to ignore this vulnerability rebuild with 'make DISABLE_VULNERABILITIES=yes'
*** Error code 1

Stop.
make[6]: stopped in /usr/ports/graphics/openjpeg
*** Error code 1
 

gessel

Member

Thanks: 15
Messages: 98

#10
The graphics/openjpeg issue has a thread at https://forums.freebsd.org/threads/vulnerability-on-these-ports.67787/" href="/index.php?threads/https://forums.freebsd.org/threads/vulnerability-on-these-ports.67787//">Thread https://forums.freebsd.org/threads/vulnerability-on-these-ports.67787/. My take on the situation is that development on openjpeg is a little slower than one would hope given the vulns, but it seems there are a few upstream patches (see https://www.vuxml.org/freebsd/11dc3890-0e64-11e8-99b0-d017c2987f9a.html) which should be integrated in the next update, but according to https://www.freshports.org/graphics/openjpeg/ 2.3.0_2 should fix CVE-2018-5785 which is still being reported in your check so the vuln ecosystem might still be syncing.

Evaluating vulns can be a bit intimidating and is definitely one of the time consuming aspects of managing globe-facing services, but it is essential. In the end, there's always a tradeoff between convenience and security and no easy way around evaluating the balance for your particular needs.
 
Top