[Secure-testing-team] Security update for fuse

[Moritz Muehlenhoff]

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