Re: CVE Requests

[Kurt Seifried <kseifried () redhat com>]

On 03/15/2012 07:30 PM, Mark Stanislav wrote:
> #1,2,3 are all included

? Sorry but I have literally no idea what that means.

> #4, each project is linked to where the code (both vulnerable and/or
> fixed) lives
>
> #5...
> phpMoneyBooks, 1.0.2 and potentially prior versions
> phpGradeBook, 1.9.4 and potentially prior versions
> phpPaleo, 4.8b155 and potentially prior versions
> hbportal, 0.1 and potentially prior versions
> eticketing, no version numbering used *shrug*
>
> #6 An e-mail was sent to cve () mitre org <mailto:cve () mitre org> 7 days ago
> without response
> #7 All open source
> #8 Not embargoed

I need the actual information for each one. Check out the nginx CVE
request today for a good example.


> I think that should do it.
>
> -Mark
>
> On Thu, Mar 15, 2012 at 8:22 PM, Kurt Seifried <kseifried () redhat com
> <mailto:kseifried () redhat com>> wrote:
>
>     On 03/15/2012 01:18 PM, Mark Stanislav wrote:
>     > Howdy,
>     >
>     > I was looking to receive CVEs for the following...
>     >
>     > 1) phpMoneyBooks (http://phpmoneybooks.com/) has an
>     unauthenticated local
>     > file inclusion (LFI) vulnerability
>     > * Notified, Response Received, and Patch Released
>     >
>     > 2) phpGradeBook (http://phpgradebook.com/) has unauthenticated SQL
>     Database
>     > Exportation
>     > * Notified, Response Received, and Patch Released
>     >
>     > 3) phpPaleo (http://sourceforge.net/projects/phppaleo/) has an
>     > unauthenticated local file inclusion (LFI) vulnerability
>     > * Notified, Response Received, and Patch Released
>     >
>     > 4) hbportal (http://sourceforge.net/projects/hbportal/) has a
>     POST-based
>     > SQL injection vulnerability
>     > * Notified
>     >
>     > 5) e-ticketing (http://sourceforge.net/projects/e-ticketing/) has a
>     > POST-based SQL injection vulnerability
>     > * Notified & Response Received
>     >
>     > Thanks!
>     >
>     > -Mark
>     >
>     Removed the "no" this time to avoid ambiguity=)
>
>     More info would be helpful. Some draft guidelines:
>
>     Information for CVE request, REQUIRED:
>
>     1) Email address of requester (so we can contact them)
>     2) Software name and optionally vendor name
>     3) At least one of (to determine is this a security issue):
>      1. Type of vulnerability
>      2. Exploitation vectors
>      3. Attack outcome
>     4) For Open Source at least one of:
>      1. Link to vulnerable source code or fix
>      2. Link to source code change log
>      3. Link to security advisory
>      4. Link to bug entry
>      5. Request comes from project member (a.k.a. "trust me, it's a
>     problem")
>     5) Affected version(s) (3.2.4, 3.x, current version, all current
>     releases, something)
>     6) Whether or not this has been previously requested (i.e. on OSS-Sec or
>     to cve-assign)
>     7) Is this an Open Source or commercial software request
>     8) Is this an embargoed issue (if yes and commercial: send to
>     cve-assign, if yes and open source: send to vs-sec?)
>     9) IF multiple issues are listed please list affected versions for each
>     issue and/or who reported them (so we can determine CVE split/merge).
>
>     Information for CVE request, REQUESTED:
>
>     1) More of the above information of course
>     2) Software version(s) fixed (if available)
>     3) For closed source any of the information from "For Open Source at
>     least one of:"
>     4) Any additional information
>
>
>     --
>
>     -- Kurt Seifried / Red Hat Security Response Team


-- 
Kurt Seifried Red Hat Security Response Team (SRT)