Secure testing team - Mar 2006 - Security update for fuse

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi folks,

There''s a serious vulnerability in fuse; see bug #311634.
This does not yet have a CVE ref, but I found
http://secunia.com/advisories/15561/

I''ve prepared updates for both sid and sarge:
http://people.debian.org/~rleigh/fuse/sarge-security/
http://people.debian.org/~rleigh/fuse/sid/

Due to the release being so close, I haven''t uploaded either of these.
I''m not a security expert, so thought you might be better reviewing
them first, in case I''ve missed something.  I was also not sure
whether to use stable-security or testing-security, or if the version
for sid needed uploading first.


Regards,
Roger

- -- 
Roger Leigh
                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFCoYbIVcFcaSW/uEgRAiwvAJ9eoQz3Q+6mpFz8J6KGB1i4NV2wbACdFEzp
kIfJxzzr3Eh+vpMl2cO8M64=LZ9E
-----END PGP SIGNATURE-----

Roger Leigh wrote:
> There''s a serious vulnerability in fuse; see bug #311634.
> This does not yet have a CVE ref, but I found
> http://secunia.com/advisories/15561/
> 
> I''ve prepared updates for both sid and sarge:
> http://people.debian.org/~rleigh/fuse/sarge-security/
> 
> Due to the release being so close, I haven''t uploaded either of
these.
> I''m not a security expert, so thought you might be better
reviewing
> them first, in case I''ve missed something. 
FWIW, the patch is identical to the one posted to linux-kernel by
Miklos Szeredi, the official fuse kernel maintainer, so it seems
safe.

Cheers,
        Moritz

Le mercredi 06/08/05 Micah Anderson <micah@debian.org> a ?crit
:
> > I think the biggest misnomer with testing-security is its name. Think
of it
> > as sarge-security. This is why it was a blocker for the release - we
needed
> 
> I disagree. The original intention of the secure-testing-team was not
> to be a temporary organization that went away when sarge released.
> Before sarge released it could have been viewed as
"sarge-security" as
> sarge was "testing", but now that release has happened,
> "sarge-security" is in the hands of the "Secutiry
Team".
> 
> Now that sarge has released, this group is going to continue on in the
> vein that Joey Hess outlined in the section of his email[1] titled
> "Work after sarge''s release". Most notably, "to
start regular security
> updates for testing". Testing meaning testing, not sarge. It *was*
> sarge a few days ago, but it is no longer.
I think Andrew talk about the testing-security *queue*, not the team! :-)

Regards
-- 
Djoum? SALVETTI
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050608/170fe309/attachment.pgp

Le mercredi 06/15/05 Moritz Muehlenhoff <jmm@inutil.org> a ?crit
:
> I''m thinking of some "minor" tag for uncritical
tempraces, packages
> not vulnerable in the Debian package, and generally obscure issues.
What do you think about two kinds of tags?

One about severity or "criticality" like what we can find on secunia :

http://secunia.com/about_secunia_advisories/

and another one about type of vulnerabilities, the goal would be to
autobuilt a page like this :

https://wiki.ubuntu.com//USNAnalysis
> Additionally I''d already started to write a tool that provides a
system specific
> overview of vulnerabilities affecting a system (generated from CAN/list),
which
> should improve the state of testing''s security from a
user''s perspective,
> as well, but I''m currently busy with diploma stuff (I hope to get
around to it
> during the next weeks).
That would be very nice. :-)

-- 
Djoum? SALVETTI

On Wed, 08 Jun 2005, Andrew Pollock wrote:
> On Tue, Jun 07, 2005 at 10:39:41PM -0500, Micah Anderson wrote:
> > On Mon, 06 Jun 2005, Joey Hess wrote:
> > 
> > > Micah Anderson wrote:
> > > > Additionally, should testing-security provide security
notices (such
> > > > as DSA''s)? If so, how would this work?
> > > 
> > > I believe that we should do this, but have been waiting for the
release
> > > of sarge for it, since I''m not sure if we can do
something to get the
> > > testing-security (and/or testing-proposed-updates) queues to
remain
> > > functional after sarge is released, to get packages built against
etch.
> > 
> > It seems as if testing-security has been renamed to stable-security,
> > so this queue is out. Also, from what I understand britney
hasn''t been
> > reenabled yet for etch, and since the release is so recent, this is
> > probably not people''s highest priority. Maybe I''m a
sarge
> > party-pooper, but I would rather not find out a month from now that
> > these queues were destroyed because nobody thought they were useful to
> > keep around anymore, but from what I''ve been able to find out
-- there
> > simply aren''t any.
> 
> I think the biggest misnomer with testing-security is its name. Think of it
> as sarge-security. This is why it was a blocker for the release - we needed
I disagree. The original intention of the secure-testing-team was not
to be a temporary organization that went away when sarge released.
Before sarge released it could have been viewed as "sarge-security" as
sarge was "testing", but now that release has happened,
"sarge-security" is in the hands of the "Secutiry Team". 

Now that sarge has released, this group is going to continue on in the
vein that Joey Hess outlined in the section of his email[1] titled
"Work after sarge''s release". Most notably, "to start
regular security
updates for testing". Testing meaning testing, not sarge. It *was*
sarge a few days ago, but it is no longer.

1. http://lists.debian.org/debian-security/2004/10/msg00166.html
-------------- 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/20050608/da3f3295/attachment.pgp

Moritz Muehlenhoff wrote:
> Don''t underestimate the time required for providing a security
update.
> So, first we should find criteria for issues that should be handled through
> secure-testing, ideally in a form suitable for data/CAN/list. Several
> of the issues right now listed in newraff.d.o/t-s.h do not really deserve
> urgent action (and they begin making the overview a bit crowded).
I''m
> thinking of some "minor" tag for uncritical tempraces, packages
not
> vulnerable in the Debian package, and generally obscure issues.
Yes, I agree we need something like that, perhaps to color code the
list. Picking out remote shell exploits or the like (very high priority
stuff) would also be handy.
> Fixes built against testing are definitely needed, e.g. the fix included
> in latest Firefox wouldn''t be showing in Etch during the next 2-3
months
> otherwise. IMO the best solution for this would be fixes uploaded by the
> maintainers themselves, with an option to pass the ball to the
secure-testing
> team if they''re not interested/don''t care/don''t
know whatever (which is a
> not too small margin). Ideally there''d be a simple way in which a
maintainer
> could denote his intentions towards t-s handling in an easy way. Judging
from
> experiences with reaction times towards security related bug reports
reaction
> times vary from "fixed within < 1 hr" (e.g. the leafnode
maintainer) up to
> "no maintainer reaction for months, even with included patch and
pending
> stable release". The complexity of the vulnerable packages is not to
be
> forgotten, e.g. the proposed gdb fix looked simple and correct, until Dan
> Jacobowitz pointed out that there''s a code path that does not
initialize
> cwdbuf, which isn''t really obvious if you are not familiar with
the gdb
> sources.
Right, this is always an interesting line to tread when doing NMUs,
especially now that sarge is released and people may not be expecting
zero day NMUs.
> I''d suggest to start an experimental service for i386 for now, if
it works
> out it can be extended.
Works for me. I''m araid that Neuro is probably going to have to
prioritise getting the security system working again for stable over us,
since that is apparently not working at all right now. Sigh.

Anyway, an experimental apt repo for this is easy enough to set up. I
wonder where we should mail the announcements? We might also want to do
announcements for holes that get fixed in testing via regular testing
propigation.
> DTSA seem like a good idea. For the sake of consistency it seems like a
good
> idea to issue them from the s-t team. When doing so we should talk to the
MITRE
> people whether DTSAs would qualify as CVE data sources. There are currently
> 55 vulnerabilities tracked by us that haven''t ever received a CVE
assignment,
> some of which may as well be in other vendor''s products. (MITRE
may be only a
> dictionary, but in practice it''s more). 
Couldn''t we just get a pipe to mitre and submit those? I assume we have
other data sources for them that mitre could point to, such as the
debian BTS.
> Oh, and we should keep in mind the
> upcoming naming change in MITRE''s processes (I think it starts in
august?)
Yes, it''s in august and I won''t be suprised if some scripts
break.
> Additionally I''d already started to write a tool that provides a
system specific
> overview of vulnerabilities affecting a system (generated from CAN/list)
That''s a great idea!

-- 
see shy jo
-------------- 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/20050615/f91ca9f2/attachment.pgp

Djoume SALVETTI wrote:
> > I''m thinking of some "minor" tag for uncritical
tempraces, packages
> > not vulnerable in the Debian package, and generally obscure issues.
> 
> What do you think about two kinds of tags?
> 
> One about severity or "criticality" like what we can find on
secunia :
Yes, but we should keep that set of issues small, the Secunia classifications
are too extensive. We won''t have the resources to track for each
vulnerability
whether it''s actively exploited, as Secunia does seem to do.

There are too many unknown variable''s on the side of the host running
the
vulnerable code. The best way to address severity of more important issues is to
prioritize fixes for these issues in a faster manner.

So maybe we should start with a simple differentiation between
vulnerabilities and minor issues, which may not be optimal from a security
perspective. e.g.:

- issues only exploitable under rare circumstances/stupid setups (e.g. cpio,
  coreutils)
- issues affecting code not shipped in the binary packages (e.g. krb5/278271)
- DoS against applications without security implications (e.g. lynx), except
  that availability has been attacked
- others?
> http://secunia.com/about_secunia_advisories/
> 
> and another one about type of vulnerabilities, the goal would be to
> autobuilt a page like this :
IMO DSAs contain a useful set of issue classifications we should adopt.

Cheers,
        Moritz

Micah Anderson wrote:
> Additionally, should testing-security provide security notices (such
> as DSA''s)? If so, how would this work?
I believe that we should do this, but have been waiting for the release
of sarge for it, since I''m not sure if we can do something to get the
testing-security (and/or testing-proposed-updates) queues to remain
functional after sarge is released, to get packages built against etch.

If those queues do function that way, then we should be able to do full
DTSAs for all architectures using them. If not, we will still be subject
to other issues that block security fixes from testing, or will have to
set up our own queues and autobuilder network (or piggyback on the
experimental autobuild network). Doable, but kinda a pain.

There''s also the issue of whether we can get upload access to
security.debian.org, and of who can actually upload packages and sign
and email the DTSA messages (probably only the official DD''s on the
team).

Also there''s the issue of what mailing list to use, but that is easily
solved of course.

-- 
see shy jo
-------------- 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/20050606/4f978c68/attachment.pgp

On Sat, Jun 04, 2005 at 12:26:15PM +0100, Roger Leigh
wrote:
> >> There''s a serious vulnerability in fuse; see bug #311634.
> >> This does not yet have a CVE ref, but I found
> >> http://secunia.com/advisories/15561/
> >> 
> >> I''ve prepared updates for both sid and sarge:
> >> http://people.debian.org/~rleigh/fuse/sarge-security/
> >> 
> >> Due to the release being so close, I haven''t uploaded
either of these.
> >> I''m not a security expert, so thought you might be better
reviewing
> >> them first, in case I''ve missed something. 
> >
> > FWIW, the patch is identical to the one posted to linux-kernel by
> > Miklos Szeredi, the official fuse kernel maintainer, so it seems
> > safe.
> 
> Thanks.  Just to double check, which distribution do I put in the
> changelog, and which upload queue do I use?  aba said to use
> sarge-security, but elsewhere I read to use testing-security, so
I''d
> just like to be 100% sure.
I also have prepared fixed packages and I also not sure where to upload
them. I wrote to security team two days ago about it and I haven''t
received
any answer yet.

regards
fEnIo

-- 
  ,''''`.  Bartosz Fenski | mailto:fenio@debian.org |
pgp:0x13fefc40 | irc:fEnIo
 : :'' :       32-050 Skawina - Glowackiego 3/15 - w. malopolskie -
Poland
 `. `''           phone:+48602383548 | proud Debian maintainer and user
   `-          http://skawina.eu.org | jid:fenio@jabber.org | rlu:172001
-------------- 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/20050604/41a3bf1b/attachment.pgp

If it should go via security.debian.org, I''ll just fetch the source
package, strip off the unstable part, rebuild as 2.2.1-4sarge1 and
take care of it.

Regards,

	Joey

-- 
Those who don''t understand Unix are condemned to reinvent it, poorly.

On Sat, Jun 04, 2005 at 06:02:00PM +0200, Martin Schulze
wrote:
> If it should go via security.debian.org, I''ll just fetch the
source
> package, strip off the unstable part, rebuild as 2.2.1-4sarge1 and
> take care of it.
I''ll be thankful if you could take care of it, cause I''m
getting more and
more confused about which queue should I use ;)

So please upload it yourself if you can.

regards
fEnIo

-- 
  ,''''`.  Bartosz Fenski | mailto:fenio@debian.org |
pgp:0x13fefc40 | irc:fEnIo
 : :'' :       32-050 Skawina - Glowackiego 3/15 - w. malopolskie -
Poland
 `. `''           phone:+48602383548 | proud Debian maintainer and user
   `-          http://skawina.eu.org | jid:fenio@jabber.org | rlu:172001
-------------- 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/20050604/cdc6866b/attachment.pgp

Bartosz Fenski aka fEnIo wrote:
> On Sat, Jun 04, 2005 at 06:02:00PM +0200, Martin Schulze wrote:
> > If it should go via security.debian.org, I''ll just fetch the
source
> > package, strip off the unstable part, rebuild as 2.2.1-4sarge1 and
> > take care of it.
> 
> I''ll be thankful if you could take care of it, cause I''m
getting more and
> more confused about which queue should I use ;)
> 
> So please upload it yourself if you can.
Ok, will do.  Asked for a CVE id first, will provide it to you as well.
More instructions will follow.

Regards,

	Joey

-- 
Those who don''t understand Unix are condemned to reinvent it, poorly.

Please always Cc to me when replying to me on the lists.

On Mon, Jun 06, 2005 at 11:20:02PM +0200, Martin Schulze
wrote:
> > Ok, will do.  Asked for a CVE id first, will provide it to you as
well.
> > More instructions will follow.
> 
> This is CAN-2005-1858.
> 
> Please
>  . update the package in sid
Done.
>  . mention the CVE id from the subject in the changelog
Can''t be done, cause I uploaded it yesterday and I simply
didn''t know CVE id.
>  . tell me the version number of the fixed package
2.3.0-1
>  . use priority=high
Done.
>  . please forward it upstream
Upstream knows it already and that was the reason to release 2.3.0 version.
 
> I''ll take care of sarge, once security.debian.org is unbroken
again.
Many thanks.

regards
fEnIo

-- 
  ,''''`.  Bartosz Fenski | mailto:fenio@debian.org |
pgp:0x13fefc40 | irc:fEnIo
 : :'' :       32-050 Skawina - Glowackiego 3/15 - w. malopolskie -
Poland
 `. `''           phone:+48602383548 | proud Debian maintainer and user
   `-          http://skawina.eu.org | jid:fenio@jabber.org | rlu:172001
-------------- 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/20050606/389fdfe3/attachment.pgp

Joey Hess wrote:
> > Additionally, should testing-security provide security notices (such
> > as DSA''s)? If so, how would this work?
> 
> I believe that we should do this, but have been waiting for the release
> of sarge for it, since I''m not sure if we can do something to get
the
> testing-security (and/or testing-proposed-updates) queues to remain
> functional after sarge is released, to get packages built against etch.
> 
> If those queues do function that way, then we should be able to do full
> DTSAs for all architectures using them. If not, we will still be subject
> to other issues that block security fixes from testing, or will have to
> set up our own queues and autobuilder network (or piggyback on the
> experimental autobuild network). Doable, but kinda a pain.
> 
> There''s also the issue of whether we can get upload access to
> security.debian.org, and of who can actually upload packages and sign
> and email the DTSA messages (probably only the official DD''s on
the
> team).
Don''t underestimate the time required for providing a security update.
So, first we should find criteria for issues that should be handled through
secure-testing, ideally in a form suitable for data/CAN/list. Several
of the issues right now listed in newraff.d.o/t-s.h do not really deserve
urgent action (and they begin making the overview a bit crowded). I''m
thinking of some "minor" tag for uncritical tempraces, packages not
vulnerable in the Debian package, and generally obscure issues.

Fixes built against testing are definitely needed, e.g. the fix included
in latest Firefox wouldn''t be showing in Etch during the next 2-3
months
otherwise. IMO the best solution for this would be fixes uploaded by the
maintainers themselves, with an option to pass the ball to the secure-testing
team if they''re not interested/don''t care/don''t know
whatever (which is a
not too small margin). Ideally there''d be a simple way in which a
maintainer
could denote his intentions towards t-s handling in an easy way. Judging from
experiences with reaction times towards security related bug reports reaction
times vary from "fixed within < 1 hr" (e.g. the leafnode
maintainer) up to
"no maintainer reaction for months, even with included patch and pending
stable release". The complexity of the vulnerable packages is not to be
forgotten, e.g. the proposed gdb fix looked simple and correct, until Dan
Jacobowitz pointed out that there''s a code path that does not
initialize
cwdbuf, which isn''t really obvious if you are not familiar with the gdb
sources.

I''d suggest to start an experimental service for i386 for now, if it
works
out it can be extended.
For s-t purposes the requirements for arch synchronity should be lowered,
it doesn''t make sense to withhold security fixes because of slow/buggy
archs. This is needed for a stable release, but for a volatile target like
testing it doesn''t make much sense.

DTSA seem like a good idea. For the sake of consistency it seems like a good
idea to issue them from the s-t team. When doing so we should talk to the MITRE
people whether DTSAs would qualify as CVE data sources. There are currently
55 vulnerabilities tracked by us that haven''t ever received a CVE
assignment,
some of which may as well be in other vendor''s products. (MITRE may be
only a
dictionary, but in practice it''s more). Oh, and we should keep in mind
the
upcoming naming change in MITRE''s processes (I think it starts in
august?)

Additionally I''d already started to write a tool that provides a system
specific
overview of vulnerabilities affecting a system (generated from CAN/list), which
should improve the state of testing''s security from a user''s
perspective,
as well, but I''m currently busy with diploma stuff (I hope to get
around to it
during the next weeks).

Cheers,
        Moritz

Bartosz Fenski aka fEnIo wrote:
> >  . please forward it upstream
> 
> Upstream knows it already and that was the reason to release 2.3.0 version.
But upstream probably doesn''t know about the CVE id.

CAN-2005-nnnn a unique identifier for a vulnerability in a software
package.  The database behind this is maintained at MITRE''s Common
Vulnerabilities and Exposures project <http://cve.mitre.org/cve/>.
Details for such an id are available after a few days of quarantaine
at <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-nnnn>.

Many vendors (both propriatery and Free Software) participate in this
database and assign the id to vulnerability reports or updates they
produce.  These IDs help us security people generally for identifying
if a given package is fixed or if a given update fixes which problem.
Please mention this ID in the changelog and/or project announcements.

Regards,

	Joey

-- 
No question is too silly to ask, but, of course, some are too silly
to answer.   -- Perl book

On Wed, Jun 08, 2005 at 12:11:29PM +0200, Ulf Harnhammar
wrote:
> On Wed, Jun 08, 2005 at 01:49:01PM +1000, Andrew Pollock wrote:
> > I think the biggest misnomer with testing-security is its name. Think
of it
> > as sarge-security. This is why it was a blocker for the release - we
needed
> > it for after sarge became stable. So what was testing-security just
got
> > promoted to stable-security when we released sarge. Arguably the
> > wood-security stuff should get recycled into etch-security, but I
think that
> > we provide oldstable security support for a bit, so we either need to
go
> > through the hassle of setting up etch-security now, or wait until
resources
> > are freed up from oldstable-security.
> 
> This testing security list was created recently, but Debian has released
many
> times before. How was this type of problem handled earlier? (Simultaneous
> upgrades for potato and slink, for instance.)
> 
It was a similar release blocker for woody IIRC. I can''t speak for
anything
prior to that. You''d need to read the mailing list archives.

regards

Andrew

On Tue, Jun 07, 2005 at 10:39:41PM -0500, Micah Anderson
wrote:
> On Mon, 06 Jun 2005, Joey Hess wrote:
> > Micah Anderson wrote:
> > > Additionally, should testing-security provide security notices
(such
> > > as DSA''s)? If so, how would this work?
> > I believe that we should do this, but have been waiting for the
release
> > of sarge for it, since I''m not sure if we can do something to
get the
> > testing-security (and/or testing-proposed-updates) queues to remain
> > functional after sarge is released, to get packages built against
etch.
> It seems as if testing-security has been renamed to stable-security,
> so this queue is out. Also, from what I understand britney hasn''t
been
> reenabled yet for etch, and since the release is so recent, this is
> probably not people''s highest priority. Maybe I''m a sarge
> party-pooper, but I would rather not find out a month from now that
> these queues were destroyed because nobody thought they were useful to
> keep around anymore, but from what I''ve been able to find out --
there
> simply aren''t any.
Well, I recall that there were precisely zero instances in which the
secure-testing team used the testing-security queue during sarge''s
preparation (related of course to the fact that only the security team has
access to those queues); so after all, why should this be a priority?  The
excellent work the secure-testing team has done during sarge''s
preparation
seems to have depended on the proper working of the testing-security queue
not at all.

Getting testing-security re-established for etch *is* a release team
concern, given that we basically delayed sarge''s release for 8 months
because of this single issue; so of course we want that to be addressed
sooner rather than later for this cycle.  But after three years of waiting,
I think it''s fair to give people at least a week or so to relax and
celebrate before worrying over etch, don''t you?

Anyway, yeah, there''s some additional setup that needs to happen before
etch
will have testing-security; it''s a little hard to have etch chroots
running
around before there''s an etch to build them against, for one thing.

-- 
Steve Langasek
postmodern programmer
-------------- 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/20050608/7a9be57f/attachment.pgp

On Wed, Jun 08, 2005 at 10:27:10AM -0500, Micah Anderson
wrote:
> On Wed, 08 Jun 2005, Andrew Pollock wrote:
> > 
> > I think the biggest misnomer with testing-security is its name. Think
of it
> > as sarge-security. This is why it was a blocker for the release - we
needed
> 
> I disagree. The original intention of the secure-testing-team was not
> to be a temporary organization that went away when sarge released.
> Before sarge released it could have been viewed as
"sarge-security" as
> sarge was "testing", but now that release has happened,
> "sarge-security" is in the hands of the "Secutiry
Team".
Don''t get me wrong, I''m talking about testing-security the
infrastructure,
not testing-security the team.
 
> Now that sarge has released, this group is going to continue on in the
> vein that Joey Hess outlined in the section of his email[1] titled
> "Work after sarge''s release". Most notably, "to
start regular security
> updates for testing". Testing meaning testing, not sarge. It *was*
> sarge a few days ago, but it is no longer.
> 
> 1. http://lists.debian.org/debian-security/2004/10/msg00166.html
Sure. So the first thing we need to be lobbying for is new security
infrastructure for testing. Whether the rest of the project decides this is
a priority remains to be seen though, right?

regards

Andrew

Micah Anderson wrote:
> It seems as if testing-security has been renamed to stable-security,
> so this queue is out.
FWIW, I''m talking with Ryan Murray about getting testing-security back.
> I''ve seen some documentation out there about how to setup an
> autobuilder, and I feel that I could set one up on my home machine if
> necessary, however an i386 box is probably not what is really needed
> in an autobuilder network, especially one with very little space
> available.
If we have to set up autobuilders, I can personally do it for about 7
architectures, if it came down to that. There are almost certianly
better ways though. :-)
> interest in getting into the buildd network and cant for some reason,
> these are often the experimental autobuilder folks. Leveraging this
> might make sense, although are there security issues that should be
> taken into consideration in picking autobuilders?
Not really, if they already feed the debian archive they are assumed to
be secure.
> > There''s also the issue of whether we can get upload access to
> > security.debian.org, and of who can actually upload packages and sign
> > and email the DTSA messages (probably only the official DD''s
on the
> > team).
> 
> I wonder if it makes sense to have a conversation with the security
> team about merging efforts/resources?
I''m all for that if we can find useful ways to do it..

-- 
see shy jo
-------------- 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/20050608/ec03ce56/attachment.pgp

Steve Langasek wrote:
> Well, I recall that there were precisely zero instances in which the
> secure-testing team used the testing-security queue during sarge''s
> preparation (related of course to the fact that only the security team has
> access to those queues); so after all, why should this be a priority?
I used the t-p-u queue multiple times for testing-security work. I
didn''t see a distinction between that queue and the testing-security
queue that would make me choose one over the other.

I''d be happy to have either for etch.
> excellent work the secure-testing team has done during sarge''s
preparation
> seems to have depended on the proper working of the testing-security queue
> not at all.
About 50% of all security holes in testing at any given time for the
past 6 months have been held up by issues that can be entirely worked
around by the t-s queue. Some of those issues can be avoided in other
ways, but having a t-s queue will allow us to be assured that we can
make security fixes availale for testing in the timeframe we choose.

-- 
see shy jo
-------------- 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/20050608/95819a6f/attachment.pgp

On Mon, 06 Jun 2005, Joey Hess wrote:
> Micah Anderson wrote:
> > Additionally, should testing-security provide security notices (such
> > as DSA''s)? If so, how would this work?
> 
> I believe that we should do this, but have been waiting for the release
> of sarge for it, since I''m not sure if we can do something to get
the
> testing-security (and/or testing-proposed-updates) queues to remain
> functional after sarge is released, to get packages built against etch.
It seems as if testing-security has been renamed to stable-security,
so this queue is out. Also, from what I understand britney hasn''t been
reenabled yet for etch, and since the release is so recent, this is
probably not people''s highest priority. Maybe I''m a sarge
party-pooper, but I would rather not find out a month from now that
these queues were destroyed because nobody thought they were useful to
keep around anymore, but from what I''ve been able to find out -- there
simply aren''t any.
> If those queues do function that way, then we should be able to do full
> DTSAs for all architectures using them. If not, we will still be subject
> to other issues that block security fixes from testing, or will have to
> set up our own queues and autobuilder network (or piggyback on the
> experimental autobuild network). Doable, but kinda a pain.
Since it seems like not, we are stuck in the harder spot and need to
pick one of these solutions it seems. Unless there is something else
that can be done to try and get one of those queues functional.

I''ve seen some documentation out there about how to setup an
autobuilder, and I feel that I could set one up on my home machine if
necessary, however an i386 box is probably not what is really needed
in an autobuilder network, especially one with very little space
available. However, I have seen a number of people who have expressed
interest in getting into the buildd network and cant for some reason,
these are often the experimental autobuilder folks. Leveraging this
might make sense, although are there security issues that should be
taken into consideration in picking autobuilders?
> There''s also the issue of whether we can get upload access to
> security.debian.org, and of who can actually upload packages and sign
> and email the DTSA messages (probably only the official DD''s on
the
> team).
I wonder if it makes sense to have a conversation with the security
team about merging efforts/resources?

micah
-------------- 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/20050607/a9177857/attachment.pgp

Micah Anderson wrote:
> testing-proposed-updates, supposedly there was some testing-security
> infrastructure that was holding up sarge, but we aren''t really
using
> it.
It has been used already and it''s being used by the security team.

Regards,

	Joey

-- 
Those who don''t understand Unix are condemned to reinvent it, poorly.

On Wed, 15 Jun 2005, Joey Hess wrote:
> > I''d suggest to start an experimental service for i386 for
now, if it works
> > out it can be extended.
> 
> Works for me. I''m araid that Neuro is probably going to have to
> prioritise getting the security system working again for stable over us,
> since that is apparently not working at all right now. Sigh.
> 
> Anyway, an experimental apt repo for this is easy enough to set up. I
> wonder where we should mail the announcements? We might also want to do
> announcements for holes that get fixed in testing via regular testing
> propigation.
I''ve updated the announcement email with the statistics and additional
information (find it below for review). However, I am wondering if we
should wait to send this out until we have this repository and a place
to mail the announcements, so we can communicate those?

Here is the updated announcement:

. Secure-Testing Accomplishments
. Statistics
. Etching our way towards testing security

Now that Sarge has released, the testing-security team is shifting
gears from our pre-release activities to our post-release work. What
follows is a report on our activities thus far, and our future plans.

Secure-Testing Accomplishments pre-Sarge
------------------------------------------

Testing-security performed a massive security review of *all* CAN and
CVE entries announced since the release of woody, performed a scan of
every DSA since woody''s release and checked all DSAs to see if fixes
for those security holes had reached testing. This process uncomvered
a few security holes that hadn''t been fixed in testing for a year or
more, although these were exceptions.

We setup an automatic SVN repository updater of the CAN list, bringing
in fresh CANs/CVEs from Mitre. This allowed us to become alert of
CANs/CVEs that were released as soon as possible so that we could
check them. We also setup a webpage that is automatically updated
based on the status of this SVN repository.

Statistics
----------

   . As of a few days ago we have processed a total of 6,536 items
   . Out of these, 1,226 items affected Debian at some point
	(in 498 distinct packages and taking 918 package uploads to fix)
   . Currently there are 56 unfixed in etch now
   . and 44 items left that we have to process


Etching our way towards testing security
----------------------------------------

Now that Sarge has released the testing-security team is shifting
gears from keeping the security pressure on for the release towards
building out our infrastructure to provide more security support for
testing. The team has worked hard to get Sarge secure, and we now have
a testing distribution with no old security holes in it.

We are beginning to move towards developing the procedures necessary
to start providing regular security updates for testing.  This means
developing a DTSA (Debian Testing Security Advisory) procedure and
start releasing these as GPG signed advisories. Also provide timely
package updates for security issues in testing. Our goal would be no
more than four days after a DSA is released.

Initially we will start experimental service for i386, extending it as
we go. We are lowering the bar for architecture synchronicty, due to
the volitile nature of testing.

We hope we can obtain security infrastructure for testing, either by
obtaining the testing-security (and/or testing-proposed-updates)
queues to get packages built against etch. However, if we cannot
procure this resource we will have to set up our own queues and
autobuilder network (or possibly piggyback on the experimental
autobuild network). Stay tuned for more information.

Additionally our team continues to maintain the[1] public database and
statistics about the current state of security in testing. We are
developing ways to make this listing more granular so that higher
priority items are distinct from less urgent minor and obscure issues.
We are also looking to provide to MITRE information about
vulnerabilities that we track that have not received a CVE assignment
(currently we have 55).


1. http://newraff.debian.org/~joeyh/testing-security.html


-------------- 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/20050615/8204ad77/attachment.pgp

This thread brings up something that has not been worked out here in
the testing-security team. We need to define some procedures for
handling this sort of thing that can be made public so developers know
what to do. 

Additionally, should testing-security provide security notices (such
as DSA''s)? If so, how would this work?

It has been asked on debian-security, and debian-devel[1] what
testing-security has done. Thus far, we have only been tracking known
CAN/DSAs and generating the newraff/~joeyh/testing-security.html page.
This page is useful for release managers, and people concerned about
running testing (and arguably a blueprint/roadmap for hackers, but
thats another thread). But are people expecting more? If so what is
it? Security updates have been going through unstable, or
testing-proposed-updates, supposedly there was some testing-security
infrastructure that was holding up sarge, but we aren''t really using
it.

Micah

1. http://lists.debian.org/debian-devel/2005/05/msg01060.html


On Sat, 04 Jun 2005, Martin Schulze wrote:
> If it should go via security.debian.org, I''ll just fetch the
source
> package, strip off the unstable part, rebuild as 2.2.1-4sarge1 and
> take care of it.
> 
> Regards,
> 
> 	Joey
> 
> -- 
> Those who don''t understand Unix are condemned to reinvent it,
poorly.
> 
> _______________________________________________
> Secure-testing-team mailing list
> Secure-testing-team@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/secure-testing-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/20050604/5efed5eb/attachment.pgp

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moritz Muehlenhoff <jmm@inutil.org> writes:
> Roger Leigh wrote:
>> There''s a serious vulnerability in fuse; see bug #311634.
>> This does not yet have a CVE ref, but I found
>> http://secunia.com/advisories/15561/
>> 
>> I''ve prepared updates for both sid and sarge:
>> http://people.debian.org/~rleigh/fuse/sarge-security/
>> 
>> Due to the release being so close, I haven''t uploaded either
of these.
>> I''m not a security expert, so thought you might be better
reviewing
>> them first, in case I''ve missed something. 
>
> FWIW, the patch is identical to the one posted to linux-kernel by
> Miklos Szeredi, the official fuse kernel maintainer, so it seems
> safe.
Thanks.  Just to double check, which distribution do I put in the
changelog, and which upload queue do I use?  aba said to use
sarge-security, but elsewhere I read to use testing-security, so I''d
just like to be 100% sure.


Thanks again,
Roger

- -- 
Roger Leigh
                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFCoY/UVcFcaSW/uEgRApVeAJ952i8A00jHfn5M+KELcVfn1tJh1QCcD17w
1FZQKQpN6sgFydf4QsofqI8=LJzA
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bartosz Fenski aka fEnIo <fenio@debian.org> writes:

Hi,
> On Sat, Jun 04, 2005 at 12:26:15PM +0100, Roger Leigh wrote:
>> >> There''s a serious vulnerability in fuse; see bug
#311634.
>> >> This does not yet have a CVE ref, but I found
>> >> http://secunia.com/advisories/15561/
>> >> 
>> >> I''ve prepared updates for both sid and sarge:
>> >> http://people.debian.org/~rleigh/fuse/sarge-security/
>> >> 
>> >> Due to the release being so close, I haven''t uploaded
either of these.
>> >> I''m not a security expert, so thought you might be
better reviewing
>> >> them first, in case I''ve missed something. 
>> >
>> > FWIW, the patch is identical to the one posted to linux-kernel by
>> > Miklos Szeredi, the official fuse kernel maintainer, so it seems
>> > safe.
>> 
>> Thanks.  Just to double check, which distribution do I put in the
>> changelog, and which upload queue do I use?  aba said to use
>> sarge-security, but elsewhere I read to use testing-security, so
I''d
>> just like to be 100% sure.
> I also have prepared fixed packages and I also not sure where to upload
> them. I wrote to security team two days ago about it and I haven''t
received
> any answer yet.
- From what I''ve read over the last couple of hours, you want

  fuse (2.2.1-5sarge1) testing-security; urgency=high

in the changelog (I checked the versions with `dpkg
- --compare-versions`), and you upload to /pub/SecurityUploadQueue on
security.debian.org (dupload: --to anonymous-security).

You also need to build with dpkg-buildpackage -sa to ensure the full
source is uploaded (including .orig.tar.gz).  You need to do this in a
sarge chroot ideally, or on a sarge system.

I won''t do anything further with this if you''re going to take
care of
it.


Thanks,
Roger

- -- 
Roger Leigh
                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFCoaEXVcFcaSW/uEgRAtWvAJ0VFY/alf8nnsZBCBQT1K7NsKX2xACg5xpW
FuEshSPQcQTx6hA4hCKoaUY=Xqor
-----END PGP SIGNATURE-----

Bartosz Fenski aka fEnIo <fenio@debian.org> writes:
> On Sat, Jun 04, 2005 at 12:26:15PM +0100, Roger Leigh wrote:
>> >> There''s a serious vulnerability in fuse; see bug
#311634.
>> >> This does not yet have a CVE ref, but I found
>> >> http://secunia.com/advisories/15561/
>> >> 
>> >> I''ve prepared updates for both sid and sarge:
>> >> http://people.debian.org/~rleigh/fuse/sarge-security/
>> >> 
>> >> Due to the release being so close, I haven''t uploaded
either of these.
>> >> I''m not a security expert, so thought you might be
better reviewing
>> >> them first, in case I''ve missed something. 
>> >
>> > FWIW, the patch is identical to the one posted to linux-kernel by
>> > Miklos Szeredi, the official fuse kernel maintainer, so it seems
>> > safe.
>> 
>> Thanks.  Just to double check, which distribution do I put in the
>> changelog, and which upload queue do I use?  aba said to use
>> sarge-security, but elsewhere I read to use testing-security, so
I''d
>> just like to be 100% sure.
>
> I also have prepared fixed packages and I also not sure where to upload
> them. I wrote to security team two days ago about it and I haven''t
received
> any answer yet.
Properly built (with source) packages are here:

http://people.debian.org/~rleigh/fuse/

These are ready to upload if you want.


Regards,
Roger

-- 
Roger Leigh
                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

On Tue, Jun 07, 2005 at 08:59:47AM +0200, Martin Schulze
wrote:
> > >  . please forward it upstream
> > 
> > Upstream knows it already and that was the reason to release 2.3.0
version.
> 
> But upstream probably doesn''t know about the CVE id.
> 
> CAN-2005-nnnn a unique identifier for a vulnerability in a software
> package.  The database behind this is maintained at MITRE''s Common
> Vulnerabilities and Exposures project <http://cve.mitre.org/cve/>.
> Details for such an id are available after a few days of quarantaine
> at <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-nnnn>.
> 
> Many vendors (both propriatery and Free Software) participate in this
> database and assign the id to vulnerability reports or updates they
> produce.  These IDs help us security people generally for identifying
> if a given package is fixed or if a given update fixes which problem.
> Please mention this ID in the changelog and/or project announcements.
Ok. He''s CCed in this message.

Thanks for comments.

regards
fEnIo

-- 
  ,''''`.  Bartosz Fenski | mailto:fenio@debian.org |
pgp:0x13fefc40 | irc:fEnIo
 : :'' :       32-050 Skawina - Glowackiego 3/15 - w. malopolskie -
Poland
 `. `''           phone:+48602383548 | proud Debian maintainer and user
   `-          http://skawina.eu.org | jid:fenio@jabber.org | rlu:172001
-------------- 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/20050607/6355d2ef/attachment.pgp

Martin Schulze wrote:
> Bartosz Fenski aka fEnIo wrote:
> > On Sat, Jun 04, 2005 at 06:02:00PM +0200, Martin Schulze wrote:
> > > If it should go via security.debian.org, I''ll just fetch
the source
> > > package, strip off the unstable part, rebuild as 2.2.1-4sarge1
and
> > > take care of it.
> > 
> > I''ll be thankful if you could take care of it, cause
I''m getting more and
> > more confused about which queue should I use ;)
> > 
> > So please upload it yourself if you can.
> 
> Ok, will do.  Asked for a CVE id first, will provide it to you as well.
> More instructions will follow.
This is CAN-2005-1858.

Please
 . update the package in sid
 . mention the CVE id from the subject in the changelog
 . tell me the version number of the fixed package
 . use priority=high
 . please forward it upstream

I''ll take care of sarge, once security.debian.org is unbroken again.

Regards,

	Joey

-- 
Let''s call it an accidental feature.  -- Larry Wall

On Wed, Jun 08, 2005 at 01:49:01PM +1000, Andrew Pollock
wrote:
> I think the biggest misnomer with testing-security is its name. Think of it
> as sarge-security. This is why it was a blocker for the release - we needed
> it for after sarge became stable. So what was testing-security just got
> promoted to stable-security when we released sarge. Arguably the
> wood-security stuff should get recycled into etch-security, but I think
that
> we provide oldstable security support for a bit, so we either need to go
> through the hassle of setting up etch-security now, or wait until resources
> are freed up from oldstable-security.
This testing security list was created recently, but Debian has released many
times before. How was this type of problem handled earlier? (Simultaneous
upgrades for potato and slink, for instance.)

// Ulf

On Tue, Jun 07, 2005 at 10:39:41PM -0500, Micah Anderson
wrote:
> On Mon, 06 Jun 2005, Joey Hess wrote:
> 
> > Micah Anderson wrote:
> > > Additionally, should testing-security provide security notices
(such
> > > as DSA''s)? If so, how would this work?
> > 
> > I believe that we should do this, but have been waiting for the
release
> > of sarge for it, since I''m not sure if we can do something to
get the
> > testing-security (and/or testing-proposed-updates) queues to remain
> > functional after sarge is released, to get packages built against
etch.
> 
> It seems as if testing-security has been renamed to stable-security,
> so this queue is out. Also, from what I understand britney hasn''t
been
> reenabled yet for etch, and since the release is so recent, this is
> probably not people''s highest priority. Maybe I''m a sarge
> party-pooper, but I would rather not find out a month from now that
> these queues were destroyed because nobody thought they were useful to
> keep around anymore, but from what I''ve been able to find out --
there
> simply aren''t any.
I think the biggest misnomer with testing-security is its name. Think of it
as sarge-security. This is why it was a blocker for the release - we needed
it for after sarge became stable. So what was testing-security just got
promoted to stable-security when we released sarge. Arguably the
wood-security stuff should get recycled into etch-security, but I think that
we provide oldstable security support for a bit, so we either need to go
through the hassle of setting up etch-security now, or wait until resources
are freed up from oldstable-security.
 
regards

Andrew
-------------- 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/20050608/65df8629/attachment.pgp

Joey Hess wrote:
> I like the levels, but the punctuation seems non-obvious. How about
> this, which allows for future expansion:
> 
> CAN-2005-XXXX [remote root exploit in foo; also present but not built in
bar''s source]
> 	- foo 3.1.4 (high)
> 	- bar (unfixed; bug #101010; low)
Fine with me.
> > And we need to track testing propagation, so that the specific fix is
purged
> > once the regular fix has propagated.
> 
> We need to make sure our fixes have a version number which allows the
> regular fix to replace them on upgrade.
What about something like this:
3.14-1 vulnerable version in testing
3.14-1ts1 fix prepared by secure-testing
3.14-2 regular maintainer fix coming through the regular testing propagation
> Another problem is we need to
> make sure that a new vulnerable version doesn''t come in from
unstable
> and replace our fix.
But this would only be the case if the maintainer hasn''t read his bug
reports
(we should still continue to file bugs for every security issue) and issues
an update without including a fix or do I misinterpret you?  
> So I think limiting ourselves to security holes
> that have RC bugs is a good idea (why do any more work that that
> anyway), but still an RC bug could conceivably be downgraded or ignored
> and so we''ll have to make sure to catch these cases and relase a
new
> fix.
We''ll notice this anyway through d-d-c. I''m reading every
change there, you
seem to do the same and I guess most other s-t team members do as well.

Once things get established a bit more this should creep into the
developer''s
reference as well.

Cheers,
        Moritz

Moritz Muehlenhoff wrote:
> Yes, but we should keep that set of issues small, the Secunia
classifications
> are too extensive. We won''t have the resources to track for each
vulnerability
> whether it''s actively exploited, as Secunia does seem to do.
> 
> There are too many unknown variable''s on the side of the host
running the
> vulnerable code. The best way to address severity of more important issues
is to
> prioritize fixes for these issues in a faster manner.
> 
> So maybe we should start with a simple differentiation between
> vulnerabilities and minor issues, which may not be optimal from a security
> perspective. e.g.:
> 
> - issues only exploitable under rare circumstances/stupid setups (e.g.
cpio,
>   coreutils)
> - issues affecting code not shipped in the binary packages (e.g.
krb5/278271)
> - DoS against applications without security implications (e.g. lynx),
except
>   that availability has been attacked
> - others?
I agree that we should KISS and bear in mind that we''re only using it
to
prioritise our work.
> > http://secunia.com/about_secunia_advisories/
> > 
> > and another one about type of vulnerabilities, the goal would be to
> > autobuilt a page like this :
> 
> IMO DSAs contain a useful set of issue classifications we should adopt.
We''d certianly want to use those in DTSAs.

-- 
see shy jo
-------------- 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/20050619/b967350d/attachment.pgp

Steve Langasek wrote:
> On Sun, Jun 19, 2005 at 12:55:55PM -0400, Joey Hess wrote:
> > I like the levels, but the punctuation seems non-obvious. How about
> > this, which allows for future expansion:
> 
> > CAN-2005-XXXX [remote root exploit in foo; also present but not built
in bar''s source]
> > 	- foo 3.1.4 (high)
> > 	- bar (unfixed; bug #101010; low)
> 
> > I have a probably not quite working patch for this which I can commit
> > which will add the notes to the web page, we could also use this to
> > colorise it with shades of red or something.
> 
> Shading or something else that allows for easy scanning would be
> appreciated.
Would someone like to contribute some css, html, or whatever that can do
that?

-- 
see shy jo
-------------- 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/20050619/0869c32f/attachment.pgp

Moritz Muehlenhoff schrieb am Sunday, den 19. June 2005:
> Micah Anderson wrote:
> > I think that we''d have to be careful about DoS''
because any
> > vulnerability that can cause a service interruption should be viewed
> > as minor only with qualifications.
> 
> Yes, DoSing Apache is not a minor issue, but DoSing browsers, mails clients
> etc. is IMO.
Yeah, I agree.
> > What about three risk categories: low, medium, high. 
> 
> Personally I think there are too many different systems out there to
> define severitys for real issues, as there are too many variables to define
a
> generic severity. DSAs aren''t doing such a classification for a
good reason
> as well.
> Additionally you''d need to update the information once you find an
exploit
> (leaving out the problematic fact that''d you''ll never
really know whether
> an exploit is available among black hats)
> But I don''t care too much for that issue, three levels would be
fine for me
> as well.
Ah, I thought we were talking about these categories for our own
purposes in terms of color coding things on
http://newraff.debian.org/... I hadn''t considered if it would make
sense to add severities to DTSAs or not.

micah
-------------- 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/20050619/096267cf/attachment.pgp

Moritz Muehlenhoff wrote:
> > We need to make sure our fixes have a version number which allows the
> > regular fix to replace them on upgrade.
> 
> What about something like this:
> 3.14-1 vulnerable version in testing
> 3.14-1ts1 fix prepared by secure-testing
> 3.14-2 regular maintainer fix coming through the regular testing
propagation
This will fail if there''s an NMU to debian with the fix, since it will
superscede the NMU. It probably needs to use a version like -1.0.0ts1 to
avoid prolems with binary NMUs too.
> > Another problem is we need to
> > make sure that a new vulnerable version doesn''t come in from
unstable
> > and replace our fix.
> 
> But this would only be the case if the maintainer hasn''t read his
bug reports
> (we should still continue to file bugs for every security issue) and issues
> an update without including a fix or do I misinterpret you?  
It could also happen if the release team decide getting the new package
into testing is more important than the security fix, for example. It''s
just something we need to keep an eye out for.

-- 
see shy jo
-------------- 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/20050622/e3555b9c/attachment.pgp

On Sat, Jun 18, 2005 at 12:37:24AM +0200, Moritz Muehlenhoff
wrote:
> Joey Hess wrote:
> > > DTSA seem like a good idea. For the sake of consistency it seems
like a good
> > > idea to issue them from the s-t team. When doing so we should
talk to the MITRE
> > > people whether DTSAs would qualify as CVE data sources. There are
currently
> > > 55 vulnerabilities tracked by us that haven''t ever
received a CVE assignment,
> > > some of which may as well be in other vendor''s products.
(MITRE may be only a
> > > dictionary, but in practice it''s more). 
> > Couldn''t we just get a pipe to mitre and submit those? I
assume we have
> > other data sources for them that mitre could point to, such as the
> > debian BTS.
> I just asked the security team for a CVE ID for an issue not present in
Woody
> and Joey told me that they don''t assign IDs to such issues, only
if it were
> present in another vendor''s product.
AFAIK, what this actually means is that the Debian security team will not
*request* a CVE ID for an issue not present in a stable release, and
therefore none will be assigned.  I don''t know of any explicit reason
why
CVE IDs couldn''t be issued for DTSAs, if the secure-testing team
established
a relationship with MITRE.

-- 
Steve Langasek
postmodern programmer
-------------- 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/20050617/a245a2b7/attachment.pgp

Moritz Muehlenhoff wrote:
> Ok, what about this:
> 
> CAN-2005-XXXX [buffer overflow in foo]
>         - foo 3.1.4
> 
> CAN-2005-XXXX [foo is DoSable when used in full moon and it''s PID
is a mersenne prime]
>         _ foo 3.1.4
> 
> As said in another mail I think very high priority stuff would best be
> prioritized by fixing it faster than the rest and that this is really hard
> to classify, but of course we could add something like:
> 
> CAN-2005-XXXX [remote root exploit in foo]
>         ^ foo 3.1.4
I like the levels, but the punctuation seems non-obvious. How about
this, which allows for future expansion:

CAN-2005-XXXX [remote root exploit in foo; also present but not built in
bar''s source]
	- foo 3.1.4 (high)
	- bar (unfixed; bug #101010; low)
 
I have a probably not quite working patch for this which I can commit
which will add the notes to the web page, we could also use this to
colorise it with shades of red or something.
> And it would be nice if our provisional vulnerability summaries were
overwritten
> with MITRE''s once this are issued, right now the script
doesn''t touch these.
This untested patch should do it:

Index: updatelist
==================================================================--- updatelist
(revision 1231)
+++ updatelist	(working copy)
@@ -93,7 +93,11 @@
 		my $desc=$2;
 		docan($can) if $can;
 		$can=$1;
-		$cans{$can}{description}=$desc if length $desc && $desc !~
/^\(.*\)$/;
+		if (length $desc && $desc !~ /^\(.*\)$/ &&
+		    (! exists $cans{$can}{description} ||
+		     ! length $cans{$can}{description})) {
+			$cans{$can}{description}=$desc;
+		}
 	}
 	elsif (/^\s+NOTE:\s*(reserved|rejected)\s*$/) {
 		# skip it
> What about an additional Alioth ML for now? If it works out after the
experimental
> phase it can still be promoted to a regular d.o list.
Good idea, I will set that up next time I''m online.
> > We might also want to do
> > announcements for holes that get fixed in testing via regular testing
> > propigation.
> 
> Yes, but I guess that''s also for the not-experimental-anymore
phase, as it''s
> quite a lot of work.
Getting the list should be automatable, then the work is only a matter
of writing descriptions of the vulnerabilities. If we decide not to
offer a lot of detail it seems doable.
> And we need to track testing propagation, so that the specific fix is
purged
> once the regular fix has propagated.
We need to make sure our fixes have a version number which allows the
regular fix to replace them on upgrade. Another problem is we need to
make sure that a new vulnerable version doesn''t come in from unstable
and replace our fix. So I think limiting ourselves to security holes
that have RC bugs is a good idea (why do any more work that that
anyway), but still an RC bug could conceivably be downgraded or ignored
and so we''ll have to make sure to catch these cases and relase a new
fix.

-- 
see shy jo
-------------- 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/20050619/bf8001a9/attachment.pgp

Moritz Muehlenhoff schrieb am Saturday, den 18. June 2005:
> Djoume SALVETTI wrote:
> > > I''m thinking of some "minor" tag for
uncritical tempraces, packages
> > > not vulnerable in the Debian package, and generally obscure
issues.
> > 
> > What do you think about two kinds of tags?
> > 
> > One about severity or "criticality" like what we can find on
secunia :
> 
> Yes, but we should keep that set of issues small, the Secunia
classifications
> are too extensive. We won''t have the resources to track for each
vulnerability
> whether it''s actively exploited, as Secunia does seem to do.
I agree, I think that our classifications should be simple, perhaps
only three different categories.
> So maybe we should start with a simple differentiation between
> vulnerabilities and minor issues, which may not be optimal from a security
> perspective. e.g.:
> 
> - issues only exploitable under rare circumstances/stupid setups (e.g.
cpio,
>   coreutils)
> - issues affecting code not shipped in the binary packages (e.g.
krb5/278271)
> - DoS against applications without security implications (e.g. lynx),
except
>   that availability has been attacked
> - others?
Would these all be minor issues? 

I think that we''d have to be careful about DoS'' because any
vulnerability that can cause a service interruption should be viewed
as minor only with qualifications.

What about three risk categories: low, medium, high. 

Things that go into the high risk category would be things like remote
root exploits, local root exploits, priviledge escalation to
super-user, remote/local service crippling via DoS, and sensitive
information disclosure. Medium risk vulnerabilities that have known
exploits/proof-of-concepts would be promoted to high-risk.

Medium risk would be vulnerabilities without known
exploits/proof-of-concepts on LAN-based services (SMB, lpr, NFS, RPC),
cross-site scripting and priviledge escalation not resulting in root
priviledges.

Low risk are rare, theoretical exploits that are circumstantial,
issues affecting code not shipped in binary packages. Non-sensitive
information disclosure. (Issues that you listed above)

Micah

Micah Anderson wrote:
> What about three risk categories: low, medium, high. 
> 
> Things that go into the high risk category would be things like remote
> root exploits, local root exploits, priviledge escalation to
> super-user, remote/local service crippling via DoS, and sensitive
> information disclosure. Medium risk vulnerabilities that have known
> exploits/proof-of-concepts would be promoted to high-risk.
> 
> Medium risk would be vulnerabilities without known
> exploits/proof-of-concepts on LAN-based services (SMB, lpr, NFS, RPC),
> cross-site scripting and priviledge escalation not resulting in root
> priviledges.
> 
> Low risk are rare, theoretical exploits that are circumstantial,
> issues affecting code not shipped in binary packages. Non-sensitive
> information disclosure. (Issues that you listed above)
As long as we''re using the classificatons to decide what gets priority
to be worked on (or to ignore stuff that is not worth working on ;-), I
thnk that the specifics don''t matter very much. If we end up with too
many high priority things spanning too broad a spectrum then we will
naturally shift the boundry between it and medium, or add a fouth level.

We may find it better to start with just two levels, since I think we''d
all be agreed of what goes in high and low then, and we can always add
more later.

-- 
see shy jo
-------------- 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/20050619/4133c71a/attachment.pgp

Micah Anderson wrote:
> However, I am wondering if we
> should wait to send this out until we have this repository and a place
> to mail the announcements, so we can communicate those?
Seems like a good idea. If we have some more to offer it can be "Bytes
from.."
instead of all the ordinary "Bits from.." mails :-)

Cheers,
        Moritz

Micah Anderson wrote:
> > So maybe we should start with a simple differentiation between
> > vulnerabilities and minor issues, which may not be optimal from a
security
> > perspective. e.g.:
> > 
> > - issues only exploitable under rare circumstances/stupid setups (e.g.
cpio,
> >   coreutils)
> > - issues affecting code not shipped in the binary packages (e.g.
krb5/278271)
> > - DoS against applications without security implications (e.g. lynx),
except
> >   that availability has been attacked
> > - others?
> 
> Would these all be minor issues? 
Yes.
 
> I think that we''d have to be careful about DoS'' because
any
> vulnerability that can cause a service interruption should be viewed
> as minor only with qualifications.
Yes, DoSing Apache is not a minor issue, but DoSing browsers, mails clients
etc. is IMO.
 
> What about three risk categories: low, medium, high. 
> 
> Things that go into the high risk category would be things like remote
> root exploits, local root exploits, priviledge escalation to
> super-user, remote/local service crippling via DoS, and sensitive
> information disclosure. Medium risk vulnerabilities that have known
> exploits/proof-of-concepts would be promoted to high-risk.
> 
> Medium risk would be vulnerabilities without known
> exploits/proof-of-concepts on LAN-based services (SMB, lpr, NFS, RPC),
> cross-site scripting and priviledge escalation not resulting in root
> priviledges.
Personally I think there are too many different systems out there to
define severitys for real issues, as there are too many variables to define a
generic severity. DSAs aren''t doing such a classification for a good
reason
as well.
Additionally you''d need to update the information once you find an
exploit
(leaving out the problematic fact that''d you''ll never really
know whether
an exploit is available among black hats)
But I don''t care too much for that issue, three levels would be fine
for me
as well.

Cheers,
        Moritz

Micah Anderson wrote:
> > > Moritz Muehlenhoff wrote:
> 
> > Ok, what about this:
> > 
> > CAN-2005-XXXX [buffer overflow in foo]
> >         - foo 3.1.4
> > 
> > CAN-2005-XXXX [foo is DoSable when used in full moon and it''s
PID is a mersenne prime]
> >         _ foo 3.1.4
> 
> To clarify, you are suggesting that we use the ''-''
character for
> medium/normal priority items, the ''_'' character for
low/rare priority
> items.
Yes.
 
> > CAN-2005-XXXX [remote root exploit in foo]
> >         ^ foo 3.1.4
> 
> and ''^'' for high priority itmes, am I reading that
correctly?
Yup. 
> > And it would be nice if our provisional vulnerability summaries were
overwritten
> > with MITRE''s once this are issued, right now the script
doesn''t touch these.
> 
> Do you have ideas of how to do that? It seems like a difficult problem
> and would always require manual cross-referencing, unless I am
> misunderstanding what you are referring to.
Might have been a bit hard to understand; I refered to cases where the CAN ID is
still
reserved, but information about a certain vulnerability has already been
published,
e.g. CAN-2005-1858. Once the official description is out it would be nice if the
provisional
one were overwritten, right now it''s kept.
> We can setup apt repositories and mailing lists on alioth, although
> such repositories seem pretty ad-hoc. What about something on
> debian.net?
If it''s no more difficult than Alioth, why not?
 
> > > Couldn''t we just get a pipe to mitre and submit those? I
assume we have
> > > other data sources for them that mitre could point to, such as
the
> > > debian BTS.
> > 
> > I just asked the security team for a CVE ID for an issue not present
in Woody
> > and Joey told me that they don''t assign IDs to such issues,
only if it were
> > present in another vendor''s product.
> > I''ll check which conditions would be required to assign IDs
for these as well.
> 
> Are you checking with MITRE about this?
Yes, I''ve already send a mail, I''ll tell what they are
thinking once they replied.

Cheers,
        Moritz

Joey Hess wrote:
> Moritz Muehlenhoff wrote:
> > Don''t underestimate the time required for providing a
security update.
> > So, first we should find criteria for issues that should be handled
through
> > secure-testing, ideally in a form suitable for data/CAN/list. Several
> > of the issues right now listed in newraff.d.o/t-s.h do not really
deserve
> > urgent action (and they begin making the overview a bit crowded).
I''m
> > thinking of some "minor" tag for uncritical tempraces,
packages not
> > vulnerable in the Debian package, and generally obscure issues.
> 
> Yes, I agree we need something like that, perhaps to color code the
> list. Picking out remote shell exploits or the like (very high priority
> stuff) would also be handy.
Ok, what about this:

CAN-2005-XXXX [buffer overflow in foo]
        - foo 3.1.4

CAN-2005-XXXX [foo is DoSable when used in full moon and it''s PID is a
mersenne prime]
        _ foo 3.1.4

As said in another mail I think very high priority stuff would best be
prioritized by fixing it faster than the rest and that this is really hard
to classify, but of course we could add something like:

CAN-2005-XXXX [remote root exploit in foo]
        ^ foo 3.1.4

And it would be nice if our provisional vulnerability summaries were overwritten
with MITRE''s once this are issued, right now the script
doesn''t touch these.
 
> > I''d suggest to start an experimental service for i386 for
now, if it works
> > out it can be extended.
> 
> Works for me. I''m araid that Neuro is probably going to have to
> prioritise getting the security system working again for stable over us,
> since that is apparently not working at all right now. Sigh.
> 
> Anyway, an experimental apt repo for this is easy enough to set up. I
> wonder where we should mail the announcements? 
What about an additional Alioth ML for now? If it works out after the
experimental
phase it can still be promoted to a regular d.o list.
> We might also want to do
> announcements for holes that get fixed in testing via regular testing
> propigation.
Yes, but I guess that''s also for the not-experimental-anymore phase, as
it''s
quite a lot of work.

And we need to track testing propagation, so that the specific fix is purged
once the regular fix has propagated.
 
> > DTSA seem like a good idea. For the sake of consistency it seems like
a good
> > idea to issue them from the s-t team. When doing so we should talk to
the MITRE
> > people whether DTSAs would qualify as CVE data sources. There are
currently
> > 55 vulnerabilities tracked by us that haven''t ever received a
CVE assignment,
> > some of which may as well be in other vendor''s products.
(MITRE may be only a
> > dictionary, but in practice it''s more). 
> 
> Couldn''t we just get a pipe to mitre and submit those? I assume we
have
> other data sources for them that mitre could point to, such as the
> debian BTS.
I just asked the security team for a CVE ID for an issue not present in Woody
and Joey told me that they don''t assign IDs to such issues, only if it
were
present in another vendor''s product.
I''ll check which conditions would be required to assign IDs for these
as well.

Cheers,
        Moritz

Moritz Muehlenhoff schrieb am Saturday, den 18. June 2005:
> Joey Hess wrote:
> > Moritz Muehlenhoff wrote:
> Ok, what about this:
> 
> CAN-2005-XXXX [buffer overflow in foo]
>         - foo 3.1.4
> 
> CAN-2005-XXXX [foo is DoSable when used in full moon and it''s PID
is a mersenne prime]
>         _ foo 3.1.4
To clarify, you are suggesting that we use the ''-'' character
for
medium/normal priority items, the ''_'' character for low/rare
priority
items.
> CAN-2005-XXXX [remote root exploit in foo]
>         ^ foo 3.1.4
and ''^'' for high priority itmes, am I reading that correctly?
> And it would be nice if our provisional vulnerability summaries were
overwritten
> with MITRE''s once this are issued, right now the script
doesn''t touch these.
Do you have ideas of how to do that? It seems like a difficult problem
and would always require manual cross-referencing, unless I am
misunderstanding what you are referring to.
> > Anyway, an experimental apt repo for this is easy enough to set up. I
> > wonder where we should mail the announcements? 
> 
> What about an additional Alioth ML for now? If it works out after the
experimental
> phase it can still be promoted to a regular d.o list.
We can setup apt repositories and mailing lists on alioth, although
such repositories seem pretty ad-hoc. What about something on
debian.net?
> > Couldn''t we just get a pipe to mitre and submit those? I
assume we have
> > other data sources for them that mitre could point to, such as the
> > debian BTS.
> 
> I just asked the security team for a CVE ID for an issue not present in
Woody
> and Joey told me that they don''t assign IDs to such issues, only
if it were
> present in another vendor''s product.
> I''ll check which conditions would be required to assign IDs for
these as well.
Are you checking with MITRE about this? If so, I think others should
not attempt communication with them. I think that if we do approach
MITRE it should be through one person and not have multiple people
speaking with them. Having one person (and a backup) as someone that
they expect communications from seems like it would increase our
chances of success with them. I''d be happy to help with being a
liason/interface with them.

micah
-------------- 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/20050619/4e9fe34c/attachment.pgp

On Sun, Jun 19, 2005 at 12:55:55PM -0400, Joey Hess
wrote:
> I like the levels, but the punctuation seems non-obvious. How about
> this, which allows for future expansion:
> CAN-2005-XXXX [remote root exploit in foo; also present but not built in
bar''s source]
> 	- foo 3.1.4 (high)
> 	- bar (unfixed; bug #101010; low)
> I have a probably not quite working patch for this which I can commit
> which will add the notes to the web page, we could also use this to
> colorise it with shades of red or something.
Shading or something else that allows for easy scanning would be
appreciated.

-- 
Steve Langasek
postmodern programmer
-------------- 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/20050619/25f88cdc/attachment.pgp