Gaps in security coverage?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Gaps in security coverage?

John Goerzen-3
Hi folks,

So I recently started running debsecan on one of my boxes.  It's a
fairly barebones server install, uses unattended-upgrades and is fully
up-to-date.  I expected a clean bill of health, but didn't get that.  I
got pages and pages and pages of output.  Some of it (especially kernel
related) I believe may be false positives, but not all.  Some of it
simply isn't patched yet.

Diving into it a bit, it seems that somehow we fell down a bit with
stretch.  The first hit on my list is this one:

https://security-tracker.debian.org/tracker/CVE-2011-5325

Marked fixed in jessie, vulnerable in stretch.  And indeed when looking
at the bug report 802702, I don't see any such changelog entries
pertaining to this in my stretch version.

So, the questions -

1) Is this a symptom of a bad process or of not enough volunteers?  In
other words, could we have marked these security bugs fixed in jessie as
RC for stretch somehow until they were also fixed there?

2) Is there a need for more help with security in general?  If so, what
kinds of volunteering would be appreciated?

Thanks,

John

Reply | Threaded
Open this post in threaded view
|

Re: Gaps in security coverage?

Paul Wise via nm
On Mon, Nov 5, 2018 at 10:29 PM John Goerzen wrote:

> Hi folks,

FTR, in case you were trying to contact the Debian Security Team
directly I suggest using [hidden email] or
[hidden email] instead, debian-security is more of a general
security discussion list than a Debian Security Team list.

> So I recently started running debsecan on one of my boxes.  It's a
> fairly barebones server install, uses unattended-upgrades and is fully
> up-to-date.  I expected a clean bill of health, but didn't get that.  I
> got pages and pages and pages of output.  Some of it (especially kernel
> related) I believe may be false positives, but not all.  Some of it
> simply isn't patched yet.

That has been the normal state of things since I started running
debsecan many many years ago.

> Diving into it a bit, it seems that somehow we fell down a bit with
> stretch.  The first hit on my list is this one:
>
> https://security-tracker.debian.org/tracker/CVE-2011-5325
>
> Marked fixed in jessie, vulnerable in stretch.  And indeed when looking
> at the bug report 802702, I don't see any such changelog entries
> pertaining to this in my stretch version.

You can see at the bottom of this issue:

[stretch] - busybox <no-dsa> (Minor issue)

This means that the security team determined it is not an important
enough issue for them to fix in stable, but the maintainer could still
fix it in a point release if they cared.

> 1) Is this a symptom of a bad process or of not enough volunteers?  In
> other words, could we have marked these security bugs fixed in jessie as
> RC for stretch somehow until they were also fixed there?

I would guess mostly a lack of volunteers and also we need to give
package maintainers more responsibility for fixing the issues.

> 2) Is there a need for more help with security in general?  If so, what
> kinds of volunteering would be appreciated?

First rule of FLOSS (that also applies to Debian): more help is needed
in almost every area of almost every project.

>From the help Debian page:

https://www.debian.org/intro/help

You can help track, find and fix security issues within the packages in Debian.

https://security-tracker.debian.org/tracker/data/report
https://www.debian.org/security/audit/
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security

You can also help harden packages, repositories and images and other things.

https://wiki.debian.org/Hardening
https://wiki.debian.org/Hardening/RepoAndImages
https://wiki.debian.org/Hardening/Goals

Personally, I think running debsecan, looking at each item, pinging
bug reports and maintainers, doing stable updates and unstable NMUs,
pushing patches upstream etc would be a great help.

Also, debsecan itself could use a lot of help, the maintenance of it
and addition of new features currently falls on already-busy security
team folks.

In addition some more automation of ingestion of security info into
the security tracker would free up security team time that is
currently spent on manually updating the security-tracker data.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: Gaps in security coverage?

John Goerzen-3
On Tue, Nov 06 2018, Paul Wise wrote:

> On Mon, Nov 5, 2018 at 10:29 PM John Goerzen wrote:
>
>> Hi folks,
>
> FTR, in case you were trying to contact the Debian Security Team
> directly I suggest using [hidden email] or
> [hidden email] instead, debian-security is more of a general
> security discussion list than a Debian Security Team list.

Hi Paul,

Thanks - I did intend it to go here, understanding that difference; I
had no particular reason to make it more private.

[ snips ]

> Personally, I think running debsecan, looking at each item, pinging
> bug reports and maintainers, doing stable updates and unstable NMUs,
> pushing patches upstream etc would be a great help.

That is good advice, thanks.  I've been a DD for a long while, but it's
been awhile (years) since I've been involved in the security process and
wasn't quite sure what the flow was anymore.

> Also, debsecan itself could use a lot of help, the maintenance of it
> and addition of new features currently falls on already-busy security
> team folks.
>
> In addition some more automation of ingestion of security info into
> the security tracker would free up security team time that is
> currently spent on manually updating the security-tracker data.

What kind of automated sources are you talking about here?  Where do I
find the source that might be relevant?  I might be able to pitch in
here.

Thanks again,

John

Reply | Threaded
Open this post in threaded view
|

Re: Gaps in security coverage?

Paul Wise via nm
On Mon, 2018-11-05 at 20:52 -0600, John Goerzen wrote:

> That is good advice, thanks.  I've been a DD for a long while, but it's
> been awhile (years) since I've been involved in the security process and
> wasn't quite sure what the flow was anymore.

It is still mostly the same but the security team try to distribute
more work to the package maintainers especially for unstable.

> What kind of automated sources are you talking about here?  Where do I
> find the source that might be relevant?  I might be able to pitch in
> here.

Basically if you follow the manual commits to the security tracker repo
and think about how to automate each commit. The Mitre CVE data is
automatically imported but there are various sources of non-CVE data or
per-project data that has lower latency. I wrote down some possible
sources of data in check-external/sources.ini but never got around to
going further and the security team didn't seem to like the idea at all
so I've basically dropped it for now.

Also, a much more important task is restructuring the git repo so that
it doesn't cause responsiveness and resource usage issues with salsa.

--
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gaps in security coverage?

Holger Levsen-2
On Tue, Nov 06, 2018 at 02:42:59PM +0800, Paul Wise wrote:
> Also, a much more important task is restructuring the git repo so that
> it doesn't cause responsiveness and resource usage issues with salsa.

is there a bug or wiki page describing the issues/requirements for that and
what has been tried / the status?

(I just cloned the tracker yesterday and could see the problem 'live'..)


--
cheers,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gaps in security coverage?

Paul Wise via nm
On Tue, Nov 6, 2018 at 7:01 PM Holger Levsen wrote:

> is there a bug or wiki page describing the issues/requirements for that and
> what has been tried / the status?

Woops, I should have included that in the mail:

Bug#908678: security-tracker - Breaks salsa.d.o
https://bugs.debian.org/908678

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: Gaps in security coverage?

Holger Levsen-2
On Tue, Nov 06, 2018 at 07:08:20PM +0800, Paul Wise wrote:
> Bug#908678: security-tracker - Breaks salsa.d.o
 
thank you.


--
cheers,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gaps in security coverage?

Davide Prina
In reply to this post by Paul Wise via nm
On 06/11/2018 02:34, Paul Wise wrote:
> On Mon, Nov 5, 2018 at 10:29 PM John Goerzen wrote:

>> So I recently started running debsecan on one of my boxes.  It's a
>> fairly barebones server install, uses unattended-upgrades and is fully
>> up-to-date.  I expected a clean bill of health, but didn't get that.  I
>> got pages and pages and pages of output.  Some of it (especially kernel
>> related) I believe may be false positives, but not all.  Some of it
>> simply isn't patched yet.
>
> That has been the normal state of things since I started running
> debsecan many many years ago.

I'm not a security expert, but:
* security bugs are found daily
* security bugs are found also by people that don't work on the project
and upstream can consider these bugs in different way: lower security
bug; no security bug; no bug at all; ...
* a software without security bugs (or fewer) is not intricately more
secure than one with a lot of security bugs... the first one can be not
checked for security bugs...
* a security bug of a software that you are using can also not impact
you, that depend on how you use that software and the system/network on
which it is installed
* ...

Ciao
Davide

Reply | Threaded
Open this post in threaded view
|

Re: Gaps in security coverage?

Moritz Mühlenhoff-2
In reply to this post by John Goerzen-3
John Goerzen <[hidden email]> schrieb:

Hi John,

> So I recently started running debsecan on one of my boxes.

debsecan hasn't seen any feature work for about a decade and is
far too noisy to the point of being useless these days.

> It's a
> fairly barebones server install, uses unattended-upgrades and is fully
> up-to-date.  I expected a clean bill of health, but didn't get that.  I
> got pages and pages and pages of output.  Some of it (especially kernel
> related) I believe may be false positives, but not all.  Some of it
> simply isn't patched yet.

No distro backports everything, that would be outright insane :-)
As such there's no clean bill of health. We look at everything and if it's
important enough it gets fixed via security.debian.org and if not, via
point releases or not at all (there's plenty of cases where the tradeoff
of changing stable clearly balances towards not fixing stuff!)

E.g. your specific example of busybox/CVE-2011-5325 is fixed in the
upcoming stretch point release.

> Marked fixed in jessie

After introducing a regression (https://packages.qa.debian.org/b/busybox/news/20180803T045026Z.html)
which is a good example of the balance I mentioned above.

> 2) If so, what kinds of volunteering would be appreciated?

Sure! If you tell us what languages you feel comfortable to backport
security fixes in, I'm sure we can find you some tasks to work
on, best to reply to the team alias ([hidden email])
and can pick it up from there.

Thanks,
        Moritz

Reply | Threaded
Open this post in threaded view
|

Re: Gaps in security coverage?

Paul Wise via nm
On Wed, Nov 7, 2018 at 6:28 AM Moritz Mühlenhoff wrote:

> E.g. your specific example of busybox/CVE-2011-5325 is fixed in the
> upcoming stretch point release.

I noticed that this isn't reflected in the security tracker website
but it is in data/next-point-update.txt.

If anyone wants to get involved in enhancing the security tracker this
would probably be an ideal place to start.

--
bye,
pabs

https://wiki.debian.org/PaulWise