kdesu security update needed

kdesu security update needed

[Leo Famulari]

kdesu has a string handling bug, CVE-2016-7787:

http://seclists.org/oss-sec/2016/q3/653

David, since you added all the KDE packages, can you look into this bug
and see what we need to do to protect against it?

Re: kdesu security update needed

[David Craven]

> David, since you added all the KDE packages, can you look into this bug
> and see what we need to do to protect against it?

They have a vendored kdesu. The source files look pretty different
now, and I'm having a little trouble seeing if the problem is in kde
kdesu or just kde-cli-tools kdesu. From what I can tell the source has
diverged and the problem seems to be with the cli client they wrote
for the kdesu deamon or something like that. Don't know if this is a
satisfying answer...

Re: kdesu security update needed

[David Craven]

Ah just checked our linter doesn't flag a CVE, so I think we're ok...

Re: kdesu security update needed

[Leo Famulari]

On Thu, Sep 29, 2016 at 08:52:34PM +0200, David Craven wrote:
> Ah just checked our linter doesn't flag a CVE, so I think we're ok...

The linter is a good tool for catching things that we miss, but it's not
a substitute for manual investigation :)

First, our package's name might not match the name used by the Common
Platform Enumeration [0], which is the name that the linter looks up. We
can give packages a cpe-name property [1], which tells the linter to use
something besides the package's name.

Second, I've noticed that sometimes bugs are publicized on oss-sec or
elsewhere, but then they don't show up in the CVE database for a while.

An aside, the CVE linter gives false positives for grafted packages. For
example, try `guix lint -c cve openssl@1.0`.

[0]
https://nvd.nist.gov/cpe.cfm

[1] An example:
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gd.scm#n76

Re: kdesu security update needed

[Leo Famulari]

On Thu, Sep 29, 2016 at 08:35:53PM +0200, David Craven wrote:
> > David, since you added all the KDE packages, can you look into this bug
> > and see what we need to do to protect against it?
> 
> They have a vendored kdesu. The source files look pretty different
> now, and I'm having a little trouble seeing if the problem is in kde
> kdesu or just kde-cli-tools kdesu. From what I can tell the source has
> diverged and the problem seems to be with the cli client they wrote
> for the kdesu deamon or something like that. Don't know if this is a
> satisfying answer...

Yeah, that's my interpretation as well. Thanks for looking :)

Re: kdesu security update needed

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Thu, Sep 29, 2016 at 08:52:34PM +0200, David Craven wrote:
>> Ah just checked our linter doesn't flag a CVE, so I think we're ok...
>
> The linter is a good tool for catching things that we miss, but it's not
> a substitute for manual investigation :)

+1

> First, our package's name might not match the name used by the Common
> Platform Enumeration [0], which is the name that the linter looks up. We
> can give packages a cpe-name property [1], which tells the linter to use
> something besides the package's name.
>
> Second, I've noticed that sometimes bugs are publicized on oss-sec or
> elsewhere, but then they don't show up in the CVE database for a while.

Often, vulnerabilities and CVE IDs are publicized when the CVE ID is
still marked as “reserved” without additional info; reserved CVE IDs
don’t show up in the CVE database that ‘guix lint’ fetches.

> An aside, the CVE linter gives false positives for grafted packages. For
> example, try `guix lint -c cve openssl@1.0`.

That’s been annoying me for some time so I’d like to see if we can
improve grafting in a way that would allow us to use a different version
number in the package replacement, which in turn would allow ‘guix lint’
to see the right version number of the replacement.

Ludo’.

Re: kdesu security update needed

[David Craven]

Thank you for the info @Leo and @Ludo, just noticed that it's
mentioned in the manual.

One question that wasn't answered yet in your description and the
manual is how the linter detects when a package is patched. I assume
it looks at the applied patch names see if they contain a CVE code?

Re: kdesu security update needed

[Leo Famulari]

On Sat, Oct 01, 2016 at 02:19:05PM +0200, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> > An aside, the CVE linter gives false positives for grafted packages. For
> > example, try `guix lint -c cve openssl@1.0`.
> 
> That’s been annoying me for some time so I’d like to see if we can
> improve grafting in a way that would allow us to use a different version
> number in the package replacement, which in turn would allow ‘guix lint’
> to see the right version number of the replacement.

That would be nice. The current situation (with misleading package
versions) is a huge improvement over what we had before, but I think
that users should not need to understand the implementation details of
grafting to determine the version of packages.

I always figured this quirky limitation was a side-effect of rushing to
implement recursive grafting before OpenSSL 1.0.2g was released.

Re: kdesu security update needed

[Ludovic Courtès]

David Craven <david@craven.ch> skribis:

> One question that wasn't answered yet in your description and the
> manual is how the linter detects when a package is patched. I assume
> it looks at the applied patch names see if they contain a CVE code?

Exactly: it checks the version number and the name of the applied
patches.

Ludo’.

Re: kdesu security update needed

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Sat, Oct 01, 2016 at 02:19:05PM +0200, Ludovic Courtès wrote:
>> Leo Famulari <leo@famulari.name> skribis:
>> > An aside, the CVE linter gives false positives for grafted packages. For
>> > example, try `guix lint -c cve openssl@1.0`.
>> 
>> That’s been annoying me for some time so I’d like to see if we can
>> improve grafting in a way that would allow us to use a different version
>> number in the package replacement, which in turn would allow ‘guix lint’
>> to see the right version number of the replacement.
>
> That would be nice. The current situation (with misleading package
> versions) is a huge improvement over what we had before, but I think
> that users should not need to understand the implementation details of
> grafting to determine the version of packages.
>
> I always figured this quirky limitation was a side-effect of rushing to
> implement recursive grafting before OpenSSL 1.0.2g was released.

Done in commit 57bdd79e485801ccf405ca7389bd099809fe5d67!  And with
9bee2bd1b02c7ef91cc7232e8647bd07525d3382, ‘guix lint -c cve openssl@1.0’
reports the right thing (zero known CVEs).

Ludo’.

Re: kdesu security update needed

[Leo Famulari]

On Mon, Oct 03, 2016 at 11:36:48PM +0200, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> 
> > On Sat, Oct 01, 2016 at 02:19:05PM +0200, Ludovic Courtès wrote:
> >> Leo Famulari <leo@famulari.name> skribis:
> >> > An aside, the CVE linter gives false positives for grafted packages. For
> >> > example, try `guix lint -c cve openssl@1.0`.
> >> 
> >> That’s been annoying me for some time so I’d like to see if we can
> >> improve grafting in a way that would allow us to use a different version
> >> number in the package replacement, which in turn would allow ‘guix lint’
> >> to see the right version number of the replacement.
> >
> > That would be nice. The current situation (with misleading package
> > versions) is a huge improvement over what we had before, but I think
> > that users should not need to understand the implementation details of
> > grafting to determine the version of packages.
> >
> > I always figured this quirky limitation was a side-effect of rushing to
> > implement recursive grafting before OpenSSL 1.0.2g was released.
> 
> Done in commit 57bdd79e485801ccf405ca7389bd099809fe5d67!  And with
> 9bee2bd1b02c7ef91cc7232e8647bd07525d3382, ‘guix lint -c cve openssl@1.0’
> reports the right thing (zero known CVEs).

Awesome :)