[Secure-testing-team] Security update for fuse

[Moritz Muehlenhoff]

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