A word on handling Common Vulnerabilities and Exposures on the FreeBSD Ports Collection

Issues affecting the FreeBSD Ports Collection are covered separately in the FreeBSD VuXML document. This is the advice you get here. Now click on the link and follow all of the very few links there to just get an idea on what VuXML is about.

pkg audit makes use of it.
Code:
# pkg audit
tiff-4.0.7_1 is vulnerable:
tiff -- multiple vulnerabilities
CVE: CVE-2017-7602
CVE: CVE-2017-7601
CVE: CVE-2017-7600
CVE: CVE-2017-7599
CVE: CVE-2017-7598
CVE: CVE-2017-7597
CVE: CVE-2017-7596
CVE: CVE-2017-7595
CVE: CVE-2017-7594
CVE: CVE-2017-7593
CVE: CVE-2017-7592
CVE: CVE-2017-5225
WWW: https://vuxml.FreeBSD.org/freebsd/2a96e498-3234-4950-a9ad-419bc84a839d.html

This output above I get since 2017-04-20 when the entry was created in the database 30 days ago.

Looking at https://vuxml.freebsd.org/freebsd/index.html we can dig into
https://vuxml.freebsd.org/freebsd/2a96e498-3234-4950-a9ad-419bc84a839d.html
where you can look up a list of NVD reports. Each report has a link source at the lower right corner of the box which you might not notice. But click on it!
It takes you there https://nvd.nist.gov/vuln/detail/CVE-2017-5225

Before you get attracted by the impact of that vulnerability notice the "Quick Info":
Quick Info

CVE Dictionary Entry:
CVE-2017-5225
Original release date:
01/12/2017
Last revised:
01/27/2017
Source:
US-CERT/NIST

Notice there is a time hole of 92 days between the NIST entry and the vuxml.freebsd entry.

Now add the 30 days a/o today to the 92 days and try to express it in months.

And please note, this is only the first CVE of 12 CVEs.

Interesting is the PR from Sevan Janiyan entered 2017-01-31 03:33:41 UTC which got a reply Jan Beich (away from May 25 to June 11) freebsd_committer 2017-04-21 08:06:40 UTC.

Now anticipating that few/some/most want to say "But it's all for free. We are volunteers". But could it be worse?

Now what would be the pragmatic policy for a port where there is no fix found in the ports? Suppose there is no alternative that means deleting the port and all those depending on it. Anyone votes against? Too much ports depending on it?
 
Why are they prevented from patching the port until "upstream" shows signs of life?
I found similar patches in the bug reports upstream, apparently some (or all) of the proposed patches are causing regression errors. So we can either blindly apply those patches to "fix" the CVE issue and cause other problems, or wait until it gets properly fixed.
 
Failing to patch security vulnerabilities as a matter of priority cannot be called proper. Exposing users to known vulnerabilities is by no means acceptable.
I fully agree but on the other hand, fixing security issues and introducing new errors because of the "fix" can't be called proper either. While I agree it should get priority I'm also of the opinion things need to be fixed correctly. And this, unfortunately, takes time.
 
I won't use the word properly here any more. Failing to patch security vulnerabilities as a matter of priority cannot be called proper. Exposing users to known vulnerabilities is by no means acceptable.
But who is to blame for that? Definitely not FreeBSD in my opinion but the author(s) of the involved projects. After all, the Ports collection is basically a blueprint; a means to obtain software from their original locations. Although the auditing system provided by pkg is a nifty feature it's also not something to blindly rely on.

While I do appreciate the CVE feature I personally don't rely on it either. I'm simply following other lists to base my decisions on.

A solution regarding the tiff-library is just deinstallation and trying to build without tiff where possible.
I have to agree that it would be a good alternative to try and get rid of the port. But in my opinion that decision should be left with the users, not someone upstream. Especially not if the removal of such a port would immediately result in even bigger problems (dependencies not working).

I mean... A turned off server which is locked away can be considered to be pretty secure, but it's also pretty useless as well. Not trying to be sarcastic here, but that is something to keep in mind nonetheless.

Things like these don't have simple solutions in my opinion. Well, other than the original project members fixing their stuff as soon as possible of course.
 
How are CVEs collected from other databases?
What is the procedure to be followed entering a new entry into vuxml?
What measures are taken that new events are published in vuxml without delay?
Does a binding policy exist for this process?
Thank you for answering my questions. :(
I'm overwhelmed by the community's interest in their own FreeBSD vulnerabilities and exposures framework.

From MITRE https://cve.mitre.org/compatible/alerts_announcements.html
Organizations with CVE Identifiers in Advisories

The 98 organizations below are including, or have included, CVE Identifiers in their security advisories, ensuring that the community benefits by having CVE Identifiers as soon as the problem is announced.

...
FreeBSD
...
As FreeBSD is listed there, there must be an existing commitment to meet some rules, isn't it?

Now again I like to ask, how and when are CVE entries added to the FreeBSD vuln.xml?
Who is doing it?
 
can you imagine the state of the ports tree if tiff was marked FORBIDDEN all these months?
I'm guessing the very best ports would all be skipped. chromium, libreoffice, all desktops.

You can sit on a high horse, but had you been the one to break the ports tree, everyone would have been coming at you relentlessly until you just realized that the volunteer job wasn't worth all this [hassle].

Easier said than done.

[added: and it's not the maintainer or security's responsibility to actually create security patches. It's upstream as said before. At best they can take suggested random patches from the internet without really being sure it's the proper fix.]
 
Personally, I actually prefer it this way. The other end would have "fixes" for these CVEs but may introduce other issues like crashes (or worse; new vulnerabilities) and you would be none the wiser. At least now you know exactly which vulnerabilities are there and you know exactly why and what's vulnerable. This allows you to take alternative measures to mitigate the risks. In my opinion it's better to have a few known vulnerabilities than a bunch of unknown ones.
 
Ignoring the rules because a port is too popular is no valid solution to me.
You assume they're ignoring it. But it's just as likely they are fully aware of it but are having difficulties implementing a correct fix. Rules are fine but there may be perfectly valid reasons not to follow them. Just because you don't know the reasoning doesn't mean there isn't any.

But, lets turn this around and take the TIFF example again. How would you like to have seen this handled?
 
Sorry for not having been precise enough. With the Tiff causa there are two really big failures:

1. The obligation to inform the user community
2. Fixing the vulnerabilities.

On both there are rules to be applied.

ad 1. Upstream issued a warning, a CVE was given. (In fact there was a bundle of them.)
Now FreeBSD had the liability to add the CVEs to VuXML as soon as possible. This did not happen. It happened even then not after someone pointed with a PR to the CVEs. It is not left to the discretion of the port maintainer or the Security Officer to add an entry to VuXML. See the quotes and links above, there are existing rules.

ad 2. The FreeBSD Porters Handbook has rules on fixing vulnerabilities. Obviously in this case the rules were not applied. But if rules for fixing security issues are not followed, this compromises the security concept as a whole.

Maybe the VuXML users were intentionally not informed, because it was known to "some" that the problem is really really big. This would be a clear breach with the MITRA commitment as they issued CVEs already. Such thoughts should not be given any room.

I advocate for not blaming others here but to take steps for improvement. There is quite some room for getting better, as the next events are right around the corner. Excuses do not bring us any step forward.
 
Maybe the VuXML users were intentionally not informed, because it was known to "some" that the problem is really really big. This would be a clear breach with the MITRA commitment as they issued CVEs already.
FreeBSD is not the OWNER of those CVEs, it is a USER of those CVEs. It would have been different if the CVE was due to an issue with FreeBSD itself. But that's not the case here.
 
FreeBSD is not the OWNER of those CVEs, it is a USER of those CVEs. It would have been different if the CVE was due to an issue with FreeBSD itself. But that's not the case here.
I'm wondering how reading my text could trigger such a thought. But understanding is said to be done on the recipients side.

Of course your statement is right. But I have nothing said in contradiction to it.

Again: if a CVE was issued (not by FreeBSD) FreeBSD has the obligation to add this into VuXML as soon as possible. This did not happen within an acceptable time frame in the Tiff case, raising the question if this is just a single failure or if this happens more than 10% of the CVEs.
 
if a CVE was issued (not by FreeBSD) FreeBSD has the obligation to add this into VuXML as soon as possible.
Maybe I misread it but where is this obligation defined? As far as I understood it this would only be the case for CVEs if FreeBSD is the owner, i.e. for vulnerabilities in the base or kernel. It does not have this obligation regarding CVEs owned by a third party.
 
From my point of view it is defined by the MITRE Requirements and Recommendations for CVE Compatibility where FreeBSD is a member.

Once the MITRE database is used which FreeBSD does with VuXML, there is the responsibility to "ensuring that the community benefits by having CVE Identifiers as soon as the problem is announced." (See quote and link above) In the VuXML are, as we know not only the base and kernel CVEs but also those of the ports collection. All data have to be up to date if used.
 
Yes, regarding CVEs for which FreeBSD is directly responsible, i.e. vulnerabilities in the base or kernel. That's what the "requirements and recommendations" talks about. And those are required to be CVE-compatible. The "capability" is the FreeBSD OS or kernel, the "owner" is the FreeBSD foundation.
 
well, I did notice that you conveniently ignored my suggestion to join to security team where you can make a direct difference.
If you're not willing to do this security work yourself, IMO you don't have a whole lot of room for demanding others to get better. Nobody is getting paid.

Is there room for improvement? Sure.
Can improvement be demanded? Shamed into doing it? No, probably not. The answer is always the same when it comes to FOSS.
 
everything is a volunteer effort. Somebody might ask for a specific subgroup like security team but volunteering for any activity is fine too. Maybe the "application" is turned down due to current lack of experience, but at that point somebody will say what needs to happen in order to get there. But if you contacted secteam on your own and said "I'm interested in helping", surely you'd get a positive response.

the quoted bit above was a cheeky way of saying that complaining on a forum where the principals are not even present isn't a good approach. You can talk until you're blue in the face and nothing is going to change. The people that need to hear it probably won't. At best you're preaching to a choir that can't effect change. If you want to blow off steam, fine, but if you want change you have to take some initiative.
 
AFAIK a security team asks someone for joining, not the other way round.

Why would you think that? That makes no sense (not trying to be rude). If you want to join the security team, apply to join the security team. If they reject you, ask how you can still contribute and then make contributions and actively seek out ways to make the lives of the security team easier (since that'll enable to make the most out of their limited time and resources). Eventually you will be on the security team if you are motivated enough and willing to accept feedback on your work (at the very minimum you'll have contributed to FreeBSD security (which is whole point anyways) and become a better developer/security-expert/sysadmin).

Also in this case, making a meaningful contribution could mean fixing the vulnerability upstream (which I don't think you could reasonably do tbh since even their own "fixes" caused their users issues/regressions) or coming up with a mitigation like a program (make sure to write it with no security issues) to detect bad input (like malformed images that hacker could use to exploit the vulnerability) that application writers could take advantage of in the meanwhile (and note that this is probably a futile effort) to lint input images prior to supplying to them to a program that utilizes libtiff.

A more proactive (and perhaps more reasonable) approach you could possibly take is to engage in the use of fuzz testing (which might have allowed the developers of that library to detect the issue in the CVE before hand) and try to get it adopted by developers of the libraries/applications/operating-systems whose security that you care about.
 
Back
Top