# Gentoo and security (or lack thereof)

## saturnalia0

I'm a happy Gentoo user (and noob), but I have been disappointed about security lately - I was wondering what is the rationale behind the delay to push some security updates. Forgive me if that's not the case, if there is no reason for disappointment and if there's no delay - I have never maintained a package and I am not completely aware of what goes on behind the scenes. But it seems to me that Gentoo is constantly (very) behind other distros of its league when it comes to security updates. Take for instance the recent advisories from LWN:

 *Quote:*   

> 
> 
> Gentoo has updated binutils (multiple vulnerabilities from 2014), coreutils (code execution from 2014), cracklib (code execution), jq (code execution from 2015), openjpeg (multiple vulnerabilities, one from 2015), socat (encryption botch), and sqlite (code execution from 2015). 
> 
> 

 

https://lwn.net/Articles/708516/rss

Remote code execution and other severe vulnerabilities from two years ago, in a ubiquitous package such as binutils. One would think this would have been pushed several years ago. Granted, I don't know if the issue was only fixed now or if it was in fact a delay on Gentoo security team's part, but take for instance the mupdf package, which has a widely reported use after free bug (a malicious user could send me a .pdf that would allow him to execute arbitrary code when opened with mupdf):

https://bugs.gentoo.org/show_bug.cgi?id=589826

As I have mentioned in the comments there, there was a fix upstream for three months and I still didn't have any updates on Gentoo. Now, this is the maintainers fault, is it not? I realize time is a valuable resource and that the work is voluntary, but I think there is nevertheless a critic to be made. That being said I would gladly contribute to package maintenance, but I fear my lack of experience and knowledge inhibit me from doing so for the time being.

----------

## Ant P.

 *saturnalia0 wrote:*   

> Remote code execution and other severe vulnerabilities from two years ago, in a ubiquitous package such as binutils. One would think this would have been pushed several years ago.

 

```
*binutils-2.25 (09 Feb 2015)

  09 Feb 2015; Mike Frysinger <vapier@gentoo.org> +binutils-2.25.ebuild:

  Version bump #533454 by Lars Wendler.
```

One evidently did not bother to think.

----------

## Hu

Sometimes the security advisory comes out very late, relative to the maintainer pushing a package update that fixes the problem.  I have seen several cases recently where a GLSA advised installing a version and, on checking, I had already installed that version months ago just because it had become available.

----------

## Spargeltarzan

Did someone try already using a different cve checker tool from another distribution in Gentoo beside glsa-check?

For example I found the CVE-Check-tool on Github.

An (maybe outdated or superficial) overview of distributions is shown here https://lzone.de/blog/Automated%20Linux%20Package%20Vulnerability%20Scanning

I also observe cve reported on the software developers' webpage, but not in glsa. Lately my installed thunderbird was affected, but not reported by glsa-check.

If someone can share his or her experience with another checking-tools in Gentoo, thanks in advance!

ADD: When we speek about the devil:

https://lwn.net/Articles/759211/

"Multiple security issues were discovered in Firefox. If a user were

tricked in to opening a specially crafted website, an attacker could

potentially exploit these to cause a denial of service, read uninitialized

memory, bypass same-origin restrictions, bypass CORS restrictions,

bypass CSRF protections, obtain sensitive information, or execute

arbitrary code. (CVE-2018-5156, CVE-2018-5186, CVE-2018-5187,

CVE-2018-5188, CVE-2018-12358, CVE-2018-12359, CVE-2018-12360,

CVE-2018-12361, CVE-2018-12362, CVE-2018-12363, CVE-2018-12364,

CVE-2018-12365, CVE-2018-12366, CVE-2018-12367, CVE-2018-12370,

CVE-2018-12371)"

Instruction: To upgrade to firefox 61.

Firefox 61.0.1 not in Gentoo tree yet. Latest firefox-bin available, what I use, 60.1. Maybe this is fixed in LTS version 52.9, don't know, but it is not stabilized yet.

----------

## krinn

People always forget CVE checker only base their checks against a version.

It mean:

packageZ version 1.0 will ring a bell if CVE is against <packageZ-1.1

while gentoo packageZ-1.0 could just be made of: packageZ-1.0 + patches with fixes.

glsa-check will do just the work, because it is made for gentoo. And your guy just mark it bad because he is not using gentoo and the lack of documentation (for him, you have --help and man ready for glsa-check) cve are handle thru bugreport, and push to forum when solve is available.

I'm not using redhat, should i mark "bad" their checker just because i know nothing about it?

german hosted website always seems quiet flexible with truth and correctness (that's a joke because of 0pointer.de).

----------

## Spargeltarzan

I didn't cite this site because "glsa-checker" is marked as bad, I know people "from outside the gentoo-world" often write bad reports about Gentoo because they don't use & understand it. I cited it for an overview of available cve-checkers in the Linux world.

I asked myself if there is a need for an additional cve-checker, because glsa might be late. Now I see with this tool I would have wrong reports without knowing "+patches applied in background".

Nevertheless, why does glsa not report public CVEs on our local systems? We would benefit from it, for example now we could upgrade to ~amd64 firefox if we want this CVE to be closed (what devs currently work for days on it. For firefox-bin they just stated "lack of manpower".) At least users would have awareness on affected CVEs. When you search for "security" on bugs.gentoo.org, we see plenty of packages currently affected. Some on outdated ones, some on current ones. Webkit-gtk 2.18.6 the same. Upgrading to ~amd64 might be a trap for a too mixed stable/testing system, but at least we would have awareness on it and a choice.

----------

