"This fixes 2 security vulnerabilities in KTorrent. It would be advisable to upgrade to this release." See also http://cia.navi.cx/stats/project/kde/ktorrent: 19:03 Thursday KDE Commit by guisson :: r640661 ktorrent/trunk/extragear/network/ktorrent/ (4 files in 2 dirs): Fix 2 security vulnerabilities, both were discovered by Bryan Burns of Juniper Networks
thanks for your report. Adding maintainer for when he is back.
*** Bug 170047 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 170727 ***
I think that this one should be kept open.
I'll try to do it tonight, but no promises... I still have to configure my wireless network here in Barcelona, Spain.
*** Bug 170727 has been marked as a duplicate of this bug. ***
Unlike some other distros, we don't mark all security bugs as critical :) http://www.gentoo.org/security/en/vulnerability-policy.xml tells that this kind of vulnerabilities should be rated "minor". A "critical" bug must be solved within 3 days only! :)
Ebuild in CVS. Arches please stabilize asap.
x86 stable
ppc64 stable
sparc stable.
ppc stable
amd64 done
I think all arches have marked it stable. What's the next step?
This one is ready for GLSA vote.
Upstream didn't even bother to mention it in ChangeLogs. http://websvn.kde.org/?view=rev&revision=640661 http://www.ubuntu.com/usn/usn-436-1 According to the Ubuntu advisory this could lead to the remote execution of arbitrary code or did they fix another problem?
In the patch I see two things - one is protecting a counter in ChunkCounter.cpp from going beyond another size value. The other actually has a comment that indicates the change was to protect against directory traversal. I vote yes for GLSA based on Kees' advisory.
The directory traversal fix is incomplete. Cases such as '../' being inserted into a bnode string in the path sequence will pass the filter they put in place (which only checks if each string node is == ".."). I've verified this against 2.1.2 in the tree. Deathwing00 can you contact upstream and see if we can get a better fix? There's a pretty large number of cases that need to be checked - my suggestion would be a "whitelist" of allowed characters in the strings that specify paths.
Thx Matt. Resetting to upstream status until we have a better fix.
Upstream: http://bugs.kde.org/show_bug.cgi?id=143637
Version 2.1.3 in CVS.
Arches please test and mark stable. Target keywords are: ktorrent-2.1.3.ebuild:KEYWORDS="amd64 ppc ppc64 sparc x86 ~x86-fbsd"
CVE-2007-1384 Directory traversal vulnerability in torrent.cpp in KTorrent before 2.1.2 allows remote attackers to overwrite arbitrary files via ".." sequences in a torrent filename. CVE-2007-1385 chunkcounter.cpp in KTorrent before 2.1.2 allows remote attackers to cause a denial of service (crash) and heap corruption via a negative or large idx value.
Name: CVE-2007-1799 Directory traversal vulnerability in torrent.cpp in KTorrent before 2.1.3 only checks for the ".." string, which allows remote attackers to overwrite arbitrary files via modified ".." sequences in a torrent filename, as demonstrated by "../" sequences, due to an incomplete fix for CVE-2007-1384.
Once again: ppc stable
Stable on amd64.
This one is ready for GLSA decision. I vote NO.
voting NO.
i vote yes because i think it's easy to trick a user into browsing his own malicious torrent.
I also vote yes - too easy to get a malicious torrent where someone could download it, and it basically gives an attacker write access to any of the user's files.
changing status and submitting GLSA request.
GLSA 200705-01, thanks everybody
