If compression is to be used a custom compression algorithm should be written.
Bitcoin data is largely incompressible outside of a tiny subset of fields. On 12/01/2015 11:33 PM, Simon Liu via bitcoin-dev wrote: > Hi Pavel, > > (my earlier email was moderated, so the list can only see it via your > reply), > > Yes, an attacker could try and send malicious data to take advantage of > a compression library vulnerability... but is it that much worse than > existing attack vectors which might also result in denial of service, > crashes, remote execution? > > Peter, perhaps your BIP can look at possible ways to isolate the > decompression phase, such as having incoming compressed blocks be saved > to a quarantine folder and an external process/daemon decompress and > verify the block's hash? > > Regards, > Simon > > > On 12/01/2015 10:47 PM, Pavel Janík wrote: >>> On 02 Dec 2015, at 00:44, Simon Liu <[email protected]> wrote: >>> >>> Hi Matt/Pavel, >>> >>> Why is it scary/undesirable? Thanks. >> Select your preferable compression library and google for it with +CVE. >> >> E.g. in zlib: >> >> http://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-1820/GNU-Zlib.html >> >> …allows remote attackers to cause a denial of service (crash) via a crafted >> compressed stream… >> …allows remote attackers to cause a denial of service (application crash)… >> etc. >> >> Do you want to expose such lib to the potential attacker? >> -- >> Pavel Janík >> >> >> >> > _______________________________________________ > bitcoin-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
