Subject: [alpine-devel] Alpine security tracker

From: Quentin Machu <[email-masked]>
Date: Thu, 24 Mar 2016 16:34:43 -0400

Hi,

My name’s Quentin Machu and I am the primary maintainer of Clair [1],  an
open source project for the static analysis of vulnerabilities in
containers, by CoreOS. The project, which aim at bringing security
awareness to everyone, recently went 1.0 [2] and is considerably well
received by the community.

As Alpine grows more and more popular, especially for containers to which
it becomes a really common base image, I believe that it would be extremely
valuable for Alpine to track vulnerabilities that may affect its packages.
Several Linux distributions, such as Debian [3][4], Ubuntu [5][6], RHEL
[7][8], Arch [9], already do through advisories and parsable databases.

Since the very beginning of Clair, the community has shown a significant
interest in being informed about the potential security flaws that may
threaten their Alpine-based containers [10].

[1]: https://github.com/coreos/clair

[2]: https://coreos.com/blog/clair-v1.html

[3]: https://www.debian.org/security/

[4]: https://security-tracker.debian.org/tracker/

[5]: http://www.ubuntu.com/usn/

[6]: https://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/

[7]: https://rhn.redhat.com/errata/

[8]: https://www.redhat.com/security/data/oval/

[9]: https://wiki.archlinux.org/index.php/CVE

[10]: https://github.com/coreos/clair/issues/12

Best Regards,
Quentin Machu

---

From: Leonardo Arena <[email-masked]>
Date: Thu, 24 Mar 2016 21:50:06 +0100

Hi,

> 
> My name’s Quentin Machu and I am the primary maintainer of Clair [1],
>  an open source project for the static analysis of vulnerabilities in
> As Alpine grows more and more popular, especially for containers to
> which it becomes a really common base image, I believe that it would
> be extremely valuable for Alpine to track vulnerabilities that may
> affect its packages. 

We already do that in our bug traker:
https://bugs.alpinelinux.org/projects/alpine/issues?set_filter=1&status_id=c&tracker_id=1

> Several Linux distributions, such as Debian [3][4], Ubuntu [5][6],
> RHEL [7][8], Arch [9], already do through advisories and parsable
> databases.
> 

We don't issue our own advisories if that's what you mean. That would
require more man power which I think we prefer to spend on fixing the
security issues.

- leo

---

From: Andy Shinn <[email-masked]>
Date: Thu, 24 Mar 2016 16:02:54 -0500

I wonder if just an additional field or two in Redmine could help
satisfy requirements for Clair without adding too much additional
overhead. What if Redmine had an additional tracker called Security
and a custom CVE field that container the CVE. Would this be too much
additional work for users / maintainers entering data when it is
related to a CVE?

Redmine already provides a way to grab data from the tracker in CSV
and XML form. If Clair could filter on a Security tracker to get the
CVE and associated packages then this might be a simple addition to
start work on the Clair side (assuming this is a valid way of
consuming the CVE data).

> require more man power which I think we prefer to spend on fixing the

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Leonardo Arena <[email-masked]>
Date: Thu, 24 Mar 2016 22:03:25 +0100

> require more man power which I think we prefer to spend on fixing the

Just as an example, apparently Debian stable and older are still
vulnerable to CVE-2016-3115 [1]. We didn't issue an advisory but Alpine
is no longer vulnerable [2][3], not even its older supported release
[4].

I'm not saying that's always the case, but we try do more the actual
work, than the paperwork ;-)

- leo

[1] https://security-tracker.debian.org/tracker/CVE-2016-3115
[2] https://bugs.alpinelinux.org/issues/5286
[3] https://bugs.alpinelinux.org/issues/5287
[4] https://bugs.alpinelinux.org/issues/5288

---

From: Quentin Machu <[email-masked]>
Date: Thu, 24 Mar 2016 18:21:25 -0400

Thanks for your open and quick answers.

From: Leonardo Arena <[email-masked]>

We already do that in our bug traker: https://bugs.alpinelinux.org/projects/alpine/issues?set_filter=1&status_id=c&tracker_id=1 

That’s great! I regret that I wasn’t aware of this yet.

From: Andy Shinn <[email-masked]>

Definitely, parsing properly seems to be the obstacle here. Extracting data from human-written text is unfortunately impracticable. However, Clair could undoubtedly parse Alpine’s Redmine if it would expose data in a fixed format (i.e. static fields available in CSV/XML/YAML/JSON…).

About a vulnerability, Clair usually ingests:
- Vulnerability name,
- Severity (e.g. Negligible, Low, Medium, High, Critical),
- Short description about the vulnerability,
- Link (e.g. link to Redmine),
- A list of affected package names, with their fixed version if applicable (otherwise, all versions are considered vulnerable).

Typically, the affected packages are also namespaced by the operating system version. This is useful to keep track of back ports. A specific vulnerability affecting a package X could be fixed by 1.44+bp2 in an oldstable distribution but fixed by 1.59 in the stable distribution. In that case, we would have twice package X in the list, but with two different namespaces and versions. I am not familiar with Alpine Linux to know if this makes sense here. If it doesn't (i.e. if we can usually upgrade any package to the latest versions), then it doesn’t matter, a single namespace can be used.

Another small concern, that we encounter with Arch Linux support [1], is reliability: it is quite important to be able to determine which data can be trusted. We must avoid consuming data filled by malicious users who would like to manipulate 3rd party applications (such as Clair). This can be mitigated with various solutions though.

From: Leonardo Arena <[email-masked]>

we try do more the actual work, than the paperwork ;-) 

I absolutely agree with you on that point. If making Alpine’s security data a bit more formatted, thus enabling automated systems to collect data in an useful way, represents a tiny/modest amount of work, I believe that it would be an important step forward for everybody in terms of security.

What do you think?

[1]: https://github.com/coreos/clair/pull/60#issuecomment-169699188

Best Regards,
Quentin Machu

From: Leonardo Arena <[email-masked]>
Reply: Leonardo Arena <[email-masked]>
Date: March 24, 2016 at 5:03:28 PM
To: Quentin Machu <[email-masked]>
CC: [email-masked] <[email-masked]>
Subject:  Re: [alpine-devel] Alpine security tracker  

- leo

---

From: Isaac Dunham <[email-masked]>
Date: Thu, 24 Mar 2016 21:59:06 -0700

> Definitely, parsing properly seems to be the obstacle here. Extracting data from human-written text is unfortunately impracticable. However, Clair could undoubtedly parse Alpine’s Redmine if it wou…

There are links to Atom, CSV, and PDF versions of the tracker data at
the bottom of the page mentioned.
Change 'issues' to 'issues.csv' and you get the CSV version.
However, as you mentioned, there's no CVE field.
There's also no associated package version.
However, it's theoretically possible to retrieve the package version in
an automated manner:
each issue has an associated git revision, and the diff will include a
change to the APKBUILD touching at least one of the two version numbers:
pkgver and pkgrel.
This is obviously going to be rather cumbersome to retrieve from a CVE
checker;
is there a way to hook into Redmine so it automatically parses this to add
pkgver/pkgrel fields?

Sometimes (usually? always?), if there are multiple releases affected,
there are separate issues for each release, with the affected release
tagged.

For example:
5288,Alpine Linux,Bug,Closed,Normal,[3.0] openssh: missing sanitisation of input for X11 forwarding (CVE-2016-3115),Natanael Copa,03/23/2016 10:48 AM 
5287,Alpine Linux,Bug,Closed,Normal,[3.1] openssh: missing sanitisation of input for X11 forwarding (CVE-2016-3115),Natanael Copa,03/23/2016 10:48 AM 
5286,Alpine Linux,Bug,Closed,Normal,[3.2] openssh: missing sanitisation of input for X11 forwarding (CVE-2016-3115),Natanael Copa,03/23/2016 10:48 AM 

If a bug is filed against the current release only, it will not be tagged.

> Typically, the affected packages are also namespaced by the operating
> system version. This is useful to keep track of back ports. A specific
> vulnerability affecting a package X could be fixed by 1.44+bp2 in an
> oldstable distribution but fixed by 1.59 in the stable distribution. In
> that case, we would have twice package X in the list, but with two
> different namespaces and versions. I am not familiar with Alpine Linux
> to know if this makes sense here. If it doesn't (i.e. if we can usually
> upgrade any package to the latest versions), then it doesn’t matter, a
> single namespace can be used.

You might have different versions at the same time, yes.
BTW: rather than testing/stable/oldstable, we have 'edge' and multiple
numbered releases.

---

---

From: Quentin Machu <[email-masked]>
Date: Fri, 25 Mar 2016 16:35:05 -0400

From: Isaac Dunham <[email-masked]>

From what I saw, the descriptions usually mention the packages and their fixed versions (if any) [1][2]. Could we simply create fields to store them instead of writing them in the description? So we could easily parse them using any of the Redmine's export format (XML, …)?

Sometimes, I am confused though because multiple different fixed versions are listed, for the same Alpine Linux release [3][4].

[1]: https://bugs.alpinelinux.org/issues/5288
[2]: https://bugs.alpinelinux.org/issues/5238
[3]: https://bugs.alpinelinux.org/issues/5209
[4]: https://bugs.alpinelinux.org/issues/5244

For example: 

This is pretty great, with that information and the package names/versions as discussed above, we basically have the hard part figured out. The rest is rest vulnerability name, severity, description as mentioned in my previous e-mail. Except for the severity, the CVE names and descriptions are also present either in the title and/or in the description. It probably just needs a more stable format to be parsable, I am not sure how it could be achieved with Redmine though.

Sure, that makes a lot of sense. That’s how Clair do it with other distributions, it uses numbered versions and then “unstable” (or “edge” in Alpine's case). I just wanted to simplify.

To summarize a bit, Clair (or any automated system with similar purposes) has to be able to parse something like that at the end of the day:

Alpine-release: 3.2
Name: CVE-2015-XXXX
Severity: High
Description: […]
Link: https://bugs.alpinelinux.org/issues/X
Affecting:
  - bind9 (fixed by 9.10)
  - dnsmasq (unfixed)
  
Alpine-release: 3.3
Name: CVE-2015-XXXX
Severity: Medium
Description: […]
Link: https://bugs.alpinelinux.org/issues/Y
Affecting:
  - bind9 (fixed by 9.15)
  - dnsmasq (fixed by 9.40)
  - skydns (unfixed)

Best Regards,
Quentin Machu