[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] CVE Request -- Transmission v1.92
From:       Jan Lieskovsky <jlieskov () redhat ! com>
Date:       2010-03-17 17:22:20
Message-ID: 4BA10FCC.8050104 () redhat ! com
[Download RAW message or body]

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

     --

     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

Could you allocate CVE id(s) for this / these issue(s)?

Thanks && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team


[prev in list] [next in list] [prev in thread] [next in thread]