Comment 38 for bug 401028

This bug is actually a DoS vulnerability in the way papyon handles MSNObject data in p2p.py.

There is no exception handling for malformed fields, such as the SHA1C in the bug filer's case. It tries to base 64 decode whether or not the string is properly encoded in base 64. If it isn't, it will crash silently with a traceback in the logs. The user will continue thinking he is talking to the person with the malformed checksum, but in reality, no messages will be sent or received.

More importantly, while going over this code, it appears that the checksum isn't even used when sending or receiving, yet it is stored in the object. If this is the intent, then malformed field exceptions should be ignored and a warning logged instead of crashing. However, it would be best if papyon verified the integrity of the fields and then compared checksums (just like what is done for the SHA1D). If the checksums do not match or the fields are malformed, then notify the user and drop the object from further processing.

I can kind of see the methodology behind what is being done now. The data hash is being checked and compared for integrity, and that's all you care about - the data. If this is the case and you see the checksum as redundant, then at least handle malformed ones by ignoring them instead of crashing on a bash 64 decode.