Skip to main content

12. Security Considerations, IANA Considerations, and References

  1. Security Considerations

As with any compressed file formats, decompressor implementations should handle all compressed data byte sequences, not only those that conform to this specification, where non-conformant compressed data sequences should be rejected as invalid.

A possible attack against a system containing a decompressor implementation (e.g., a web browser) is to exploit a buffer overflow triggered by invalid compressed data. Therefore, decompressor implementations should perform bounds-checking for each memory access that result from values decoded from the compressed stream and derivatives thereof.

Another possible attack against a system containing a decompressor implementation is to provide it (either valid or invalid) compressed data that can make the decompressor system's resource consumption (CPU, memory, or storage) to be disproportionately large compared to the size of the compressed data. In addition to the size of the compressed data, the amount of CPU, memory, and storage required to decompress a single compressed meta-block within a brotli stream is controlled by the following two parameters: the size of the uncompressed meta-block, which is encoded at the start of the compressed meta-block, and the size of the sliding window, which is encoded at the start of the brotli stream. Decompressor implementations in systems where memory or storage is constrained should perform a sanity-check on these two parameters. The uncompressed meta-block size that was decoded from the compressed stream should be compared against either a hard limit, given by the system's constraints or some expectation about the uncompressed data, or against a certain multiple of the size of the compressed data. If the uncompressed meta-block size is determined to be too high, the compressed data should be rejected. Likewise, when the complete uncompressed stream is kept in the system containing the decompressor implementation, the total uncompressed size of the stream should be checked before decompressing each additional meta-block. If the size of the sliding window that was decoded from the start of the compressed stream is greater than a certain soft limit, then the decompressor implementation should, at first, allocate a smaller sliding window that fits the first uncompressed meta-block, and afterwards, before decompressing each additional meta-block, it should increase the size of the sliding window until the sliding window size specified in the compressed data is reached.

Correspondingly, possible attacks against a system containing a compressor implementation (e.g., a web server) are to exploit a buffer overflow or cause disproportionately large resource consumption by providing, e.g., uncompressible data. As described in Section 11.1, an output buffer of

S(N) = N + (3 * (N >> 16) + 5)

bytes is sufficient to hold a valid compressed brotli stream representing an arbitrary sequence of N uncompressed bytes. Therefore, compressor implementations should allocate at least S(N) bytes of output buffer before compressing N bytes of data with unknown compressibility and should perform bounds-checking for each write into this output buffer. If their output buffer is full, compressor implementations should revert to the trivial compression algorithm described in Section 11.1. The resource consumption of a compressor implementation for a particular input data depends mostly on the algorithm used to find backward matches and on the algorithm used to construct context maps and prefix codes and only to a lesser extent on the input data itself. If the system containing a compressor implementation is overloaded, a possible way to reduce resource usage is to switch to more simple algorithms for backward reference search and prefix code construction, or to fall back to the trivial compression algorithm described in Section 11.1.

A possible attack against a system that sends compressed data over an encrypted channel is the following. An attacker who can repeatedly mix arbitrary (attacker-supplied) data with secret data (passwords, cookies) and observe the length of the ciphertext can potentially reconstruct the secret data. To protect against this kind of attack, applications should not mix sensitive data with non-sensitive, potentially attacker-supplied data in the same compressed stream.

  1. IANA Considerations

The "HTTP Content Coding Registry" has been updated with the registration below:

+-------+-------------------------------------+------------+ | Name | Description | Reference | +-------+-------------------------------------+------------+ | br | Brotli Compressed Data Format | RFC 7932 | +-------+-------------------------------------+------------+

  1. Informative References

[HUFFMAN] Huffman, D. A., "A Method for the Construction of Minimum Redundancy Codes", Proceedings of the Institute of Radio Engineers, September 1952, Vol. 40, No. 9, pp. 1098-1101.

[LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for Sequential Data Compression", IEEE Transactions on Information Theory, Vol. 23, No. 3, pp. 337-343, DOI 10.1109/TIT.1977.1055714, May 1977, <https://www.cs.duke.edu/courses/spring03/cps296.5/papers/ ziv_lempel_1977_universal_algorithm.pdf>.

[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, http://www.rfc-editor.org/info/rfc1951.

[WOFF2] Levantovsky, V., Ed., and R. Levien, Ed., "WOFF File Format 2.0", W3C Candidate Recommendation, March 2016, http://www.w3.org/TR/WOFF2/.

Source: RFC 7932 Official Text: https://www.rfc-editor.org/rfc/rfc7932.txt

Last updated on