Jabber OOB Transfer security issue

[Matt Jones]

You may be right - perhaps there are constraints in place that make
this a situation which is impossible to trigger or exploit, but I've
seen very similar issues in other software over the years and
sometimes they are exploitable - so I think it's safer to just correct
this dangerous construct and not speculate.

When I send through issues here, I'm not saying they are 100%
triggerable or exploitable - they are code constructs I think are very
risky and I would recommend to simply correct them based on my
experience doing security reviews.

On Fri, Sep 20, 2013 at 7:30 PM, Thijs Alkemade <thijsalkemade at gmail.com> wrote:
>
> On 20 sep. 2013, at 03:31, Daniel Atallah wrote:
>
> On Thu, Sep 19, 2013 at 8:23 PM, Matt Jones <matt at volvent.org> wrote:
>>
>> Thanks a lot.
>>
>> Just wondering if CVE's will be organised for the ones which are
>> security related fixes?
>
>
> We generally request CVEs for issues causing arbitrary code execution and
> remote crashes that don't require the user to initiate or accept an
> interaction.
>
> Without looking at the code more than the snippet attached, it looks this
> particular issue is only triggered after a user has accepted a file
> transfer, unless it can be used to cause arbitrary code execution (I haven't
> looked at it closely enough to tell if that's the case or not), it probably
> wouldn't get a CVE.
>
>
> I don't think this can cause a crash. The only place where size is used is
> as an argument to purple_xfer_set_size(), which would immediately cast it to
> a size_t (which is unsigned). Of course someone could specify -1 to get
> libpurple to initiate a filetransfer for a 2^64 - 1 (on 64bit) byte file,
> but there should be other safeguards against that (at the latest the OS not
> letting you allocate a 18 EB file).
>
> It's sloppy code, yes, but I don't think it's a security issue.
>
> Thijs