(In reply to comment #3)
> (In reply to comment #2)
> > Access Complexity: High (no existing applications will act on an invalid
> > signature so this would need to be custom/unsupported app that is written
> > incorrectly)
> 
> Not sure if this is reason for AC:H.  When scoring, you need to assume worst
> case - i.e. if there is an application that does something with invalid
> signatures and assess difficulty of triggering mis-behaviour of such app.

Yeah, I talked with Eugene last night and he cleared some of this up for me, so I think this should be AC:L because anyone can talk to dbus via /var/run/dbus/system_bus_socket (i.e. look at how difficult it is to get to the application for exploitation, not necessarily how theoretical or not it is).

> > Authentication: Single (just need local access)
> 
> This is wrong.  You already assume AV:L, so you can't use "local access" here
> as single authentication.  For AV:L, you only use Au:S if *additional*
> authentication is required besides access to the system.  In DBus case, the
> example may possibly be a DBus policy restriction only allowing users in
> certain group to send messages to affected service.

Right.  Eugene explained this as well.  =)  So I adjusted this to Au:N (I was thinking of the initial login required to obtain local access, but Eugene indicated that is assumed already, so this would be related to additional authentication (i.e. to authenticate to a MySQL server that listened to a socket and was thus only available to local users).

> > Confidentiality Impact: None (there is no way to compromise confidentiality as
> > existing apps will disregard invalid sigs)
> > Integrity Impact: None (there are no files or resources to change since
> > existing applications ignore the sigs)
> > Availability Impact: None (there is no crash in the bus, or in applications
> > that ignore invalid sigs)
> 
> Well, yes, this looks like case where CVSSv2 does not work too well.  If we are
> assuming this may possibly do some harm to some theoretical application, I
> believe score need to take such application into account.

Yeah, this is the only bit that concerns me, but then I was thinking that perhaps then the vulnerability would be in the actual application that was acting on these invalid sigs if they came across.  It's not a "good thing" in dbus to allow it in the first place, but if all existing apps discard/ignore these invalid sigs as they're supposed to, but one app doesn't then the vulnerability is arguably in that one application and not in dbus itself (dbus, in this instance, just lets it pass through when it shouldn't, but the receiving end, if written correctly, should be ignoring them to begin with).

> > Which comes up with the base score -1.1.
> 
> There are no negative CVSSv2 scores ;).  This should be 0 if you have CIA:N.  

Yeah, that would be from the python class that generates the score (it should make anything negative 0).  I've adjusted that in our notes as well.

No one has responded on vendor-sec, and SUSE has indicated when this was initially discussed that they would not be patching dbus in regards to this.  If no one has any disagreement, then I think we should drop/reject this CVE and make this pretty much a non-issue.

Colin, this CVE was not mentioned in any commits or bug reports or anything outside of this bug report, was it?  If so, then we probably have to send MITRE some kind of rejection notice, otherwise we could just silently drop the CVE name and ensure we don't assign it to anything else, I think.

I don't think it was (unless you've removed it).  Looking at all the CVE's mentioned here:

https://bugs.freedesktop.org/show_bug.cgi?id=17803

There is no mention of CVE-2009-1193 that I can see (CVE-2009-1189 is mentioned, but that is perfectly fine and legitimate -- it's CVE-2009-1193 that is questionable).