Secure testing team - Aug 2006 - Etch security bug hunting season opened

I started to raise severities of several security bugs. Unfortunately
many maintainers only care for these :-/

Please also file bugs for code duplication (embedding a copy) and
package duplication (needlessly introducing multiple versions in
a stable release), with at least severity important and keep me
posted. We really need to have Etch is a better security maintainability
than the current Sarge situation.

And please also have an eye for packages, which are too buggy to
release security-wise. Crap like oftpd, elog or mantis should never
have entered the archive at the first glance.

Cheers,
        Moritz

On Mon, Aug 14, 2006 at 09:12:54PM +0200, Moritz Muehlenhoff
wrote:
> I started to raise severities of several security bugs. Unfortunately
> many maintainers only care for these :-/
> 
> Please also file bugs for code duplication (embedding a copy) and
> package duplication (needlessly introducing multiple versions in
> a stable release), with at least severity important and keep me
> posted. We really need to have Etch is a better security maintainability
> than the current Sarge situation.
> 
Ok, I''ll try and go through the list and start filing/raising
priorities
of bugs as soon as I get a chance.
> And please also have an eye for packages, which are too buggy to
> release security-wise. Crap like oftpd, elog or mantis should never
> have entered the archive at the first glance.
> 
Is it worth subscribing to the wnpp list, and either commenting or
veto-ing packages?

Cheers,
Neil
-- 
<Tincho> ''Maybe you can try to find a nice hotel by shouting in
the Mexico DF
    streets "where could a gringo find a decent hotel in this dirty third
    world lame excuse for a country?". I''m sure the people will
rush to help
    you, as we south americans love to be called third world in a demeaning
way.''
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20060815/3b138aea/attachment.pgp

Neil McGovern wrote:
> > And please also have an eye for packages, which are too buggy to
> > release security-wise. Crap like oftpd, elog or mantis should never
> > have entered the archive at the first glance.
> 
> Is it worth subscribing to the wnpp list, and either commenting or
> veto-ing packages?
I''m trying to follow debian-devel and giving advice where possible.
Unfortunately most people just don''t care; e.g. I strongly recommended
to dump mantis completely. Still someone NMUed it for some non-DD
who''ll
most definitely in half a year lose interest like the two previous
maintainers and leave that junk in the archive with the Security Team
needing to support it for two more years. A package with only 35 installed
popcon users and _20_ vulnerabilities since January 2005. Or elog, a
_horribly_ insecure electronic web logbook written in C, which had every
basic security flaw you could ever imagine. The DSA fixed seven CVEs,
at the time of DSA it had six voting popcon users...

It''s packages like these which kill the fun out of preparing security
updates for Debian.

Cheers,
        Moritz

On Tue, Aug 15, 2006 at 11:58:04PM +0200, Moritz Muehlenhoff
wrote:
> Neil McGovern wrote:
> > > And please also have an eye for packages, which are too buggy to
> > > release security-wise. Crap like oftpd, elog or mantis should
never
> > > have entered the archive at the first glance.
> > 
> > Is it worth subscribing to the wnpp list, and either commenting or
> > veto-ing packages?
> 
> I''m trying to follow debian-devel and giving advice where
possible.
> Unfortunately most people just don''t care; e.g. I strongly
recommended
> to dump mantis completely. Still someone NMUed it for some non-DD
who''ll
> most definitely in half a year lose interest like the two previous
> maintainers and leave that junk in the archive with the Security Team
> needing to support it for two more years. A package with only 35 installed
> popcon users and _20_ vulnerabilities since January 2005. Or elog, a
> _horribly_ insecure electronic web logbook written in C, which had every
> basic security flaw you could ever imagine. The DSA fixed seven CVEs,
> at the time of DSA it had six voting popcon users...
> 
> It''s packages like these which kill the fun out of preparing
security
> updates for Debian.
What about filing bugs against ftp.debian.org requesting the removal
of these packages, and asking the release managers to block the etch
release on these bugs?

Or, perhaps file a grave bug against each package stating that it
cannot be security supported and ask the release team to drop it
from etch.

Probably best to just ask the release team (cc''d) for their preferred
approach.

-- 
dann frazier

On Tue, Aug 15, 2006 at 04:55:59PM -0600, dann frazier
wrote:
> On Tue, Aug 15, 2006 at 11:58:04PM +0200, Moritz Muehlenhoff wrote:
> > Neil McGovern wrote:
> > > > And please also have an eye for packages, which are too
buggy to
> > > > release security-wise. Crap like oftpd, elog or mantis
should never
> > > > have entered the archive at the first glance.
> > > Is it worth subscribing to the wnpp list, and either commenting
or
> > > veto-ing packages?
> > I''m trying to follow debian-devel and giving advice where
possible.
> > Unfortunately most people just don''t care; e.g. I strongly
recommended
> > to dump mantis completely. Still someone NMUed it for some non-DD
who''ll
> > most definitely in half a year lose interest like the two previous
> > maintainers and leave that junk in the archive with the Security Team
> > needing to support it for two more years. A package with only 35
installed
> > popcon users and _20_ vulnerabilities since January 2005. Or elog, a
> > _horribly_ insecure electronic web logbook written in C, which had
every
> > basic security flaw you could ever imagine. The DSA fixed seven CVEs,
> > at the time of DSA it had six voting popcon users...
> > It''s packages like these which kill the fun out of preparing
security
> > updates for Debian.
> What about filing bugs against ftp.debian.org requesting the removal
> of these packages, and asking the release managers to block the etch
> release on these bugs?
The bugs we block on are those marked in the BTS as RC severity with no
"etch-ignore" tag.  So if you want to ask us to block on them, set the
severity correctly. :)
> Or, perhaps file a grave bug against each package stating that it
> cannot be security supported and ask the release team to drop it
> from etch.
Should be serious rather than grave, but yes -- the bugs should be filed
against the unreleasable packages, independent of whether you request
removal from the archive.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

dann frazier <dannf@dannf.org> writes:
> On Tue, Aug 15, 2006 at 11:58:04PM +0200, Moritz Muehlenhoff wrote:
>> I''m trying to follow debian-devel and giving advice where
possible.
>> Unfortunately most people just don''t care; e.g. I strongly
recommended
>> to dump mantis completely. Still someone NMUed it for some non-DD
who''ll
>> most definitely in half a year lose interest like the two previous
>> maintainers and leave that junk in the archive with the Security Team
>> needing to support it for two more years. A package with only 35
installed
>> popcon users and _20_ vulnerabilities since January 2005. Or elog, a
>> _horribly_ insecure electronic web logbook written in C, which had
every
>> basic security flaw you could ever imagine. The DSA fixed seven CVEs,
>> at the time of DSA it had six voting popcon users...
>> 
>> It''s packages like these which kill the fun out of preparing
security
>> updates for Debian.
>
> What about filing bugs against ftp.debian.org requesting the removal
> of these packages, and asking the release managers to block the etch
> release on these bugs?
>
> Or, perhaps file a grave bug against each package stating that it
> cannot be security supported and ask the release team to drop it
> from etch.
>
> Probably best to just ask the release team (cc''d) for their
preferred
> approach.
Could we quantify that somewhat? Is one security bug enough? Are 10?
Do we have a delegate that could audit and veto a package already
other than the release team? Is that the domain of QA or security?

Maybe any new package (one not in stable already) that has a security
bug could be automatically blocked from the next stable release until
a source audit by some team (security? qa?) is done? Doing this for
every new package is probably too much to ask timewise but for any
package known to have one exploit already that seems prudent.

MfG
        Goswin

* Steve Langasek [Tue, 15 Aug 2006 16:21:57 -0700]:
> > Or, perhaps file a grave bug against each package stating that it
> > cannot be security supported and ask the release team to drop it
> > from etch.
> Should be serious rather than grave, but yes -- the bugs should be filed
> against the unreleasable packages, independent of whether you request
> removal from the archive.
Please sign the mail and mention it is an official request from the
Security Team, IMHO, as to make it clear nobody should be closing it
without talking to the Security Team first.

In any case, if that sounds a bit fragile as to ensure the packages
don''t ship in Etch, I''d be willing to maintain a list of
packages
blocked by the Security Team in one of the hints file.

Cheers,

-- 
Adeodato Sim?                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
                                      Listening to: Eric Clapton - Layla

On Wed, Aug 16, 2006 at 05:07:31AM +0200, Goswin von Brederlow
wrote:
> Could we quantify that somewhat? Is one security bug enough? Are 10?
> Do we have a delegate that could audit and veto a package already
> other than the release team? Is that the domain of QA or security?
> 
> Maybe any new package (one not in stable already) that has a security
> bug could be automatically blocked from the next stable release until
> a source audit by some team (security? qa?) is done? Doing this for
> every new package is probably too much to ask timewise but for any
> package known to have one exploit already that seems prudent.
imo, that is a separate, more proactive problem to solve - and for
that, metrics will probably need to be created, used, reassessed, etc.

But for now (i.e., for etch), I would think it sufficient for the
security team to agree that they cannot sanely security support a
package. I don''t think we need a well established process for this, at
least anything more than consensus within the security team.

Filing the bug means that this is public knowledge, and gives
developers a chance to volunteer to assist the security team for these
difficult packages. I''d suggest a mail to d-d-a by the security/release
teams that announce the first set of packages, so developers aren''t
surprised when their favorite package drops.

-- 
dann frazier

On Wed, Aug 16, 2006 at 05:07:31AM +0200, Goswin von Brederlow
wrote:
> > Probably best to just ask the release team (cc''d) for their
preferred
> > approach.
> 
> Could we quantify that somewhat? Is one security bug enough? Are 10?
There''s no way to quantify that as security bugs are linearly dependant
on
lines of code [1]
> Do we have a delegate that could audit and veto a package already
> other than the release team? Is that the domain of QA or security?
That''s currently the domain of the BTS. Anyone could publish sufficient
security (RC bugs) in a vulnerable package that it would make it impossible
for it to be released. Of course that would only be possible if:

a) the package is full of bugs
b) someone did a full audit of it

Unfortunately, the Security Team does not get to decide what they support
security-wise. I talked with members of the Security Team about this in the
past and have talked about this publicly in two Debconfs, we will get to
a point where we will have to say "the Security Team only supports packages
in ''standard'' in the ''stable'' release, other
package sections are supported
in a ''best effort'' basis". 

That''s not really much of an issue, mind you, it is the same security
treatment provide to Fedora Core "extras" or OpenBSD, FreeBSD or
NetBSD
"ports". And, by the way, is more or less what is happening know since
package priorities set the priorities for attention of the Security Team when
they have to rush a DSA.
> Maybe any new package (one not in stable already) that has a security
> bug could be automatically blocked from the next stable release until
> a source audit by some team (security? qa?) is done? Doing this for
> every new package is probably too much to ask timewise but for any
> package known to have one exploit already that seems prudent.
There are different types of security bugs, some are stupid and
non-consequential, others are just as stupid and have dire consequences. Not
all security bugs are equal [2]. If you are going to rule out packages that
someone found a security bug in, I can assure you [3] that we have a high
number of packages with security bugs nobody has yet ever noticed. What would
you do?  Have the security (or audit) team have veto powers over all the
archive?

You are using an "innocent until proven guilty" line of thought, I
would
rather go further and imposse an have "guilty until proven innocent"
line of
though for packages that:

a) install a tool that root will run (i.e. /sbin/ or /usr/sbin) or runs
   with "higher-than-user" privileges (i.e. setuid/setgid)
b) installs a daemon (more so if it''s a network service) or gets run at
   runlevel switching 
c) install a cron task (or other automatically-run task)
d) receives data from the network (i.e. a network client)

However that might mean putting a *large* number of packages on hold until
someone has time to complete a security audit, and the resources of the Audit
Team are scarce.

Just my 2c,

Javier


[1] Based on empiric test published in scientific (i.e. IEEE) journals, but
you know the line "lies, damn lines.."

[2] CVSS helps getting them rated, however, http://www.first.org/cvss/

[3] Based on the latest run I made tring to find local security bugs (i.e.
temporary race conditions) working for the Audit Team.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20060816/e20f9a56/attachment.pgp

Javier Fern?ndez-Sanguino Pe?a <jfs@computer.org> writes:
> On Wed, Aug 16, 2006 at 05:07:31AM +0200, Goswin von Brederlow wrote:
>> > Probably best to just ask the release team (cc''d) for
their preferred
>> > approach.
>> 
>> Could we quantify that somewhat? Is one security bug enough? Are 10?
>
> There''s no way to quantify that as security bugs are linearly
dependant on
> lines of code [1]
>
>> Do we have a delegate that could audit and veto a package already
>> other than the release team? Is that the domain of QA or security?
>
> That''s currently the domain of the BTS. Anyone could publish
sufficient
> security (RC bugs) in a vulnerable package that it would make it impossible
> for it to be released. Of course that would only be possible if:
That wasn''t what I suggested (below). The BTS only stops a package
from being released due to known bugs. I ment that if a package has
such a bug that it gets still blocked from the next release even if
the bug is fixed without an audit of the code by e.g. the security
team.

This is ment to prevent one security bug after another to show up on a
weekly basis in a package in stable. I''m assuming that more people
will use it once it hits stable and then more bugs get found. Waiting
for another release also means new project have more time to mature.
> a) the package is full of bugs
The save thing to do is to assume it is full of bugs. Where there is
one there will be more, unless
> b) someone did a full audit of it
someone did this to see if it was just a fluke.
> Unfortunately, the Security Team does not get to decide what they support
> security-wise. I talked with members of the Security Team about this in the
> past and have talked about this publicly in two Debconfs, we will get to
> a point where we will have to say "the Security Team only supports
packages
> in ''standard'' in the ''stable'' release,
other package sections are supported
> in a ''best effort'' basis". 
>
> That''s not really much of an issue, mind you, it is the same
security
> treatment provide to Fedora Core "extras" or OpenBSD, FreeBSD or
NetBSD
> "ports". And, by the way, is more or less what is happening know
since
> package priorities set the priorities for attention of the Security Team
when
> they have to rush a DSA.
I would rather have less packages in stable so that the security team
does have enough resources. If a package is in reasonable danger of
having security bugs then it should not get into stable.
>> Maybe any new package (one not in stable already) that has a security
>> bug could be automatically blocked from the next stable release until
>> a source audit by some team (security? qa?) is done? Doing this for
>> every new package is probably too much to ask timewise but for any
>> package known to have one exploit already that seems prudent.
>
> There are different types of security bugs, some are stupid and
> non-consequential, others are just as stupid and have dire consequences.
Not
> all security bugs are equal [2]. If you are going to rule out packages that
> someone found a security bug in, I can assure you [3] that we have a high
> number of packages with security bugs nobody has yet ever noticed. What
would
> you do?  Have the security (or audit) team have veto powers over all the
> archive?
>
> You are using an "innocent until proven guilty" line of thought,
I would
> rather go further and imposse an have "guilty until proven
innocent" line of
> though for packages that:
More a blak&white world view. If it has at least one security bug then
it is black and must be audited.
> a) install a tool that root will run (i.e. /sbin/ or /usr/sbin) or runs
>    with "higher-than-user" privileges (i.e. setuid/setgid)
> b) installs a daemon (more so if it''s a network service) or gets
run at
>    runlevel switching 
> c) install a cron task (or other automatically-run task)
> d) receives data from the network (i.e. a network client)
Some thread assessment and the kind of security bug detected should
have influence on the decision, sure.

I think any new package with your 4 cases should be audited if that can
be done. I fear though that there isn''t enough manpower for that.
> However that might mean putting a *large* number of packages on hold until
> someone has time to complete a security audit, and the resources of the
Audit
> Team are scarce.
Exactly. Hence only do that for suspect packages as defnied by having
(had) a known security bug.
> Just my 2c,
>
> Javier
>
>
> [1] Based on empiric test published in scientific (i.e. IEEE) journals, but
> you know the line "lies, damn lines.."
>
> [2] CVSS helps getting them rated, however, http://www.first.org/cvss/
>
> [3] Based on the latest run I made tring to find local security bugs (i.e.
> temporary race conditions) working for the Audit Team.
MfG
        Goswin

On Thu, Aug 17, 2006 at 02:25:58AM +0200, Goswin von Brederlow
wrote:
> > That''s currently the domain of the BTS. Anyone could publish
sufficient
> > security (RC bugs) in a vulnerable package that it would make it
impossible
> > for it to be released. Of course that would only be possible if:
> 
> That wasn''t what I suggested (below). The BTS only stops a package
> from being released due to known bugs. I ment that if a package has
> such a bug that it gets still blocked from the next release even if
> the bug is fixed without an audit of the code by e.g. the security
> team.
I know that is not what you suggested, you asked what we currently do, and
what we currently do (audit and security team) is bug through the BTS AFAIK
and that''s what might prevent a bug.
> I would rather have less packages in stable so that the security team
> does have enough resources. If a package is in reasonable danger of
> having security bugs then it should not get into stable.
The problem here is determine "reasonable danger" I would say that
there are
more chances of unused / unaudited packages having "reasonable danger"
than a
package which is widely used and reviewed (even if many bugs have been
found). But that''s just my opinion.

Regards

Javier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20060817/39867aea/attachment.pgp

dann frazier wrote:
> On Wed, Aug 16, 2006 at 05:07:31AM +0200, Goswin von Brederlow wrote:
> > Could we quantify that somewhat? Is one security bug enough? Are 10?
> > Do we have a delegate that could audit and veto a package already
> > other than the release team? Is that the domain of QA or security?
> > 
> > Maybe any new package (one not in stable already) that has a security
> > bug could be automatically blocked from the next stable release until
> > a source audit by some team (security? qa?) is done? Doing this for
> > every new package is probably too much to ask timewise but for any
> > package known to have one exploit already that seems prudent.
> 
> imo, that is a separate, more proactive problem to solve - and for
> that, metrics will probably need to be created, used, reassessed, etc.
Through the Debian security tracker database we have a solid history of
security problems ranging back to 2004, which gives some useful metrics.
 
> But for now (i.e., for etch), I would think it sufficient for the
> security team to agree that they cannot sanely security support a
> package. I don''t think we need a well established process for
this, at
> least anything more than consensus within the security team.
I''ll file a bug against mantis.

Cheers,
        Moritz