FreeBSD quarterly package repository

H

holala

Good day!

I'm using url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly" for my pkg. However I noticed some mismatch between the packages available for upgrade and the vulnerable packages:

Code: 
# pkg audit
python37-3.7.7 is vulnerable:
Python -- Regular Expression DoS attack against client
CVE: CVE-2020-8492
WWW: https://vuxml.FreeBSD.org/freebsd/a27b0bb6-84fc-11ea-b5b4-641c67a117d8.html

python37-3.7.7 is vulnerable:
Python -- CRLF injection via the host part of the url passed to urlopen()
CVE: CVE-2019-18348
WWW: https://vuxml.FreeBSD.org/freebsd/ca595a25-91d8-11ea-b470-080027846a02.html

python36-3.6.9_3 is vulnerable:
Python -- Regular Expression DoS attack against client
CVE: CVE-2020-8492
WWW: https://vuxml.FreeBSD.org/freebsd/a27b0bb6-84fc-11ea-b5b4-641c67a117d8.html

python36-3.6.9_3 is vulnerable:
Python -- CRLF injection via the host part of the url passed to urlopen()
CVE: CVE-2019-18348
WWW: https://vuxml.FreeBSD.org/freebsd/ca595a25-91d8-11ea-b470-080027846a02.html

libnghttp2-1.40.0 is vulnerable:
nghttp2 -- DoS vulnerability
CVE: CVE-2020-11080
WWW: https://vuxml.FreeBSD.org/freebsd/4bb56d2f-a5b0-11ea-a860-08002728f74c.html

py36-urllib3-1.22,1 is vulnerable:
urllib3 -- multiple vulnerabilities
CVE: CVE-2019-11324
CVE: CVE-2019-11236
CVE: CVE-2018-20060
WWW: https://vuxml.FreeBSD.org/freebsd/87270ba5-03d3-11ea-b81f-3085a9a95629.html

gnutls-3.6.13 is vulnerable:
GnuTLS -- flaw in TLS session ticket key construction
CVE: CVE-2020-13777
WWW: https://vuxml.FreeBSD.org/freebsd/ef5b4f5f-a658-11ea-80d7-001cc0382b2f.html

7 problem(s) in 5 installed package(s) found.
#
# pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (0 candidates): 100%
Processing candidates (0 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
#

My question is, does the quarterly repo include also fixes to the vulnerable packages? Or should I wait until the next quarterly build to receive the fixed package?

And one offtopic question, several sources show usage of pgkg with the -f and -F flag (pkg update -f and pkg upgrade -F), however I do not see any reference to -f -F in the man page. Would you please hint me on these options?

Thank you!
 
Thank you. Do you have a idea why the reported vulnerable packages were not shown as available upgrades? I guess that the maintainers didn't have time to update them...
 
The quarterly branch takes a little more time to update than the latest. Usually about a week’s wait for the security patches.
 
  1. Force a full download of the repos and then upgrade:
    pkg update -f
    pkg upgrade
  2. Remove orphan packages,
    Some of them may have vulnerabilities, but you don't need them, remove them and get rid of additional warning:
    pkg autoremove
  3. Then, try audit with -F flag (fetch db before checking)
    pkg audit -F
Maybe the updates are available on the latest branch and you are on the quarterly branch. Look at this guide, Switching from quarterly to latest ... to switch to the latest branch.
Sometimes you have to wait, maybe just a few days or longer. If it's critical, and there's a new version available with fixes in the port tree, and you don't care about consequence of the mixing ports and packages (maybe or mabe not), go for a build from the ports tree and get the latest security fixes. Go by default options, and you should keep track of what you are doing. It's on you!
 
swegen said:
The quarterly branch takes a little more time to update than the latest. Usually about a week’s wait for the security patches.
Click to expand...

You're saying binary pkgs of quarterly ports can be vulnerable for a week after the security breach disclosure?
Quarterly is used in -RELEASE snapshot by default. Isn't this a security problem?
vigole said:
  1. Force a full download of the repos and then upgrade:
    pkg update -f
    pkg upgrade
  2. Remove orphan packages,
    Some of them may have vulnerabilities, but you don't need them, remove them and get rid of additional warning:
    pkg autoremove
  3. Then, try audit with -F flag (fetch db before checking)
    pkg audit -F
Maybe the updates are available on the latest branch and you are on the quarterly branch. Look at this guide, Switching from quarterly to latest ... to switch to the latest branch.
Sometimes you have to wait, maybe just a few days or longer. If it's critical, and there's a new version available with fixes in the port tree, and you don't care about consequence of the mixing ports and packages (maybe or mabe not), go for a build from the ports tree and get the latest security fixes. Go by default options, and you should keep track of what you are doing. It's on you!
Click to expand...

The thing about waiting a week applies only to binary (pkg) distribution of quarterly branch or to the
XXXXQY branch of github/svn repo too? E.g. is it more secure to pull the fixes and rebuild than using pkg?
 
I don't think there is any right answer that applies to all situations and issues and applications.

Recently MySQL had some security vulnerabilities that it took some time (a month?) before the new versions appeared for FreeBSD (ports or packages). It got to the stage I started trying to work out what was different between the revisions to see if I could move to the new, "more-secure" version myself. After I'd wasted a few hours on that I had a lot more respect for FreeBSD porters! As well as the security fixes there seemed to be hundreds of utterly unrelated changes - made by the MySQL developers - including to the build process.

Soon after that - there was ANOTHER set of MySQL security vulnerabilities but the updated version appeared within a week in ports, and packages soon after (including quarterly).

Neither instance mattered too much in my use case because there were other layers of defence (firewall, user set-up in MySQL, etc.)

Sometimes the rush patch is worse and leads to downtime or yet more patching - you'd have been better waiting some time for the dust to settle (and for other people to have the pain of finding the first version of the patches weren't right.) So getting a fix ASAP and in less than a week - doesn't really help.

So quarterly isn't perfect. Neither is latest. And nor is ports. There is no silver bullet.

I don't mean to wave away your concerns or say you are wrong - in an ideal world everything would get fixed and tested and released a lot quicker (or in the ideal world there wouldn't be bugs in the first place.)
 
richardtoohey2 said:
I don't think there is any right answer that applies to all situations and issues and applications.

Recently MySQL had some security vulnerabilities that it took some time (a month?) before the new versions appeared for FreeBSD (ports or packages). It got to the stage I started trying to work out what was different between the revisions to see if I could move to the new, "more-secure" version myself. After I'd wasted a few hours on that I had a lot more respect for FreeBSD porters! As well as the security fixes there seemed to be hundreds of utterly unrelated changes - made by the MySQL developers - including to the build process.

Soon after that - there was ANOTHER set of MySQL security vulnerabilities but the updated version appeared within a week in ports, and packages soon after (including quarterly).

Neither instance mattered too much in my use case because there were other layers of defence (firewall, user set-up in MySQL, etc.)

Sometimes the rush patch is worse and leads to downtime or yet more patching - you'd have been better waiting some time for the dust to settle (and for other people to have the pain of finding the first version of the patches weren't right.) So getting a fix ASAP and in less than a week - doesn't really help.

So quarterly isn't perfect. Neither is latest. And nor is ports. There is no silver bullet.

I don't mean to wave away your concerns or say you are wrong - in an ideal world everything would get fixed and tested and released a lot quicker (or in the ideal world there wouldn't be bugs in the first place.)
Click to expand...

Thank you for the detailed answer.
The only thing that bothered me is just that if there will be some critical security vulnerability disclosed to CVE (for example, remote execution in TCP/IP stack code), that can be exploited really quick, will it be fixed as soon as possible? A week or a day looks inacceptable in this case. Am I supposed to rely on FreeBSD security team in case of critical disclosure? Or do I have to maintain my own security tracking policy, including making workarounds, disabling vulnerable services, etc? (Or hire a security specialist, of course)

vigole

Thank you for the detailed answer.
Is it a good idea to use latest ports/pkgs on working laptop? I use latest for some jails/vms, but what about the host system?
 
putin.is.a.thief said:
The only thing that bothered me is just that if there will be some critical security vulnerability disclosed to CVE (for example, remote execution in TCP/IP stack code), that can be exploited really quick, will it be fixed as soon as possible?
Click to expand...
The TCP/IP stack is part of the base OS. Different strategy.
putin.is.a.thief said:
Am I supposed to rely on FreeBSD security team in case of critical disclosure?
Click to expand...
The security team is responsible for fixing issues in the base OS. It is not responsible for fixing issues with third party software, aka ports. It only reports those. It's up to the respective port maintainer(s) to actually fix the port. Does that mean a port can be vulnerable a long time? Yes, especially with unmaintained ports. Most port maintainers however take their responsibility serious and provide updates or patches in a reasonably timely manner.

www.freebsd.org

FreeBSD Security Information

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
www.freebsd.org www.freebsd.org
 
I don't think there's ANY operating system that offers instant fixes for security issues. And it would be a huge job to try and track, fix, test, and deploy fixes for the full "stack" so I can't see any individual being able to do that (or hire a security specialist to do so).

You asked "will it be fixed as soon as possible?" - and I think yes, things are generally fixed as "soon as possible" with the resources FreeBSD have got (or OpenBSD, or Ubuntu, or Red Hat.) Sometimes it would be nicer if it happened sooner.

This is one of the reasons defence-in-depth is good - you need layers of defence - firewall, patching, restricted access, logging, code reviews, intrusion detection, penetration testing, disabling unrequired services, hardening, careful configuration, tracking security bulletins etc., etc., etc.

If you hear of a security issue there are usually workarounds (configuration, firewall, whatever) - but again, that's true of Windows, Mac, Linux, etc.

There is no silver bullet or perfect operating system.
 
  • Like
Reactions: a6h
You must log in or register to reply here.
Back
Top