Quoting [EMAIL PROTECTED] from ml.softs.gtk-gnutella.devel: :I haven't looked at the sources recently but I wondered whether GTKG :applies resp. can apply a limit to the (de)compressed size of packets. :As you know, Glib/GTK+ is a bitch *woof* when it comes to malloc failures :so it would be very likely you can crash GTKG this way if it didn't.
When decompressing data from Gnet, we do that in a fixed-size buffer before passing the received data to the node layer. Which will bail out when the maximum message size is reached anyway, so we're safe here, I'd say. Decompression of GGEP deflated data is always done in a fixed-size buffer as well. As for decompression of QRT compressed data, we do that ad infinitum until we reach the advertised patch length, at which point we'll bail out. Here are the calls to inflate: File Function Line 0 ggep.c ggep_inflate 125 ret = inflate(inz, Z_SYNC_FLUSH); 1 ggep.c ggep_inflate_into 218 ret = inflate(inz, Z_FINISH); 2 qrp.c qrt_handle_patch 2571 ret = inflate(inz, Z_SYNC_FLUSH); 3 rx_inflate.c inflate_data 88 ret = inflate(inz, Z_SYNC_FLUSH); The ggep_inflate() routine is unused currently, and hopefully so because that one would be vulnerable: it keeps realloc'ing the target buffer where decompressed data is put and will not return until it got everything decompressed! Based on that assessment, which I invite everyone to review in greater details, I believe it is safe to say that GTKG is not vulnerable to decompression bombs. Raphael ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
