# Vulnerability on these ports!



## teo (Oct 2, 2018)

When I try to update these vulnerable ports I end up in error.
# `pkg audit -F`

```
Fetching vuln.xml.bz2: 100%  748 KiB 766.3kB/s    00:01    
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

pango-1.42.0 is vulnerable:
pango -- remote DoS vulnerability
CVE: CVE-2018-15120
WWW: https://vuxml.FreeBSD.org/freebsd/5a757a31-f98e-4bd4-8a85-f1c0f3409769.html

2 problem(s) in the installed packages found.
#
```


# `portmaster -o graphics/openjpeg graphics/openjpeg`


```
===>>> Currently installed version: openjpeg-2.3.0_2
===>>> Port directory: /usr/ports/graphics/openjpeg

===>>> Gathering distinfo list for installed ports

===>>> Launching 'make checksum' for graphics/openjpeg in background
===>>> Gathering dependency list for graphics/openjpeg from ports
===>>> Initial dependency check complete for graphics/openjpeg


===>>> Starting build for graphics/openjpeg <<<===

===>>> All dependencies are up to date

===>  Cleaning for openjpeg-2.3.0_1
===>  openjpeg-2.3.0_1 has known vulnerabilities:
openjpeg-2.3.0_1 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: stopped in /usr/ports/graphics/openjpeg

===>>> make build failed for graphics/openjpeg
===>>> Aborting update


===>>> You can restart from the point of failure with this command line:
       portmaster <flags> graphics/openjpeg 

This command has been saved to /tmp/portmasterfail.txt

#
```


# `portmaster -o x11-toolkits/pango x11-toolkits/pango`

```
===>>> Currently installed version: pango-1.42.0
===>>> Port directory: /usr/ports/x11-toolkits/pango

===>>> Gathering distinfo list for installed ports

===>>> Launching 'make checksum' for x11-toolkits/pango in background
===>>> Gathering dependency list for x11-toolkits/pango from ports
===>>> Initial dependency check complete for x11-toolkits/pango


===>>> Starting build for x11-toolkits/pango <<<===

===>>> All dependencies are up to date

===>  Cleaning for pango-1.42.0
===>  pango-1.42.0 has known vulnerabilities:
pango-1.42.0 is vulnerable:
pango -- remote DoS vulnerability
CVE: CVE-2018-15120
WWW: https://vuxml.FreeBSD.org/freebsd/5a757a31-f98e-4bd4-8a85-f1c0f3409769.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[1]: stopped in /usr/ports/x11-toolkits/pango
*** Error code 1

Stop.
make: stopped in /usr/ports/x11-toolkits/pango

===>>> make build failed for x11-toolkits/pango
===>>> Aborting update


===>>> You can restart from the point of failure with this command line:
       portmaster <flags> x11-toolkits/pango 

This command has been saved to /tmp/portmasterfail.txt

#
```


----------



## Martin Paredes (Oct 3, 2018)

Use the -m option to pass an argument to `make`, check the man page portmaster(8)

`portmaster -m DISABLE_VULNERABILITIES=yes graphics/openjpeg x11-toolkits/pango`


----------



## SirDice (Oct 3, 2018)

Note that by doing so you are installing ports with known security issues on them. Ignoring that is typically a bad idea. So think twice before applying DISABLE_VULNERABILITIES.


----------



## shkhln (Oct 3, 2018)

SirDice said:


> Note that by doing so you are installing ports with known security issues on them.



Not installing, _upgrading_ ports with known security issues. I doubt that was the intention behind that vulnerabilities check feature, preventing upgrades seems too dumb.


----------



## SirDice (Oct 3, 2018)

It doesn't look like it's upgrading, it looks like it's downgrading actually. 


```
===>>> Currently installed version: openjpeg-2.3.0_2
```
That looks good, but a little further down:

```
===>>> Starting build for graphics/openjpeg <<<===

===>>> All dependencies are up to date

===>  Cleaning for openjpeg-2.3.0_1
===>  openjpeg-2.3.0_1 has known vulnerabilities:
....
===>>> make build failed for graphics/openjpeg
```
So it's trying to build and install 2.3.0_1 instead of 2.3.0_2. And by enabling DISABLE_VULNERABILITIES it's actually being forced to install a vulnerable version.


----------



## shkhln (Oct 3, 2018)

Just spotted OP actually tries to downgrade openjpeg-2.3.0_2 to openjpeg-2.3.0_1. Meh, there is absolutely no utility in reading audit log, freaking out and frantically trying to upgrade your programs. For normal desktop/notebook users regularly checking the package repository for upgrades would be enough.


----------



## shkhln (Oct 3, 2018)

SirDice said:


> It doesn't look like it's upgrading, it looks like it's downgrading actually.


Indeed. Still, that vulnerability check would prevent upgrades as well.


----------



## SirDice (Oct 3, 2018)

It shouldn't. It never did on any of my systems. Unless the VuXML info is wrongly interpreted, that's something that happened in the past. The version check was handled incorrectly in certain situations. But that doesn't appear to be the case here.

I can remember only one or two occasions when I really needed DISABLE_VULNERABILITY, but this was because there was no updated version available yet.
I have never needed it to update a vulnerable package to a fixed version.

That's why I said to think twice about enabling it. It's rarely needed. It certainly is never needed to update a vulnerable port/package to a fixed one.

But note that 2.3.0_2 is also vulnerable. At least according to VuXML. It says all versions, up to _and including_, 2.3.0_2 are vulnerable. 
http://www.vuxml.org/freebsd/11dc3890-0e64-11e8-99b0-d017c2987f9a.html


----------



## Martin Paredes (Oct 3, 2018)

If you run `portmaster graphics/openjpeg x11-toolkits/pango`, it is not supposed to install the most current?

Why the downgrade?

Unless the installation is launched by a dependency


----------



## SirDice (Oct 3, 2018)

Martin Paredes said:


> Why the downgrade?


I suspect his INDEX-* file is not in sync with the actual ports tree he has. The INDEX may have 2.3.0_2 but the port itself might still be 2.3.0_1. An out of sync INDEX can cause all sorts of weird build issues.

If you use SVN keep an eye out for merge conflicts or other reasons why (parts of) the ports tree isn't updating correctly. If you use portsnap(8) it might be a good idea to wipe /usr/ports/ and do a fresh extract.

I've encountered things like this myself. Usually because I screwed around with various ports and settings. Wipe, rinse and repeat


----------



## teo (Oct 3, 2018)

SirDice said:


> If you use SVN keep an eye out for merge conflicts or other reasons why (parts of) the ports tree isn't updating correctly. If you use portsnap(8) it might be a good idea to wipe /usr/ports/ and do a fresh extract.




The port tree and source code this  built through SVN, the flavor of the system is RELEASE 11.2, and for binary packages the latest.


----------



## Deleted member 30996 (Oct 4, 2018)

When the vulnerable program is a dependency of another program, I have used `DISABLE_VULNERABILIES=yes` on occasion and then deinstalled the vulnerable program with no il effects to the parent program after the build. graphics/OpenEXR being a vulnerable dependency for graphics/gimp was one. Only because I use GIMP daily and would be be lost without it. It probably won't work in the majority of cases and likely to break something.

I've had a vulnerability on graphics/OpenJPEG for weeks now. I haven't looked into it or tried it with that port. I've been waiting like everybody else. Patiently. I only frequent a handful of sites I trust on a regular basis and calculate the odds of them having set up an exploit as being low. I do what's within my power browser side to foil their evil plot and live with the risks.

I've been waiting for a new version of www/seamonkey and using www/firefox, now it's vulnerable and I'm on www/palemoon till I start to work on it. So it helps to have a program you can use to fall back on.

FreeBSD does and always has "just worked" for me as a desktop OS. This type of thing just happens from time to time and you deal with it.


----------



## teo (Oct 5, 2018)

Trihexagonal said:


> ....and using www/firefox, now it's vulnerable and I'm on www/palemoon till I start to work on it. So it helps to have a program you can use to fall back on.
> 
> FreeBSD does and always has "just worked" for me as a desktop OS. This type of thing just happens from time to time and you deal with it.



But palemoon doesn't have extensions like Ghostery or Privacy Badger to mitigate network insecurity like trackers or unbearable advertising.


----------



## noodlefling (Oct 6, 2018)

SirDice said:


> So it's trying to build and install 2.3.0_1 instead of 2.3.0_2. And by enabling DISABLE_VULNERABILITIES it's actually being forced to install a vulnerable version.



Isn't it likely that 2.3.0_1 also has the vulnerability?  I always assumed the vulnerability problem prevented you from get slightly-better-but-still-bad software, but I suppose like most people, I just wait around until the port gets fixed and then upgrade later and don't think too much about it.


----------



## Deleted member 30996 (Oct 6, 2018)

teo said:


> But palemoon doesn't have extensions like Ghostery or Privacy Badger to mitigate network insecurity like trackers or unbearable advertising.



I've got Change Referer Button, DownloadThemAll!, NoScript, uBlock Origin and Eclipsed Moon installed as extensions in www/palemoon right now. That pretty well takes care of most things.

Eclipsed Moon changes your UserAgent but I need to disable it after doing so, it still shows what you changed it to. Otherwise it was logging me out every time I switched to a different forum page here.

And you cannot get DownloadThemAll! on www/firefox anymore.


----------



## gnath (Oct 17, 2018)

SirDice said:


> But note that 2.3.0_2 is also vulnerable


graphics/openjpeg-2.3.0_2 is still vulnerable. Removing the package delete few packages including graphics/mupdf. Now I removed the same by `pkg remove -f` and not upgrading affected packages with reduced functionality till those vulnerabilities are removed.


----------



## teo (Oct 23, 2018)

Trihexagonal said:


> I've got Change Referer Button, DownloadThemAll!, NoScript, uBlock Origin and Eclipsed Moon installed as extensions in www/palemoon right now. That pretty well takes care of most things.
> 
> 
> 
> ...



Hello Trihexagonal, what is Change Referer Button and DownloadThemAll! used for?


----------



## yuripv (Oct 24, 2018)

Sorry for offtopic, but now that you mentioned palemoon, this is NOT how you promote your project: https://github.com/jasperla/openbsd-wip/issues/86


----------



## Deleted member 30996 (Oct 24, 2018)

teo said:


> Hello Trihexagonal, what is Change Referer Button and DownloadThemAll! used for?



The Change Referer Button (yes, that's the way it's spelled) "add-on allows the user to quickly toggle "network.http.sendRefererHeader" without going to the "about:config" window."
https://addons.mozilla.org/en-US/firefox/addon/change-referer-button/

The page you land on can't tell which page you came from. I can't validate one of my site pages by clicking the Validator button with it enabled because it can't tell which page I  was referred from. A click of the button is all that's needed to enable or disable it.

DownThemAll! (which was called DownloadThemAll!! before the Mandela Effect kicked in) is a mass downloader that speeds up the process of downloading one or more large files... like .iso files.  It's the best.


----------



## teo (Oct 24, 2018)

Trihexagonal said:


> DownThemAll! (which was called DownloadThemAll!! before the Mandela Effect kicked in) is a mass downloader that speeds up the process of downloading one or more large files... like .iso files.  It's the best.



I can't find the DownThemAll extension in any of the browsers like firefox or palemoon.


----------



## Deleted member 30996 (Oct 25, 2018)

It looks like they've cut the page that had incomparable add-ons,  but here is the home page to download and install it. 

https://www.downthemall.org/main/install-it/downthemall-3-0-3/


----------



## ShelLuser (Oct 25, 2018)

yuripv said:


> Sorry for offtopic, but now that you mentioned palemoon, this is NOT how you promote your project: https://github.com/jasperla/openbsd-wip/issues/86


Sorry for a ditto offtopic response but I get the impression that the Palemoon developers don't even understand the ramification of license they used. The Mozilla Public License is pretty clear on applying extra limitations to your work.

Alas, that conversation turned ugly really quick and the result should be obvious. I think most of us would steer clear from Palemoon after reading that ordeal. I know I am.


----------



## teo (Oct 25, 2018)

Trihexagonal said:


> It looks like they've cut the page that had incomparable add-ons,  but here is the home page to download and install it.
> 
> https://www.downthemall.org/main/install-it/downthemall-3-0-3/



It is not installed because it is not compatible for firefox  63 or palemoon 27.9

By the way, has anyone been able to fix that openjpeg security vulnerability?  The system continues to detect this eternal vulnerability.

#`pkg audit -F`

```
vulnxml file up-to-date
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.
#
```


----------



## SirDice (Oct 26, 2018)

teo said:


> By the way, has anyone been able to fix that openjpeg security vulnerability?


It needs to be fixed upstream, OpenJPEG itself doesn't have patches for it yet.


----------



## Deleted member 30996 (Oct 26, 2018)

teo said:


> It is not installed because it is not compatible for firefox  63 or palemoon 27.9



I'm using www/palemoon 27.9.4 and DownThemAll! 2.0.18.1-signed.1-let-fixed.




I had to rebuild www/firefox yesterday for the vulnerability, which hosed my www/palemoon installation, so I just rebuilt it, too.




ShelLuser said:


> Alas, that conversation turned ugly really quick and the result should be obvious. I think most of us would steer clear from Palemoon after reading that ordeal. I know I am.



I use it out of practicality. I only use Mozilla products and it gives me another option if www/firefox or www/seamonkey develop a vulnerability. Monkey has had a vulnerability for some time now.

I got wind of it just before the CoC and that took precedence, but was not the least bit happy about how we were treated as a community and have a card to play in that game up my sleeve.


----------



## teo (Oct 26, 2018)

Trihexagonal said:


> I'm using www/palemoon 27.9.4 and DownThemAll! 2.0.18.1-signed.1-let-fixed.
> 
> View attachment 5456




What I don't understand is how did you install those extensions DownThemAll!, NoScript and uBlock Origin 1.16 in palemoon, when they are incompatible as I visualize it in the images, how did you proceed to install them?

The uBlock Origin Updater installed filters out abundant advertising that is not the what  you install.


----------



## Deleted member 30996 (Oct 27, 2018)

Here is the Github link to uBlock Origin. I update the filters from its menu and have never used the updater myself. Down toward the bottom of the page.


Scroll down the page till you see the version of DownThemAll! I show in my screenshot:

Version 2.0.18.1-signed.1-let-fixed

https://addons.mozilla.org/en-US/firefox/addon/downthemall/versions/

If just downloading smaller single files www/youtube_dl is what I use.


----------



## gessel (Nov 17, 2018)

With respect to the original question, the vulnerabilities in graphics/openjpeg that are blocking updates, Martin Paredes  advice (`-m DISABLE_VULNERABILITIES=yes`) should be considered a work around, but only with appropriate research.  

If you look at the commit history , 2.3.0_2 fixes CVE-2018-5785.  There were 5 vulns at one point, now there are 4.  Upgrading from 2.3.0_1 to 2.3.0_2 reduces the attack surface, a _Good Thing._

Of the 4 still reported, it appears from the  vulnxml report that two have patches and two are not fixed yet.  Hopefully those patches will be integrated soon.

Given that there are unpatched vulnerabilities, the user should first determine if the version they are running is vulnerable (in this case, probably).  If the current version isn't affected by the vulnerability and the new one is, don't update.

If both the current one and the update are vulnerable, the user has to decide whether it is tolerable to  completely remove or disable the port until it is patched (for most of us, probably not; it isn't like everyone stopped using computers when we found out about Meltdown/Spectre and lived an analog life until we could buy secure hardware).

If both current and update are vulnerable and especially if the update is less vulnerable than the current (which is the case from 2.3.0_1 to 2.3.0_2), and if the port is essential, then use the necessary command to override the check and update anyway.


----------



## Deleted member 30996 (Nov 17, 2018)

I hadn't noticed the difference and was still at 2.3.0_1 so I upgraded it. The only 2 remaining vulnerabilities involve .bmp bitmap files and I don't usually deal in that format.

I did run `pkg delete` to see what it would take with it:


```
root@onryo:/ # pkg delete openjpeg
Updating database digests format: 100%
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 12 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
    openjpeg-2.3.0_2
    poppler-0.57.0_1
    ghostscript9-agpl-base-9.24_1
    poppler-glib-0.57.0_1
    poppler-utils-0.57.0_1
    cups-filters-1.16.0_5
    epdfview-0.1.8_15
    gimp-app-2.8.22_1,1
    gutenprint-5.2.14
    py27-gimp-2.8.22_1
    gimp-gutenprint-5.2.14
    gimp-2.8.22,2

Number of packages to be removed: 12

The operation will free 141 MiB.

Proceed with deinstalling packages? [y/N]: n
```

I use graphics/gimp so much I'm really at a disadvantage if something happens where I have to resort to something else so I act accordingly and take into account what I'm doing to minimize possible exploits. Deinstalling the single port would probably still break GIMP.


----------



## noodlefling (Feb 7, 2019)

gessel said:


> If both current and update are vulnerable and especially if the update is less vulnerable than the current (which is the case from 2.3.0_1 to 2.3.0_2), and if the port is essential, then use the necessary command to override the check and update anyway.



This was my thought process as well.

Months later we're on openjpeg-2.3.0_3, but even that version is considered vulnerable. Those bugs must be fearsome.


----------



## gessel (Feb 7, 2019)

According to VuXML, there's only one unpatched vuln remaining: CVE-2018-5727, which is being tracked at https://github.com/uclouvain/openjpeg/issues/1053.


----------



## getopt (Feb 7, 2019)

gessel said:


> According to VuXML, there's only one unpatched vuln remaining: CVE-2018-5727, which is being tracked at https://github.com/uclouvain/openjpeg/issues/1053.


And that is what I get:

```
# pkg audit -F openjpeg
Fetching vuln.xml.bz2: 100%  772 KiB 790.1kB/s    00:01    
openjpeg is vulnerable:
Affected versions:
< 2.1.1
openjpeg -- use-after-free vulnerability
WWW: https://vuxml.FreeBSD.org/freebsd/a233d51f-5d4c-11e5-9ad8-14dae9d210b8.html

openjpeg is vulnerable:
Affected versions:
<= 2.3.0_3
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
```


----------



## SirDice (Feb 7, 2019)

It looks like you have a really old one installed. Even below version 2.1.1. The graphics/openjpeg port was updated to 2.1.1 about 3 years and 4 months ago. Did you perhaps pkg-lock(8) it?


----------



## shkhln (Feb 7, 2019)

getopt said:


> important project like OPENJPEG



It's JPEG 2000, not regular JPEG.


----------



## xtaz (Feb 7, 2019)

VuXML: libsndfile -- multiple vulnerabilities is the other one that has appeared in my vuln list on a permanent basis. I think both this and the openjpeg one are related to having Firefox installed. It's irked me for a while because on my server it very rarely has any vulns reported, and if it does they get fixed within a few days. But I guess a graphical desktop is a different matter.


----------



## SirDice (Feb 7, 2019)

Argh, I got thrown off by the -F option. It shows _everything_, even if it doesn't apply any more.


----------



## gessel (Feb 7, 2019)

shkhln, JPEG2000/jp2 is definitely far less regularly used than JPEG, but it is useful and necessary for some applications. It shouldn't be considered irrelevant that there are vulnerabilities.

getopt, I think there may be some inconsistencies with the vuln database.  The link returned by `pkg audit -F openjpeg` quotes:


> Multiple vulnerabilities have been found in OpenJPEG, the opensource JPEG 2000 codec. Please consult the CVE list for further details.
> CVE-2017-17479 and CVE-2017-17480 were fixed in r477112.
> CVE-2018-5785 was fixed in r480624.
> CVE-2018-6616 was fixed in r489415.
> CVE-2018-5727 is not fixed yet.



CVE-2018-6616 and CVE-2018-5785 are specifically referenced as fixed in the commit history.  PR 234473 has a little more detail, though it seems there's a little confusion over the status of r477112 or at least Andres' question at the top of the PR doesn't seem answered.  

However, whether there are 5 vulns, 4 vulns, or 1, there's still an open vuln.


----------



## shkhln (Feb 7, 2019)

gessel said:


> JPEG2000/jp2 is definitely far less regularly used than JPEG, but it is useful and necessary for some applications.



It is required by PDF standard, but that's about it.


----------



## shkhln (Feb 7, 2019)

getopt said:


> As you found this inconsistencies, could you please file a PR for updating vuxml?



There are no inconsistencies: there were no official releases since 2.3.0 and the database doesn't track individual commits. Is it supposed to work with port revision numbers?


----------



## getopt (Feb 7, 2019)

shkhln said:


> the database doesn't track individual commits.


If that is the case the use of the database is not good. The database _should_ reflect CVEs fixed as this is the purpose of it. The FreeBSD security team should discuss that as false positives are not what we want from our tools.


----------



## SirDice (Feb 7, 2019)

shkhln said:


> Is it supposed to work with port revision numbers?


No, but it should work with a port's patch revisions. 2.3.0 is vulnerable to 5 CVEs, 2.3.0_1 has 3, 2.3.0_2 has 2 and 2.3.0_3 only 1. Now it still shows all 5 for 2.3.0_3.


----------



## shkhln (Feb 7, 2019)

getopt said:


> Well that is bad news as PDF is used all the time intensively. Sad! Probably a useful vector?!?



Somewhat. PDF.js (Firefox built-in viewer) probably doesn't support that codec at all, so that one should be safe.


----------



## shkhln (Feb 7, 2019)

Just check the reverse dependencies for openjpeg:


```
% pkg info -r openjpeg
openjpeg-2.3.0_3:
    leptonica-1.76.0
    py27-pillow-5.2.0
    poppler-0.72.0
    gimp-app-2.10.8_1,1
    ImageMagick6-6.9.10.22,1
    mupdf-1.13.0_4,1
% pkg info -r poppler
poppler-0.72.0:
    poppler-qt4-0.57.0_1
    poppler-qt5-0.72.0
    poppler-glib-0.72.0
    poppler-utils-0.72.0
    libreoffice-6.0.7_4
    inkscape-0.92.3_7
% pkg info -r poppler-qt5
poppler-qt5-0.72.0:
    qpdfview-0.4.17.b1_4
    lumina-pdf-1.4.1_1
% pkg info -r poppler-glib
poppler-glib-0.72.0:
    poppler-utils-0.72.0
    gimp-app-2.10.8_1,1
    xfce4-tumbler-0.2.3_1
    inkscape-0.92.3_7
    epdfview-0.1.8_16
```


----------



## gessel (Feb 7, 2019)

getopt said:


> As you found this inconsistencies, could you please file a PR for updating vuxml?



I wrote Sunpoet, the maintainer, earlier.  If that's insufficient, I'm happy to open a PR.


----------



## shkhln (Feb 7, 2019)

shkhln said:


> Somewhat.



Oops, I completely forgot about distinguishing encoder vs decoder vulnerabilities. https://nvd.nist.gov/vuln/detail/CVE-2018-5785 looks like a vulnerability in OpenJPEG _encoder_ which is totally meh for a regular desktop user.


----------



## fernandel (Feb 7, 2019)

I have three:

```
pkg audit
patch-2.7.6 is vulnerable:
patch -- multiple vulnerabilities
CVE: CVE-2018-1000156
CVE: CVE-2018-6952
CVE: CVE-2018-6951
WWW: https://vuxml.FreeBSD.org/freebsd/791841a3-d484-4878-8909-92ef9ce424f4.html

openjpeg-2.3.0_3 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

libsndfile-1.0.28_1 is vulnerable:
libsndfile -- out-of-bounds reads
CVE: CVE-2017-17457
CVE: CVE-2017-17456
CVE: CVE-2017-14246
CVE: CVE-2017-14245
WWW: https://vuxml.FreeBSD.org/freebsd/30704aba-1da4-11e8-b6aa-4ccc6adda413.html

3 problem(s) in the installed packages found.
```


----------



## SirDice (Feb 8, 2019)

gessel said:


> I wrote Sunpoet, the maintainer, earlier. If that's insufficient, I'm happy to open a PR.


You can send an email to ports-secteam@FreeBSD.org, they're the ones that manage the VuXML. They usually respond fairly quickly.


----------



## gnath (Feb 8, 2019)

getopt said:


> For me it boils down to stop using mupdf for time being


Now I use graphics/xpdf. For me openjpeg is required for pkg. libreoffice only.


----------



## gessel (Feb 9, 2019)

SirDice, thanks for the correct address.  I have sent a note.


----------



## MathematicsStudent (Feb 28, 2019)

Same problem here. I tried to install graphics/darktable but mgmt/portmaster failed to because of an integer overflow vulnerability of graphics/openjpeg, version 2.3.0_3. I would really like to help if someone decided to fork openjpeg.


----------



## gessel (Mar 1, 2019)

graphics/jasper is a (the?) alternate JPEG 2000 CODEC project.    It has good support and no currently reported vulns.  It is used by graphics/GraphicsMagick and might be an altnernatative.  graphics/darktable seems to have optional graphics/ImageMagick and  graphics/openjpeg support, so simply unselecting those options should get you past the vulnerability fail.  If you need JPEG200 support, I seem to remember in the distant past doing something like this site describes to use graphics/GraphicsMagick instead of graphics/ImageMagick, which would then optionally install graphics/jasper for JPEG2000 support rather than  graphics/openjpeg.


----------



## shkhln (Mar 1, 2019)

gessel said:


> graphics/jasper is a (the?) alternate JPEG 2000 CODEC project.    It has good support and no currently reported vulns.



How about https://github.com/mdadams/jasper/issues/147?


----------



## gessel (Apr 3, 2019)

The last remaining vuln was closed a few days ago, see: https://github.com/uclouvain/openjpeg/issues/1053. Hopefully this patch will make it through to ports quickly.


----------



## Vull (Apr 3, 2019)

My delight in learning of these fixes to openjpeg, and 6 other ports I've been using cautiously, seemed complete until yesterday, April 2, when several previously unreported vulnerabilities showed up for Apache web server version 2.4.38, which I've been using since some time shortly after its commit date of January 23. Users should upgrade to version 2.4.39 as soon as possible.  Version 2.4.39 has been available since yesterday in ports, but not yet in packages.


----------

