Re: [art] Request for review of draft-diaz-lzip-07

Antonio -

I notice this in "Security Considerations"

> Lzip is a compressed format. Decompressing lzip data may expand them
 to a size more than 7000 times larger, risking an out-of-memory or
out-of-disc-space condition.

If you look at the corresponding "Security Considerations" for brotli,
another compression algorithm described in RFC 7932 (July 2016),
there is a much longer set of concerns expressed and risks from that
format related to malicious or corrupted content. For example, I'd
characterize the RFC 7932 concerns as being:

"buffer overflow triggered by invalid compressed data" p40

"system's resource consumption (CPU, memory, or storage)
to be disproportionately large compared to
the size of the compressed data" p40

"exploit a buffer overflow or cause disproportionately large resource
consumption by providing, e.g., uncompressible data." p41

"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." p41

Based on Brotli's concerns, I'd ask:

1) Are there sample files that implementations could use to
test against inadvertent or deliberate corruption in the file data?

2) Are there sample files that could be used to test the "7000x expansion"
case, so that implementations could check against them? I worry
about this with DDOS-style amplification attacks, where a 7000x
expansion in bytes on an attacking stream is way bigger than
the 200x that NTP amplification attacks can present.

3) Under what circumstances is lzip data incompressible,
and how does the reference implementation behave in
those circumstances? Does compression ever make a pathological
file way larger than the original?

thanks

Ed

On Mon, Apr 24, 2023 at 11:59 AM Antonio Diaz Diaz <antonio@gnu.org> wrote:

> Dear all,
>
> Not having received any answer in 3.5 years to my request for review of
> draft-diaz-lzip-00[1], I request now the review of draft-diaz-lzip-07[2]
> in
> the hope of having more luck this time.
>
> Along these years I have received feedback from several people and have
> fixed several minor issues. I think the draft is now ready for review.
>
> [1] https://mailarchive.ietf.org/arch/msg/art/ZuX1_G6rLsuoH04JNjJuD2rQ318/
> [2] https://datatracker.ietf.org/doc/draft-diaz-lzip/
>
>
> Thanks,
> Antonio Diaz.
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>

-- 
Edward Vielmetti +1 734 330 2465
edward.vielmetti@gmail.com