Fix zip bomb exploit for decompressing file fragments

[Splatt581]

At this point, an attacker can still attack the server with a zip bomb using file fragments. Video proof:
https://www.youtube.com/watch?v=QWHxdTwzZVM

This pr fixes this vulnerability.

[SergeyShorokhov]

You did something wrong with the commits, the changes are not displaying correctly, could you please fix it?

[Splatt581]

Seems its done.

[Garey27]

Can you also add check for uncompressed file size that transmitted? For example client is dropped with customization i attached.

tempdecal.zip

[Splatt581]

Can you also add check for uncompressed file size that transmitted? For example client is dropped with customization i attached.

tempdecal.zip

Yeah, I also recently encountered custom logos with max decompression ratios that exceed the allowed values. For example, your logo has max ratio of 85.91. So far I see the following solutions:

1. Increasing the sv_net_incoming_decompression_max_ratio cvar to 90. Of course, this may make the server more vulnerable to a zip bomb attack, I haven't tested it yet.

2. Maybe make max ratio for file fragments a separate cvar, something like sv_file_incoming_decompression_max_ratio? Because there is much more scope for manipulating file contents than with regular network messages.

3. Maybe we should introduce a warning system, something like sv_net_incoming_decompression_max_warns? To skip the firsts false-positive compressed data that the client sends (basically, as far as I remember, the client compresses only the logo decal of the file before sending, it doesn't even compress clc_fileconsistency).

What do you think about this?

[Splatt581]

Fixed in this commit 64c684a