Request for CVEs for Pidgin

[Tomas Hoger]

Hi Mark!

On Mon, 13 Jan 2014 23:53:58 -0800 Mark Doliner wrote:

> Hi Red Hat security folk! This is Mark, a developer of Pidgin, Finch,
> and libpurple. We're working on fixing some security problems. I hope
> to disclose more details+patches to our standard packagers at pidgin.im
> mailing list (which includes you) sometime in the next few days, with
> a public embargo date of morning US Pacific time on Jan 23.
> 
> With the exception of one, these were all reported to us privately
> over the past 12 months via our security at pidgin.im mailing list.
> Sadly, this is a long list and we've been remiss in pushing out fixes
> on a regular basis.
> 
> Could you please assign CVE numbers to us? (The listed ISSUE number is
> solely for convenience in referencing them until they have proper CVE
> numbers.)

Josh and Jan changed their roles inside Red Hat and while they both
work on security from one side or another, they will no longer be able
to help with the CVE assignments, or need access to information on
non-public issues.  I'm keeping them CCed on this reply, but you can
drop them form the CC on any further replies.

I'd like to share this list with a colleague, Kurt Seifried, who
handles many CVE assignments, to help with deciding on the merge/split
cases.  You can find him do a lot of assignments on the oss-security
list.  Please let me know if it's ok to send him your list.

> The next vulnerability is the same as CVE-2011-3185. We failed to
> adequately fix it at that time. Is it customary to reuse that CVE or
> issue a new one?
> 
> ISSUE-12, discovered by Sourcefire VRT

In case of incomplete or incorrect fix, new CVE should be assigned.

> The following 3 vulnerabilities have the same pattern but are in
> different pieces of code. My preference is to use a separate CVE for
> each of them, but I seem to remember you preferring to share a CVE for
> vulnerabilities with the same type of problem. Your call. The pattern
> is: Read a value of "-1" from the network, call g_malloc(len + 1)
> which returns NULL, then attempt to write data to NULL (aka the first
> page of memory).

Merging is actually based on CVE content decision guidelines, you can
find more details in:
  http://cve.mitre.org/cve/editorial_policies/cd_overview.html

One other common reason to split is different reporter.  In this case,
flaw type, reporter and fixed-in versions are the same.  The reason to
split may be different versions in which those were introduced.  Not
sure if that is know, or if all of them affect any still used versions.

I also see there may be some reason to merge 6-8, as they all are NULL
dereference issues, but I assume those are triggered in completely
different ways.

-- 
Tomas Hoger / Red Hat Security Response Team