Re: Re: FreeRDP tmp flaws

[Kurt Seifried <kseifried () redhat com>]

Ah poop, I remembered http://seclists.org/oss-sec/2014/q1/170 wrong, I
though if the code existed that was enough, not that the code had to
exist AND be enabled, OR enabled through a compiler flag for example. My
bad.

On 05/27/2015 09:28 AM, cve-assign () mitre org wrote:
> > This may need 2 CVE's
>
> We think there should be zero CVEs because the report is apparently
> about a developer's debugging code that was never shipped.
>
> > ./channels/drdynvc/tsmf/tsmf_media.c
> > "/tmp/FreeRDP_Frame_%d.ppm"
>
> As far as we can tell, this code has been in an "#if 0" starting from
> when the code was originally added to FreeRDP in:
>
>   https://github.com/FreeRDP/FreeRDP/commit/dadb94a1e343648503949094a50053d81212a153
>
> In other words, we don't think this code would ever have been
> reachable by an end user. The "#if 0" also apparently exists in the
> freerdp-1.0.2.tar.gz that's included in the
> freerdp-1.0.2-5.el7.src.rpm file.
>
> > ./libfreerdp-gdi/gdi.c
> > #ifdef DUMP_REMOTEFX_TILES
> >                        sprintf(tile_bitmap, "/tmp/rfx/tile_%d.bmp",
>
> As far as we can tell, there is no build option for
> DUMP_REMOTEFX_TILES or documentation recommending that an end user
> define DUMP_REMOTEFX_TILES, either in the upstream distribution or in
> a source RPM.
>
> > Actually it looks like upstream fixed both of them already so one CVE
> > can do (I don't think it's important enough to SPLIT/MERGE properly).
>
> Even if there were a different SPLIT/MERGE process for less important
> cases, a single CVE ID for issues reported in different versions would
> be among the harder process changes because it affects whether (or
> how) the CVE ID could be used on the cve.mitre.org web site, and
> complicates some types of patch-based remediation.

-- 
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Attachment: signature.asc
Description: OpenPGP digital signature