Nixpkgs: Vulnerability Roundup 16

Created on 4 Jan 2017  Â·  41Comments  Â·  Source: NixOS/nixpkgs

Here are all the vulnerabilities from https://lwn.net/Vulnerabilities
since our last roundup.

cc: @7c6f434c @LnL7 @nlewo @vcunat.

_Note:_ The list of people CC'd on this issue participated in the last
roundup. If you participate on this roundup, I'll cc you on the next
one. If you don't participate in the next one, you won't be CC'd on
the one after that. If you would like to be CC'd on the next roundup,
add a comment to the most recent vulnerability roundup.

Permanent CC's: @joepie91, @phanimahesh, @the-kenny,
@NixOS/security-notifications
If you would like to be CC'd on _all_ roundups (or removed from the
list), open a PR editing
https://github.com/NixOS/security/blob/master/lwnvulns/src/bin/instructions.md.

Notes on the list

  1. The reports have been roughly grouped by the package name. This
    isn't perfect, but is intended to help identify if a whole group
    of reports is resolved already.
  2. Some issues will be duplicated, because it affects multiple
    packages. For example, there are sometimes problems that impact
    thunderbird, and firefox. LWN might report in one vulnerability
    "thunderbird firefox". These names have been split to make sure
    both packages get addressed.
  3. By each issue is a link to code search for the package name, and
    a Github search by filename. These are to help, but may not return
    results when we do in fact package the software. If a search
    doesn't turn up, please try altering the search criteria or
    looking in nixpkgs manually before asserting we don't have it.
  4. This issue is created by https://github.com/NixOS/security

Instructions:

  1. Triage a report: If we don't have the software or our version isn't
    vulnerable, tick the box or add a comment with the report number,
    stating it isn't vulnerable.
  2. Fix the issue: If we do have the software and it is vulnerable,
    either leave a comment on this issue saying so, even open a pull
    request with the fix. If you open a PR, make sure to tag this
    issue so we can coordinate.
  3. When an entire section is completed, move the section to the
    "Triaged and Resolved Issues" details block below.

Upon Completion ...

  • [x] Run the issue through reformat one last time
  • [x] Review commits since last roundup for backport candidates
  • [x] Send an update e-mail to [email protected]
  • [x] Update the database at https://github.com/NixOS/security

Without further ado...

Assorted (30 issues)

  • [x] [#710484](https://lwn.net/Vulnerabilities/710484/) (search, files) bash: code execution
  • [x] [#710286](https://lwn.net/Vulnerabilities/710286/) (search, files) openjpeg2: multiple vulnerabilities
  • [x] [#710478](https://lwn.net/Vulnerabilities/710478/) (search, files) python-crypto: denial of service
  • [x] [#710356](https://lwn.net/Vulnerabilities/710356/) (search, files) smack: TLS bypass
  • [x] [#710358](https://lwn.net/Vulnerabilities/710358/) (search, files) tracker: adding sandboxing
  • [x] [#710363](https://lwn.net/Vulnerabilities/710363/) (search, files) gstreamer-plugins-good: code execution
  • [x] [#710480](https://lwn.net/Vulnerabilities/710480/) (search, files) cxf: two vulnerabilities
  • [x] [#710486](https://lwn.net/Vulnerabilities/710486/) (search, files) cyassl: multiple vulnerabilities
  • [x] [#710281](https://lwn.net/Vulnerabilities/710281/) (search, files) js-jquery: cross-site scripting
  • [x] [#710475](https://lwn.net/Vulnerabilities/710475/) (search, files) libphp-phpmailer: code execution
  • [x] [#624315](https://lwn.net/Vulnerabilities/624315/) (search, files) mod-wsgi: privilege escalation
  • [x] [#710282](https://lwn.net/Vulnerabilities/710282/) (search, files) nagios-plugins: multiple vulnerabilities
  • [x] [#710482](https://lwn.net/Vulnerabilities/710482/) (search, files) php-zendframework-zend-mail: parameter injection
  • [x] [#710477](https://lwn.net/Vulnerabilities/710477/) (search, files) postgresql-common: file overwrites
  • [x] [#710283](https://lwn.net/Vulnerabilities/710283/) (search, files) python-wikitcms: code execution
  • [x] [#710483](https://lwn.net/Vulnerabilities/710483/) (search, files) springframework: directory traversal
  • [x] [#710485](https://lwn.net/Vulnerabilities/710485/) (search, files) chicken: two vulnerabilities
  • [x] [#632571](https://lwn.net/Vulnerabilities/632571/) (search, files) e2fsprogs: code execution
  • [x] [#710285](https://lwn.net/Vulnerabilities/710285/) (search, files) firejail-lts: denial of service
  • [x] [#710362](https://lwn.net/Vulnerabilities/710362/) (search, files) irc-otr: information disclosure
  • [x] [#710476](https://lwn.net/Vulnerabilities/710476/) (search, files) kernel: three vulnerabilities
  • [x] [#710487](https://lwn.net/Vulnerabilities/710487/) (search, files) libarchive: denial of service
  • [x] [#710481](https://lwn.net/Vulnerabilities/710481/) (search, files) libpng: NULL dereference bug
  • [x] [#604237](https://lwn.net/Vulnerabilities/604237/) (search, files) lzo: denial of service/possible code execution
  • [x] [#710489](https://lwn.net/Vulnerabilities/710489/) (search, files) mariadb: multiple unspecified vulnerabilities
  • [x] [#623865](https://lwn.net/Vulnerabilities/623865/) (search, files) mutt: denial of service
  • [x] [#710489](https://lwn.net/Vulnerabilities/710489/) (search, files) mariadb: multiple unspecified vulnerabilities
  • [x] [#710278](https://lwn.net/Vulnerabilities/710278/) (search, files) openfire: multiple vulnerabilities
  • [x] [#710490](https://lwn.net/Vulnerabilities/710490/) (search, files) pillow: heap-based buffer overflow
  • [x] [#629994](https://lwn.net/Vulnerabilities/629994/) (search, files) xdg-utils: command execution

curl (2 issues)

  • [x] [#710474](https://lwn.net/Vulnerabilities/710474/) (search, files) curl: information leak
  • [x] [#710279](https://lwn.net/Vulnerabilities/710279/) (search, files) curl: buffer overflow

xen (2 issues)

  • [x] [#710491](https://lwn.net/Vulnerabilities/710491/) (search, files) xen: denial of service
  • [x] [#710284](https://lwn.net/Vulnerabilities/710284/) (search, files) xen: denial of service
security

All 41 comments

Xen vulns were old.

libpng, firejail : recently updated

Should firejail be backported?

notes to apply to firejail:

CVE-2016-7545, CVE-2016-9016:

It was found that the sandbox tool provided in policycoreutils was vulnerable to a TIOCSTI ioctl attack. A specially crafted program executed via the sandbox command could use this flaw to execute arbitrary commands in the context of the parent shell, escaping the sandbox.

and fixes for:

security: overwrite /etc/resolv.conf found by Martin Carpenter
secuirty: TOCTOU exploit for –get and –put found by Daniel Hodson
security: invalid environment exploit found by Martin Carpenter
security: several security enhancements

See more: https://firejail.wordpress.com/download-2/release-notes/

Hm, hard to say when the vulnerability appeared. OK, let's backport it just in case…

chicken: 4.11 seems to be about fixing these vulnerabilities, present in both master and release.

@7c6f434c I see your backport, thank you! In the future, please backport using git cherry-pick -x COMMIT

Technically, for firejail it would be moot (different starting version, so a conflict), but will try to remember.

Thanks! My tooling for security notes detects the (cherry picked from commit ...) to make sure to duplicate them.

xdg_utils: we have 1.1.1 (both places), which seems to contain the fix. The vulnerability is two years old.

I really appreciate your help, this is excellent. I've noticed Gentoo has been picking up very old vulnerabilities lately, I wonder if they got some fresh blood on the team :)

Re: postgresql: does NixOS do logging in a similar enough way for that to be a concern? My only NixOS system doesn't run PostgreSQL, and my Nix-based PostgreSQL-running system does logging differently, but I expect journald to be different enough

I think we're good on posgresql, let's mark it fixed.

I don't use mainline NixOS enough to make this call.

lzo: old stuff, we are good

mutt: we have the branch-latest releases in two branches (1.7.2 and 1.6.2), the vulnerability is about 1.5.x

e2fsprogs: we have fresh stuff

Collapsed the completed ones.

bash report seems relevant. It is also a mass-rebuild. It looks like one of the bugs is present in 4.4 even, so we may need to take a patch (maybe from Gentoo). Although it seems that Bash upstream considers that last a guaranteed segfault with no exploitation potential.

We might use the opportunity and switch the default non-interactive bash to 4.4 (on master/staging). Can you see a reference to an upstream fix? I see nothing in the official 4.4 patch list.

I think upstream considers the fix in 4.4 branch not to be worth rushing, and Gentoo decided to include it as a patch anyway

mariadb is about 10.0 branch, we use a 10.1 release that is also fresher than the 10.0.28 fix.

We should verify the latest 10.1 releases to see if we're behind / missing a patch for something, and also our version(s) of mysql, since bugs in one are frequently in the other.

As for MariaDB: we are one patchlevel behind, and the freshest version doesn't have fixed vulnerabilities listed in release notes.

As for MySQL: the CVE is originally about MySQL. I wasn't sure we even still _have_ Oracle MySQL. But yeah, we are behind by a single patchlevel on 5.5 and 5.7, and there are security notes for each of them, will update if it is simple enough…

cxf: do we even ship Apache CXF?

irssi_otr: updated. Not sure whether we have some problems with irssi header installation; in this case it was easier to bruteforce -I flags to fit the layout, but it looks like irssi headers expect strange relative paths to work.

MySQL also updated.

Both fixes ported to release branch.

openjpeg: Apparently there is a ton of fuzzing-found issues upstream, and no recent changes in the master repository.

One of the people doing the fuzzing tried to fix as many of the issues as possible and thinks this patch is a good step in this direction; I haven't looked at the patch, though:
https://github.com/uclouvain/openjpeg/pull/875/files

openfire is an interesting case. The version in NixPkgs is older than what the CVE talks about; I used it long long time ago. The fresh version of OpenFire just expects to be able to write to its installation directory in random places (not just logs and config, which I have replaced with symlinks to somewhat reasonable locations), and on the other hand its installation is still just unpacking and patching a few lines here and there. I guess the package could be marked as broken.

python-crypto or pycrypto isn't being maintained anymore. According to this comment the issue has been resolved on master already 3 years ago, but it hasn't been included in any release.

A maintained fork of pycrypto is pycryptodome. We should see if we can replace pycrypto with pycryptodome.

Pillow:

Integer overflow in the ImagingResampleHorizontal function in libImaging/Resample.c in Pillow before 3.1.1 allows remote attackers to have unspecified impact via negative values of the new size, which triggers a heap-based buffer overflow.

We have 3.4.2 on both stable and master so we're fine.

@FRidh does that need to be backported? Is it okay to backport?

Bash should be OK now in staging and 16.09,

We're safe on gstreamer-plugins-good as we already have the release with the fix.

Tracker doesn't have a CVE but Fedora somehow sandboxed tracker. I think this is not applicable for us for now.

pycrypto is fixed by https://github.com/NixOS/nixpkgs/commit/fe9373460c08c83449657b22c026c806bec92d21.

Unfortunately we can't just replace pycrypto with pycryptodome. In the long run we do have to get rid of that package which likely means updating a lot of dependents.

@FRidh pycryptodome advertises itself as a drop-in replacement for pycrypto, so I guess they ensure the API is backwards-compatible. So the only issue is that packages still depend on pycrypto instead of pycryptodome, right? Can't we fake the package name or introduce a dummy package named pycrypto which pulls in pycryptodome and in turn the Crypto python module?

@fpletz yes we can, #21671

Irssi just released a new version due to these security vulnerabilities: https://irssi.org/security/irssi_sa_2017_01.txt

I bumped smack on master from 3.4.1 to 4.1.9 where the issue is fixed. As we were using the pre-compiled jars, we can't trivally apply a patch and that version bump is likely to break stuff. Fortunately nothing in nixpkgs depends on smack.

Should we upgrade smack to 4.1.9 or mark is as broken? I'd go for upgrade because nobody is probably using it anyway.

@fpletz I would prefer marking as broken than upgrading, for now. We'll see if people make an issue in the bug tracker what they'd like to do :)

For openjpeg2, I've got found and applied several patches. Here is my diff:

diff --git a/pkgs/development/libraries/openjpeg/2.1.nix b/pkgs/development/libraries/openjpeg/2.1.nix
index 9e3c447..b9e0637 100644
--- a/pkgs/development/libraries/openjpeg/2.1.nix
+++ b/pkgs/development/libraries/openjpeg/2.1.nix
@@ -1,4 +1,4 @@
-{ callPackage, ... } @ args:
+{ callPackage, fetchpatch, ... } @ args:

 callPackage ./generic.nix (args // rec {
   version = "2.1.2";
@@ -12,5 +12,51 @@ callPackage ./generic.nix (args // rec {
     # Put in our source code to make sure we don't lose it, since that
     # referenced commit is someone else's fork, and not actually up-stream.
     ./CVE-2016-9580-and-CVE-2016-9581.patch
+
+    #(fetchpatch {
+    #  url = "https://bugzilla.suse.com/attachment.cgi?id=707353&action=diff&context=patch&collapsed=&headers=1&format=raw";
+    #  name = "CVE-2016-9113.patch";
+    #  sha256 = "1zb90m4hwrdddb8lc4pgi1xxmi5f08a22kcq3lbz2y6zfd5vfi4k";
+    #})
+    (fetchpatch {
+      url = "https://bugzilla.suse.com/attachment.cgi?id=707354&action=diff&context=patch&collapsed=&headers=1&format=raw";
+      name = "CVE-2016-9114.patch";
+      sha256 = "0qam3arw9kdbh4501xim2pyldl708dnpyjwvjmwc9gc7hcq4gfi3";
+    })
+    #(fetchpatch {
+    #  url = "https://bugzilla.suse.com/attachment.cgi?id=707355&action=diff&context=patch&collapsed=&headers=1&format=raw";
+    #  name = "CVE-2016-9115.patch";
+    #  sha256 = "1x9lh5ga67pvjf1z33dgdivzj4k8g8jwdgvfpmk5qqhmmk8zkg8x";
+    #})
+    (fetchpatch {
+      url = "https://bugzilla.suse.com/attachment.cgi?id=707356&action=diff&context=patch&collapsed=&headers=1&format=raw";
+      name = "CVE-2016-9116.patch";
+      sha256 = "0yyb3pxqi5sr44a48bacngzp206j4z49lzkg6hbkz1nra9na61a3";
+    })
+    #(fetchpatch {
+    #  url = "https://bugzilla.suse.com/attachment.cgi?id=707357&action=diff&context=patch&collapsed=&headers=1&format=raw";
+    #  name = "CVE-2016-9117.patch";
+    #  sha256 = "0m8c43msqlggiw2pmbr4cangbkkfpjwhp45bsf5vchh633ybyvz0";
+    #})
+    (fetchpatch {
+      url = "https://bugzilla.suse.com/attachment.cgi?id=707358&action=diff&context=patch&collapsed=&headers=1&format=raw";
+      name = "CVE-2016-9118.patch";
+      sha256 = "125n8bmh07y7697s0y82ypb39rxgj0bdn8rcywbvamscagwg2wy9";
+    })
+    (fetchpatch {
+      url = "https://bugzilla.suse.com/attachment.cgi?id=707359&action=diff&context=patch&collapsed=&headers=1&format=raw";
+      name = "CVE-2016-9112.patch";
+      sha256 = "18hqx73wdzfybr5n5k6pzhbhdlmawiqbjci8n82zykxiyfgp18pd";
+    })
+    #(fetchpatch {
+    #  url = "https://bugzilla.suse.com/attachment.cgi?id=707360&action=diff&context=patch&collapsed=&headers=1&format=raw";
+    #  name = "CVE-2016-9572-CVE-2016-9573.patch";
+    #  sha256 = "1qzmhr5k7vr1nlv2cgv92858mr4g2bhh8y4fw28dwgi9djfvnzn8";
+    #})
+    #(fetchpatch {
+    #  url = "https://bugzilla.suse.com/attachment.cgi?id=707351&action=diff&context=patch&collapsed=&headers=1&format=raw";
+    #  name = "CVE-2016-7445.patch";
+    #  sha256 = "1zswpsjs8if79x0a5dr27173434dx5q1jryv7ql9afd7sp1zdccw";
+    #})
   ];
 })

the commented ones don't apply cleanly, presumably because suse is on a different version. Debian doesn't have alternative patches yet. What do you think, @fpletz? Patch what we can now?

All channels except nixos-unstable have updated and contain the mass-rebuild changes (e.g. bash).

I've decided to apply the patches that I do have, and leave openjpeg2 in the list for next week to see if any development has taken place.

Done. Phew! Good work and thank you :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tomberek picture tomberek  Â·  3Comments

lverns picture lverns  Â·  3Comments

yawnt picture yawnt  Â·  3Comments

sid-kap picture sid-kap  Â·  3Comments

domenkozar picture domenkozar  Â·  3Comments