File corruption vulnerabilities in DC++ and based clients
May 30, 2010 Leave a comment
The latest stable release of DC++ fixes a long standing problem in error handling during downloads. This bug can cause file corruption, crashes and even a moderately critial security vulnerability. Most probably the problem exists in all DC++ versions released since Tiger based integrity check and file identification has been introduced. This also means that the bug should affect all clients based on DC++ libraries older than version 0.762.
In short, the problem arises when any kind of errors happen during downloading of the last chunk of data of a file (the data corresponding to the last TTH leaf of the Tiger tree). The error handling is incorrect in this case and despite the actual error the download will be finished without any warning. Everything happens like in case of any successful download: the corresponding queue item will be removed from (or depending on the setting marked as finished in) the download queue as well as the (likely corrupted) unfinished file will be moved from the unifinished downloads to the finished downloads folder.
However, the queue item removal is not done properly in this particular case; this can lead to (not necessarily immediate) crashes or freezes, especially in the newer DC++ versions. So above the possibility of getting corrupted files marked as successful downloads, if you download from a malicious client that produces specially crafted data flow it can cause further instability or even DOS.
Additionally, this problem can be used to spread fake files over the DC network since when none of the download sources are able to produce a full tiger tree for the downloaded file a special spare integrity check is done after the download finished. Without having the full Tiger tree, integrity check is done by TTH only after the file has been fully downloaded. Because of the same bug described above, even if this TTH check fails, the downloaded file will be saved to its target location without any indication of errors.
This means that searching for a known trusted file by TTH is not safe in DC as long as you don’t use the latest client versions. Rogue clients can easily create fake file lists or respond so they share the file you searching for (and known harmless by TTH). If these malicious sources refuse the query for the full Tiger tree then any file of the given size but arbitrary content will be accepted from them without showing any error message. Successful exploitation needs that no other sources provide the correct full tree before the download starts.
This problem exists in almost all clients based on TTH capable versions of DC++. The oldest tested and vulnerable version is DC++ 0.4032. The bug can be reproduced with various clients using current and former download manager implementations (the original DC++ single source, RevConnect based multi-source and current DC++ multi-source are among them). Some client versions like StrongDC++ 2.21 and above (and its derivatives) are the only exceptions; these clients do not accept files with wrong TTHs due to tentative fixes made by Big Muscle to avoid this problem (but they still can crash the way written above).
Client versions contain fix for all the three problems are DC++ 0.762, StrongDC++ 2.41 and any client based on these. As always, upgrade is recommended as soon as possible.