Local Bzip DoS Exploit

[Toast]

i wanna keep this private since it can effect other clients ie. sdc jucy etc so please respect my wishes im gonna give a bzip bomb exploit in this bug report thats still effects DC++ and still effects SDC when transferring.

I know there was a fix for this a while back but it still have some effects me and Sulan tested it on DCDev public if the filelist is transfered no effect but if you open the filelist in DC++ (CTRL + L) and open it the client crashes.

SDC mods crashes upon transfers confirmed via RSX++ and Jucy freezes up.

I supplied the exploit in this bugreport as an attachment try it for yourselves

[Jacek Sieka (arnetheduck)]

It'll be private until a fix is committed, but when that happens I suggest you make the others update asap since it will be trivial to deduce from the commit what is actually happening...

[Toast (swetoast-deactivatedaccount)]

Guess you can make it remote now emtee tested a mock hublist file using that xml file and dcpp crashed so if a rouge hublist where to use a bzip exploit then there would be alot more clients crashing and since adchublist.org has been purchased by a spammer recently its not a total impossibility that such a thing could happen.

since adchublist.org is included in the dcpp.

[eMTee (realprogger)]

Maybe checking for suspicously high compression ratio can be a solution for both filelists and hublists given the fact that usually the ratio do not exceed 3:1 even for text files. An example which is working well for hublists is attached.

[Jacek Sieka (arnetheduck)]

don'ẗ like..
it's probably an out-of-memory somewhere - in any case, the max filelist size could be used for hublists too - only thing remaining is to see why the limit isn't working as it should (for some reason it seems like the limit kicks in too late but I haven't looked into it...

another solution would be to stream the results of the decompressor to the file/hub list reader so that the whole thing doesn't have to be kept in memory...I don't quite remember, but if it first decompresses the whole file to a memory buffer and then decodes the xml, that's wrong...

[poy (poy)]

0.760