oss-sec mailing list archives

Re: CVE Request -- Transmission v1.92


From: Josh Bressers <bressers () redhat com>
Date: Thu, 1 Apr 2010 14:41:13 -0400 (EDT)

----- "Jan Lieskovsky" <jlieskov () redhat com> wrote:

Hi Steve, vendors,

   Transmission upstream has recently released latest, v1.92 version:
     [1] http://trac.transmissionbt.com/wiki/Changes

   fixing one (potentially two) security issues:
     a, Fix potential buffer overflow when adding maliciously-crafted
     magnet links

   References:
     [2] http://trac.transmissionbt.com/ticket/2965
     [3] http://trac.transmissionbt.com/wiki/Changes
     [4] http://bugs.gentoo.org/show_bug.cgi?id=309831

Use CVE-2010-0748 for this one. I'm calling it an arbitrary memory write.
It's not really a buffer overflow.


     --

     b, Fix possible data corruption issue caused by data sent by bad
     peers during endgame (this one I am not completely sure of, but when
     looking at the relevant bug record:
     [5] http://trac.transmissionbt.com/ticket/1242
         there is written:
     [6] http://trac.transmissionbt.com/ticket/1242#comment:1
         "My theory is that for some reason Transmission will download a
         corrupt part from someone but not realize it until you do a
         manual verify. At this point T will recognize the bad part and
         redownload it from the same person, which just causes the
         problem again."

         so to prevent someone from successfully downloading content of
         some torrent file, for an attacker to should be enough to
         download a part of it, corrupt it and
         share it. Not sure about the algorithm, Transmission decides
         which torrent
         to retrieve content from, but if it is deterministic /
         predictable behavior / algorithm, such attack could succeed).

   References:
     [7] http://trac.transmissionbt.com/ticket/1242
     [8] http://trac.transmissionbt.com/ticket/1242#comment:1
     [9] http://trac.transmissionbt.com/wiki/Changes


I'm giving this issue a CVE ID too. I think this issue is a bit on the
fence, but given a malicious client could corrupt download data in a manner
that is hard to fix, it should get one.

Use CVE-2010-0749

Thanks.

-- 
    JB


Current thread: