~alpine/devel

6 4

[alpine-devel] Alpine security tracker

Quentin Machu
Details
Message ID
<CANtECw8gn93aiQ4qGoGcM3TJ4C6vLAK45cp62_nmHEL1usfg7A@mail.gmail.com>
Sender timestamp
1458851683
DKIM signature
missing
Download raw message
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
Andy Shinn
Details
Message ID
<CAGF8=FzNuH=-yoyYAukg8gEoHF=Dso5J3HpAxSO2zCEbkqMXFA@mail.gmail.com>
In-Reply-To
<1458852606.9023.4.camel@c89m3s1> (view parent)
Sender timestamp
1458853374
DKIM signature
missing
Download raw message
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).

On Thu, Mar 24, 2016 at 3:50 PM, Leonardo Arena <rnalrd@gmail.com> wrote:
> Il giorno gio, 24/03/2016 alle 16.34 -0400, Quentin Machu ha scritto:
>> Hi,
>>
>
> 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.
>
> 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
>


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Quentin Machu
Details
Message ID
<etPan.56f46865.4aa9575.644@coreos.com>
In-Reply-To
<1458853405.9023.10.camel@c89m3s1> (view parent)
Sender timestamp
1458858085
DKIM signature
missing
Download raw message
Thanks for your open and quick answers.

From: Leonardo Arena <rnalrd@gmail.com>

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 <andys@andyshinn.as>

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). 


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 <rnalrd@gmail.com>

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 <rnalrd@gmail.com>
Reply: Leonardo Arena <rnalrd@gmail.com>
Date: March 24, 2016 at 5:03:28 PM
To: Quentin Machu <quentin.machu@coreos.com>
CC: alpine-devel@lists.alpinelinux.org <alpine-devel@lists.alpinelinux.org>
Subject:  Re: [alpine-devel] Alpine security tracker  

Il giorno gio, 24/03/2016 alle 21.50 +0100, Leonardo Arena ha scritto:  
> Il giorno gio, 24/03/2016 alle 16.34 -0400, Quentin Machu ha scritto:  
> > Hi,  
> >  
>  
> 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.  
>  
> 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.  
>  

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
Leonardo Arena
Details
Message ID
<1458852606.9023.4.camel@c89m3s1>
In-Reply-To
<CANtECw8gn93aiQ4qGoGcM3TJ4C6vLAK45cp62_nmHEL1usfg7A@mail.gmail.com> (view parent)
Sender timestamp
1458852606
DKIM signature
missing
Download raw message
Il giorno gio, 24/03/2016 alle 16.34 -0400, Quentin Machu ha scritto:
> Hi,
> 

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. 

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
Isaac Dunham
Details
Message ID
<20160325045905.GA6060@newbook>
In-Reply-To
<etPan.56f46865.4aa9575.644@coreos.com> (view parent)
Sender timestamp
1458881946
DKIM signature
missing
Download raw message
On Thu, Mar 24, 2016 at 06:21:25PM -0400, Quentin Machu wrote:
> Thanks for your open and quick answers.
> 
> From: Leonardo Arena <rnalrd@gmail.com>
> 
> 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 <andys@andyshinn.as>
> 
> 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). 
> 
> 
> 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…).

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.

> 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.

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

> 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 <rnalrd@gmail.com>
> 
> 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 <rnalrd@gmail.com>
> Reply: Leonardo Arena <rnalrd@gmail.com>
> Date: March 24, 2016 at 5:03:28 PM
> To: Quentin Machu <quentin.machu@coreos.com>
> CC: alpine-devel@lists.alpinelinux.org <alpine-devel@lists.alpinelinux.org>
> Subject:  Re: [alpine-devel] Alpine security tracker  
> 
> Il giorno gio, 24/03/2016 alle 21.50 +0100, Leonardo Arena ha scritto:  
> > Il giorno gio, 24/03/2016 alle 16.34 -0400, Quentin Machu ha scritto:  
> > > Hi,  
> > >  
> >  
> > 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.  
> >  
> > 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.  
> >  
> 
> 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  


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Leonardo Arena
Details
Message ID
<1458853405.9023.10.camel@c89m3s1>
In-Reply-To
<1458852606.9023.4.camel@c89m3s1> (view parent)
Sender timestamp
1458853405
DKIM signature
missing
Download raw message
Il giorno gio, 24/03/2016 alle 21.50 +0100, Leonardo Arena ha scritto:
> Il giorno gio, 24/03/2016 alle 16.34 -0400, Quentin Machu ha scritto:
> > Hi,
> > 
> 
> 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. 
> 
> 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.
> 

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
Quentin Machu
Details
Message ID
<etPan.56f5a0f9.d94e619.644@coreos.com>
In-Reply-To
<20160325045905.GA6060@newbook> (view parent)
Sender timestamp
1458938105
DKIM signature
missing
Download raw message
From: Isaac Dunham <ibid.ag@gmail.com>

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?

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

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. 

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.

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

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