Re: [ietf-types] Request for registration of application/gzip and application/zlib

"John R. Levine" <johnl@iecc.com> Thu, 23 February 2012 06:29 UTC

Return-Path: <johnl@iecc.com>
X-Original-To: ietf-types@ietfa.amsl.com
Delivered-To: ietf-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B8211E8083 for <ietf-types@ietfa.amsl.com>; Wed, 22 Feb 2012 22:29:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.354
X-Spam-Level:
X-Spam-Status: No, score=-102.354 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGYEm7wUQ8p3 for <ietf-types@ietfa.amsl.com>; Wed, 22 Feb 2012 22:29:14 -0800 (PST)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C1F5411E807F for <ietf-types@ietf.org>; Wed, 22 Feb 2012 22:29:13 -0800 (PST)
Received: (qmail 54509 invoked from network); 23 Feb 2012 06:29:12 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=d4ec.4f45dcb8.k1202; bh=fEo7RCwac/EtZnZMLjDJ4+qgJVxLE1vjMV9A1g2uPoQ=; b=L2Fpjj+ZPIB1U7JnQ8UO5nH1gTALxcckrAcR9qqZwhy1zOW4M0WXO3CIwCwMsdoYqWWjnUhafFQNXrefmmDz0cIZB64UAn3+POvNxF4rEB1nHJdxXWHi3ytwtOiejzzgbI5LfvoYG9WLQ6wo06BNGLtQjO+WHILM/wPMt2F6zig=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Feb 2012 06:28:49 -0000
Date: 22 Feb 2012 22:29:10 -0800
Message-ID: <alpine.BSF.2.00.1202222217320.25884@joyce.lan>
From: "John R. Levine" <johnl@iecc.com>
To: "Bjoern Hoehrmann" <derhoermi@gmx.net>
In-Reply-To: <ctrak7l80s1o4313m2h77b5rojji28j055@hive.bjoern.hoehrmann.de>
References: <alpine.BSF.2.00.1202211047280.29127@joyce.lan> <7bv7k75ur1utsvkk8jvdlp47tt8nuab9e6@hive.bjoern.hoehrmann.de> <01OC9QB5028200ZUIL@mauve.mrochek.com> <ctrak7l80s1o4313m2h77b5rojji28j055@hive.bjoern.hoehrmann.de>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: ietf-types@ietf.org
Subject: Re: [ietf-types] Request for registration of application/gzip and application/zlib
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Feb 2012 06:29:14 -0000

>> ???? These are binary formats, plain and simple. There's no encoding included
>> in them that would result in line-oriented output.
>>
>> I don't mind changing the wording to simply say "binary" if that is clearer,
>> but "8bit" is flat-out incorrect.

I think I'll leave the current wording.

>>>>       Magic number(s): first byte is usually 0x78 but can also be 0x08,
>>>>       0x18, 0x28, 0x38, 0x48, 0x58, or 0x68.
>>
>>> This is confusing.
>>
>> Then suggest text. Not sure how else you can say this.
>
> I have not checked whether the above is all that can be said, ...

Why not?  It's RFC 1950, section 2.2.

>>>> 4.  Security Considerations
>>>>
>>>>    Zlib and gzip compression can be used to compress arbitrary binary
>>>>    data such as hostile executable code.  Also, data that purports to be
>>>>    in zlib or gzip format may not be, and fields that are supposed to be
>>>>    flags, lengths, or pointers, could contain anything.  Applications
>>>>    should treat any data with due scepticism.
>>
>>> I would prefer simply referencing the two format RFCs, the types as such
>>> do not introduce additional security considerations.

The draft does reference the two format RFCs.

>> This may need to be reworded to make it clearer, but AFAIK the point that these
>> formats decode automatically in some contexts and are therefore sometimes used
>> to get hostile code past overly simplistic scans is not mentioned in those
>> documents and *is* a known security concern. As such, it needs to be mentioned.
>
> That is something the format RFCs should discuss, it's not a media type
> issue. With HTTP for instance you do not have automatic decompression
> based on the media type, but rather in a separate mechanism.

Beyond the fact that the format RFCs were written 15 years ago and aren't 
going to change, the issue here is that MIME parts can be mislabelled. 
Zlib and gzip have an internal structure with pointers and table lookups, 
so data that claims to be zlib but isn't quite could provoke buffer 
overruns and other security holes.

By the way, HTTP has exactly the same vulnerability, since HTTP has gzip 
and deflate content codings.  See RFC 2616, sec 3.5.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly