TrueOS Vulnerability Management / TrueOS CERT/CSIRT and ΔCERT


#1

The TRON-DELTA.ORG runs the ΔCERT since mid 2017 in an attempt to improve computer security within our organization.

Since we are in the process of TrueOS evaluation we added some VMs to our logging/monitoring systems. One monitoring check executes the well-known pkg audit command to look for known package vulnerabilities.

Although the issue was already discussed in a different thread we would like to bring it to the developers attention once again. As one can see from the comments in line, for the vulnerable packages found, some CVSS scores are equal or above to 7.5 which we consider critical.

[-@-] ~% sudo pkg audit -q
libxml2-2.9.4
curl-7.56.1
irssi-1.0.5,1
clamav-0.99.2_6

[-@-] ~% sudo pkg audit -F
vulnxml file up-to-date
libxml2-2.9.4 is vulnerable:

Port is: https://www.freebsd.org/cgi/ports.cgi?query=libxml2&stype=all&sektion=all
Version: libxml2-2.9.7
libxml2 – Multiple Issues
CVE: CVE-2017-9050
CVE: CVE-2017-9049
CVE: CVE-2017-9048
CVE: CVE-2017-9047
CVE: CVE-2017-8872
WWW: https://vuxml.FreeBSD.org/freebsd/76e59f55-4f7a-4887-bcb0-11604004163a.html
=> https://www.cvedetails.com/cve-details.php?t=1&cve_id=CVE-2017-8872
CVSS Score: 6.4

curl-7.56.1 is vulnerable:

Port is: https://www.freebsd.org/cgi/ports.cgi?query=curl&stype=all&sektion=all
Version: curl-7.58.0_2
cURL – Multiple vulnerabilities
CVE: CVE-2018-1000007
WWW: https://vuxml.FreeBSD.org/freebsd/0cbf0fa6-dcb7-469c-b87a-f94cffd94583.html

curl-7.56.1 is vulnerable:

Port is: https://www.freebsd.org/cgi/ports.cgi?query=curl&stype=all&sektion=all
Version: curl-7.58.0_2
cURL – Multiple vulnerabilities
CVE: CVE-2017-8818
CVE: CVE-2017-8817
CVE: CVE-2017-8816
WWW: https://vuxml.FreeBSD.org/freebsd/301a01b7-d50e-11e7-ac58-b499baebfeaf.html
=> https://www.cvedetails.com/cve-details.php?t=1&cve_id=CVE-2017-8818
CVSS Score: 7.5

irssi-1.0.5,1 is vulnerable:

Port is: https://www.freebsd.org/cgi/ports.cgi?query=irssi&stype=all
Version: irssi-1.1.1,1
irssi – multiple vulnerabilities
CVE: CVE-2018-7050
CVE: CVE-2018-7051
CVE: CVE-2018-7052
CVE: CVE-2018-7053
CVE: CVE-2018-7054
WWW: https://vuxml.FreeBSD.org/freebsd/7afc5e56-156d-11e8-95f2-005056925db4.html
=> https://www.cvedetails.com/cve-details.php?t=1&cve_id=CVE-2018-7053
CVSS Score: 7.5

irssi-1.0.5,1 is vulnerable:

Port is: https://www.freebsd.org/cgi/ports.cgi?query=irssi&stype=all
Version: irssi-1.1.1,1
irssi – multiple vulnerabilities
CVE: CVE-2018-5208
CVE: CVE-2018-5207
CVE: CVE-2018-5206
CVE: CVE-2018-5205
WWW: https://vuxml.FreeBSD.org/freebsd/a3764767-f31e-11e7-95f2-005056925db4.html

clamav-0.99.2_6 is vulnerable:

Port is: https://www.freebsd.org/cgi/ports.cgi?query=clamav&stype=all&sektion=all
Version: clamav-0.99.3
clamav – multiple vulnerabilities
CVE: CVE-2017-12380
CVE: CVE-2017-12379
CVE: CVE-2017-12378
CVE: CVE-2017-12377
CVE: CVE-2017-12376
CVE: CVE-2017-12375
CVE: CVE-2017-12374
WWW: https://vuxml.FreeBSD.org/freebsd/b464f61b-84c7-4e1c-8ad4-6cf9efffd025.html
=> https://www.cvedetails.com/cve-details.php?t=1&cve_id=CVE-2017-12380
CVSS Score: 7.8!

4 problem(s) in the installed packages found.

After these findings through our monitoring system we checked the TrueOS systems for possible updates/upgrades to remediate the problem.

Unfortunately though none of the management utilities indicated available updates.

  • Does that mean (ordinary) users of TrueOS are advised to/expected to install critical updates via the ports system as described in the FreeBSD handbook?

  • What is the official TrueOS policy and what kind of CERT/CSIRT or even SOC/CSOC activities does iXsystems commence on a regular basis?

[-@-] ~% sudo pkg version -vRL=
Updating trueos-base repository catalogue…
trueos-base repository is up to date.
Updating trueos-major repository catalogue…
trueos-major repository is up to date.
All repositories are up to date.

[-@-] ~% sudo pc-updatemanager pkgupdate
Boot-strapping updater…OK
Your packages are already up to date!

[-@-] ~% sudo pkg-static upgrade
Updating trueos-base repository catalogue…
trueos-base repository is up to date.
Updating trueos-major repository catalogue…
trueos-major 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.

We politely ask the TrueOS developers and maintainers to make a statement on best practices and the questions stated above, considering the circumstance that TrueOS is an operating system specifically designed for non-expert audiences/users.

Thank you in advance!


#2

Your WebSite “https://tron-delta.org/” does not provide ownership identity in its certificate.

Is this intentional? A trap by the German secret service, maybe?


#3

bsdtester, we are investing a good amount of our time to audit TrueOS and migrate away from GNU/Linux to FreeBSD-based systems, especially thanks to your out-of-control intelligence services that spy on the whole entire world. The German intelligence is not even a member of the FIVE EYES and largely not responsible for programs like Prism, Tempora, XKS, QUANTUM, NSA TAO, etc.

We are willing to to support the TrueOS community in every non-intrusive way possible. And this thread we created does state two important questions. They are probably of interest to a lot of TrueOS users.

What does that have to do with the German intelligence?

So far we have no commit bit to the TrueOS code repositories and never donated or financially influenced any of the TrueOS founders or staff.

If we were the German intelligence (BND, BfV or MAD) we would not tell you and silently cmpromize the TrueOS project! Certainly we would not participate here on Discourse.

Other than that you can find more about the founder of TRON-DELTA.ORG on Wikipedia https://en.wikipedia.org/wiki/User:Mathias_Hollstein and XING or LinkedIn. The profiles are linked on the Wikipedia profile. The member directory is available on https://tron-delta.org/content/structure/structure-en.html

Since you, bsdtester, may be from the U.S. Intelligence we will not reveal the identities to you however. :smiley:

What is ownership identity? We use the 1&1 (1und1 Internet AG Germany/United Kingdom) protection services, so our full address is not visible and auto-processable by bad spiders/crawlers from the whois record data. Since we are a registered NGO we are allowed to use that service according to domestic law.

However, please see our thorough and complete, law-conforming imprint at https://legal.tron-delta.org (please read the whole page carefully) as well as our FAQ https://tron-delta.org/content/questions/questions-en.html which also refers to our relationship with the intelligence community (please read the last question carefully).

If you have reason the believe (contrary to every statement we made) we are the intelligence then please explain how you come to that conclusion and what kind of negative things we have done so far.


#4

“Firefox/PageInfo/Security”

Is this a joke? You don’t know what “site ownership identity” information in Public Key Certificates is or means?


#5

Ok, that is enough guys. Lets get back to to the topic at hand.
@TRON-DELTA : Let me get back to you in a couple minutes - this reply will get a little bit lengthy… :wink:


#6

Agreed. I’ll stop it.


#7

First, we need to define a couple phrases to avoid confusion:

  1. "base system"
    This is used to refer to the FreeBSD install itself (on TrueOS this refers to packages which come from the trueos-base repository, all prefixed with “FreeBSD-*”).
  2. "3rd-party packages"
    This is used to refer to any applications/utilities from the FreeBSD ports tree (on TrueOS, this refers to packages which come from the trueos-major repository).

Now regarding the issue of security vulnarabilities (vuxml / pkg audit) and updates:

  • FreeBSD has always maintained that base-system security issues are the only things that will get patched/pushed as soon as possible. They make no guarantees about the viability/usability of any 3rd-party packages.
  • In practicality, the maintainers for ports do a very good job at trying to update their ports as soon as a security vulnerability is raised for that application. This means that the ports tree sources tend to be updated very quickly, not necessarily that users will get those fixes/updates.

This leads into the next distinction: ports (sources) vs. packages

  1. Packages are just pre-compiled versions of ports.
  2. Packages are generally created/pushed on a time-delay or schedule.
    • FreeBSD publishes “quarterly” (3-month) package repositories, and there are a couple other experimental repos with more frequent builds/updates.
    • TrueOS publishes 2 different tracks of packages (each track has a “base” repository and a “major” repository for base/3rd-party packages).
      • The STABLE track is a 6-month release schedule, meaning that you will only get updates everything 6 months (usually - there are a few special exceptions).
      • The UNSTABLE track is a rolling-release schedule which usually publishes new packages every 2 weeks (varies a bit depending on the state of the ports sources, but we try to ensure at least one update every month).

This results in a couple options for people who want to maintain a strict hold on security issues or update schedules:

  1. Continue using the STABLE track, but limit/uninstall vulnerable packages. This might not be possible if something like “curl” (which is used by so many things) is what is known to be vulnerable.
  2. Move to the UNSTABLE track for TrueOS (easiest solution). This will ensure that you get security updates across the board on a more regular/frequent basis, but vulnerabilities may exist on your system for up to a month between updates (depending on current state of ports).
  3. Manually manage your own CUSTOM package repository via poudriere/ports. This is generally a fairly difficult task for individuals, but for a large company that wants all of it’s users to utilize a single “verified” collection of packages this may be done.
  4. (Warning) Some people might recommend mixing a package-based system such as STABLE/UNSTABLE with manually building/installing individual packages from an up-to-date ports tree (sources). This is generally discouraged because of rampant instability in port dependencies when compiling ports this way. If this is what you are considering, I highly recommend option 3 instead as it is the safe alternative so the entire system is still setup by packages which are compatible with each other.

For example:
The vulnerability information that @TRON-DELTA posted comes from the 17.12 release of the STABLE track for TrueOS (at the present time - secutiry issues are always a moving target). All of those issues have already been resolved on the UNSTABLE track (the only issue I see on my UNSTABLE system at the moment is a vulnerability in LibreOffice). So a simple fix would be to move over to the UNSTABLE update track.

ADDENDUM:
TrueOS already integrates the output of the pkg audit command directly into the AppCafe. If you go to the “Installed” tab and look at the list of packages you currently have installed there are a number of possible icons/flags which indicate the state of that packages. Two of those states are “Security Vulnerability” (if the package has a known security vulnerability) and “Dependency Vulnerability” (a dependency of the package has a known security vulnerability).


TrueOS Update Problem 17.12 to 18.02
#8

Thank you for the answer! We will definitely discuss that and probably go the UNSTABLE track-way of things, since that looks like a reasonable effort. In the future we may choose option 3, a CUSTOM package repository ,which we did in the past with our Debian/Ubuntu-based in-house GNU/Linux distribution.


#9

We have one final question though.

Assuming e.g. Apache 2, Mozilla Firefox or Java SE (JRE) had a severe vulnerablility, would you then provide updates prior to the next 4-weekly update time-frame?


#10

If we have the capability, yes.
Basically that 4-week window is just a maximum time frame for us to get another UNSTABLE build complete and pushed. Normally we try to get that window down to as short a time frame as possible (hopefully every week).


#11

Sorry, another question:

The STABLE and UNSTABLE images seem to differ by 18 days only (12th December 2017 vs. 30th December 2017). There seems to be no February 12th, 2018 version available.

What is your idea on release cycles of images of the UNSTABLE version of TrueOS? Will you update the iso images on a monthly basis in the future?

https://download.trueos.org/unstable/amd64/


#12

I’m not speaking for @beanpole135 or any of the other devs, but STABLE is basically a 6 month release. UNSTABLE is “as needed, weekly if possible, try to keep it under 4 weeks”. The STABLE of 12Dec2017 is basically the UNSTABLE of around that time; UNSTABLE kept moving and the devs may have felt there was no reason to release an UNSTABLE around 12Feb2018.

I’m not sure what the plans are for keeping older img/iso in the download directory.


#13

Yes, stable is released every six months, but unstable is released about every four weeks, as Ken Moore pointed out in a former comment.

The question is whether the monthly (or bi-weekly) updates will also be made available as dedicated ISO files on the official website. There is a February unstable release dated 12. Feb. 2018 which is however not downloadable as an ISO from the website.

Again: What is the agenda on release cycles of ISO images of the UNSTABLE version of TrueOS? Will the developers update the images on a monthly (or bi-weekly) basis in the future on the website (download section)? Is there an ISO auto build system in place at iXsystems?


#14

Unstable has updates every few weeks, but a new installer image is not always rebuilt for it. In general, it’s not a large issue because you can always take a stable image and change it to update to unstable.

There’s been a few times I would have found a new unstable installer image helpful, but in general it’s possible to get where you want from the stable installer.


#15

Yes, but nonetheless we think the ISO images should reflect the changes. Otherwise what’s the point in having them online at all, besides the flag set to UNSTABLE in the TrueOS manager?


#16

I’m having trouble understanding the point you are trying to make. Is it:

TrueOS should keep installer images for all the UNSTABLE and STABLE releases available on the download page.

If that is your point, then you’ll have to wait for one of the devs to answer; anything I say is simply speculation as to the whys and whats on the download page. As an example, I look at the download page the way I do boot environments: I like to have the one I’m currently in once I consider it good, plus one or two previous known good. That correlates to the installer images of “latest” plus one or two previous known good. Keeping all of them plus the packages for that is an awful lot of disk space for what some may consider little benefit. But that is my opinion, not the official opinion of any project.


#17

Preferably, since having dated UNSTABLE and STABLE iso images about the same makes not much sense to us.


#18

Ok, now I understand what you’re asking for/about. thanks


#19

Beanpole135, have you considered updating the UNSTABLE images in https://download.trueos.org/unstable/amd64/ at least every three months (preferably every month), or what are the future plans? Thanks in advance! :slight_smile:


#20

Yes, we typically push the updated ISO/IMG files at the same time as the package repo, but we held off on that for the last couple months because we were doing a lot of surgical work on cleaning up the installation/upgrade procedures (which files are installed as an overlay, and which ones are installed via a package). We think we have that all worked out and verified now, and we are planning on regularly pushing out the new ISO’s again with the UNSTABLE update next week.