Subject: [media-types] Internet media type application/tar; request review

From: Sean Leonard <[email-masked]>
Date: Fri, 19 Sep 2014 11:22:58 -0700

To Media Types reviewers:

This is a first draft of a registration request for the Internet media type application/tar, for tar format archives.

Per RFC 6838, I do not believe that this registration requires a formal RFC since it is from a recognized standards organization (IEEE). Nevertheless, it deserves review and discussion prior to the formal request being lodged. Feedback is appreciated.

Registration Template [DRAFT]

Type name: application

Subtype name: tar

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: binary

Security considerations:
TAR (Tape ARchive), as an archive format, can contain arbitrary files of
arbitrary types, including files that are not considered "regular files" (e.g., symbolic links, directories). Some of these files may be executable or contain executable data,
including scripts, that could compromise the security of a computer. Additionally, some files may contain directives such as URIs that, when accessed, can compromise privacy. As POSIX file system
information can be recorded in this format, user and group permissions,
dates, and the like can also be overwritten when the data is extracted. Furthermore, when encoding data in this format, personal data such as user and group permissions from a source computer system can be
surreptitiously included in the format as a method of exfiltrating that data. The format permits extensions ("pax extensions")--these extensions may have their own security risks.

Interoperability considerations:
TAR is a widely-recognized archive format on all modern computer systems, especially those relating to UNIX and the POSIX standards. The format has undergone several iterations; the main current variations are "pax" and "ustar", which are compatible with each other.

Published specification:
POSIX.1-2008, IEEE Std 1003.1-2008 (2013 Edition), IEEE Standard for Information Technology - Portable Operating System Interface (POSIX)" Shell and Utilities - pax - EXTENDED DESCRIPTION - pax Interchange Format, ustar Interchange Format

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html

Applications that use this media type:
pax is the POSIX utility. Most UNIX-compatible implementations also include a utility called tar.
Most software archiving programs of any notoriety process this format; implementations are too numerous to list.

Fragment identifier considerations: N/A

Additional information:

  Deprecated alias names for this type: N/A
  Magic number(s): hex: 75 73 74 61 72 00 30 30, aka
                   US-ASCII: u s t a r NUL 0 0,
                   at octet 257
  File extension(s): tar
  Macintosh file type code(s): N/A

Person & email address to contact for further information:
  Sean Leonard<[email-masked]>
  Andrew Josey <[email-masked]>

Intended usage: COMMON

Restrictions on usage: None.

Author:
The Austin Common Standards Revision Group (CSRG)
The Institute of Electrical and Electronics Engineers (IEEE)
The Open Group

Change controller: CSRG <contacts?>

Provisional registration? (standards tree only): No

---

From: Sean Leonard <[email-masked]>
Date: Sun, 21 Sep 2014 19:36:59 -0700

On 9/19/2014 10:25 PM, "Martin J. Dürst" wrote:
> On 2014/09/20 03:22, Sean Leonard wrote:
>> This is a first draft of a registration request for the Internet media
>> type application/tar, for tar format archives.
>
> I think these should be "None", because N/A suggests "don't know"
>
> Regards,   Martin.

Ok.

Draft 2:

Type name: application

Subtype name: tar

Required parameters: None.

Optional parameters: None.

Security considerations:
TAR (Tape ARchive), as an archive format, can contain arbitrary files of
arbitrary types, including files that are not considered "regular files" 
(e.g., symbolic links, directories). Some of these files may be 
executable or contain executable data,
including scripts, that could compromise the security of a computer. 
Additionally, some files may contain directives such as URIs that, when 
accessed, can compromise privacy. As POSIX file system
information can be recorded in this format, user and group permissions,
dates, and the like can also be overwritten when the data is extracted. 
Furthermore, when encoding data in this format, personal data such as 
user and group permissions from a source computer system can be
surreptitiously included in the format as a method of exfiltrating that 
data. The format permits extensions ("pax extensions")--these extensions 
may have their own security risks.

Interoperability considerations:
TAR is a widely-recognized archive format on all modern computer 
systems, especially those relating to UNIX and the POSIX standards. The 
format has undergone several iterations; the main current variations are 
"pax" and "ustar", which are compatible with each other.

Published specification:
POSIX.1-2008, IEEE Std 1003.1-2008 (2013 Edition), IEEE Standard for 
Information Technology - Portable Operating System Interface (POSIX)" 
Shell and Utilities - pax - EXTENDED DESCRIPTION - pax Interchange 
Format, ustar Interchange Format

Applications that use this media type:
pax is the POSIX utility. Most UNIX-compatible implementations also 
include a utility called tar.
Most software archiving programs of any notoriety process this format; 
implementations are too numerous to list.

Additional information:

Person & email address to contact for further information:
  Sean Leonard <[email-masked]>
  Andrew Josey <[email-masked]>

Intended usage: COMMON

Author:

Change controller: CSRG <[email-masked]>

---

From: Liam R E Quin <[email-masked]>
Date: Sun, 21 Sep 2014 22:48:20 -0400

On Sun, 21 Sep 2014 19:36:59 -0700
Sean Leonard <[email-masked]> wrote:

[...]
> including scripts, that could compromise the security of a computer.

I'm surprised to see no mention of the possibility of overwriting system files on extracting a tar archive; also that device nodes might be included that could then be written to by later resources contained in the same archive. I'm not sure it's necessary to document the issue that an arbitrary tape archive could exhaust one's local storage space.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

---

From: Henrik Andersson <[email-masked]>
Date: Mon, 22 Sep 2014 11:40:39 +0200

> I'm surprised to see no mention of the possibility of overwriting system files on extracting a tar archive; also that device nodes might be included that could then be written to by later resources…
Tars don't offer compression. They are the exception to the rule that
all archive formats offer compression. As such, there is no need for a
disclaimer about the risks of decompression.

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Mon, 22 Sep 2014 12:07:23 +0100

Well, I can't say it is not about time to formalize application/x-tar :)

What about the two most common compressed TAR formats, .tar.gz and .tar.bz2 ?

Would they be registered as application/tar+gz  and application/tar+bz2  ?

On 19 Sep 2014 19:24, "Sean Leonard" <[email-masked]> wrote:
> _______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types

---

From: Henrik Andersson <[email-masked]>
Date: Mon, 22 Sep 2014 14:57:11 +0200

> Would they be registered as application/tar+gz  and application/tar+bz2  ?
I do believe that I covered this already. They are content encodings.

So the headers should be like this:
Content-Type: application/tar
Content-Encoding: gzip

I do not believe that bzip2 has been registered as a content encoding.
It's about time that this is done.

---

From: Paul Libbrecht <[email-masked]>
Date: Mon, 22 Sep 2014 15:31:13 +0200

I'm wondering if this works.
If the http-server and the http-client use the "encoding" gzip, aren't they supposed to make it transparent to the receiver and thus not let the http-client save the file as a .gz (for example a .tar.gz)? I may have overlooked parts of http but that is how I understand it.

It means that if the two agents above want to transmit a "directory.tar.gz" they would need something such as a media-type for tar.gz or? (and probably for tar.bz2).

paul

---

From: "Eric Prud'hommeaux" <[email-masked]>
Date: Mon, 22 Sep 2014 09:34:32 -0400

* Liam R E Quin <[email-masked]> [2014-09-21 22:48-0400]
> I'm surprised to see no mention of the possibility of overwriting system files on extracting a tar archive; also that device nodes might be included that could then be written to by later resources…

iirc, there's a tarbomb attack to symlink X to /etc/passwd and
later in the same archive, untar onto X. dunno if that's been a
vulnerability in the last decade.

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

([email-masked])
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

---

From: Chris Lilley <[email-masked]>
Date: Mon, 22 Sep 2014 15:46:40 +0200

Hello Henrik,

> It's about time that this is done.

How does one register a content encoding? I had a look at

http://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding

which lists the existing ones and says

Registration Procedure(s)
  IETF Review

EXI is a new one, so I looked in that spec for a registration template
but found merely a statement that it was registered
http://www.w3.org/TR/exi/#contentCoding

A pointer to the registration procedure would be welcome.

-- 
Best regards,
 Chris                            mailto:[email-masked]

---

From: Henrik Andersson <[email-masked]>
Date: Mon, 22 Sep 2014 15:57:51 +0200

> A pointer to the registration procedure would be welcome.
Sorry to say it, but I am as lost as you are. I did look for it myself
and I got about as much as you did.

---

From: "Roni Even" <[email-masked]>
Date: Mon, 22 Sep 2014 17:56:45 +0300

Hi,
Look at http://tools.ietf.org/html/rfc7231#section-8.4
Roni

> -----Original Message-----
> From: media-types [mailto:[email-masked]] On Behalf Of Chris
> Lilley
> Sent: 22 September, 2014 4:47 PM
> To: Henrik Andersson
> Cc: [email-masked]
> Subject: [media-types] registering content encodings
> 
> Hello Henrik,
> 
> EXI is a new one, so I looked in that spec for a registration template but
found
> merely a statement that it was registered

---

From: Julian Reschke <[email-masked]>
Date: Mon, 22 Sep 2014 18:43:27 +0200

> and I got about as much as you did.

What about following the link to RFC 7231?

Best regards, Julian

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Tue, 23 Sep 2014 15:18:59 +0100

Yes, which would also ruin any kind of checksums.

Not everyone uses HTTP, and not every HTTP server does the encoding
header (Although I believe Apache does).

For instance if you attach a .tar.gz by email I don't think many email
client would insert the encoding MIME header. If you add the .tar.gz
to some kind of bundle (like our Research Object Bundle [1]) then in
the manifest you would want to describe the file as having the format
(something like) application/x-tar+gz - not a .tar that happens to be
compressed.

[1] https://w3id.org/bundle/

-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718

---

From: Sean Leonard <[email-masked]>
Date: Wed, 24 Sep 2014 15:52:50 -0700

Draft 3:

Type name: application

Subtype name: tar

Security considerations:
TAR (Tape ARchive), as an archive format, can contain arbitrary files of
arbitrary types, including files that are not considered "regular files" 
(e.g., symbolic links, directories). Some of these files may be 
executable or contain executable data,
including scripts, that could compromise the security of a computer. 
Additionally, some files may contain directives such as URIs that, when 
accessed, can compromise privacy. As POSIX file system
information can be recorded in this format, user and group permissions,
dates, and the like can also be overwritten when the data is extracted. 
Extracting a tar file runs the possibility of overwriting system files, 
and device nodes might be included that could be written to by later 
resources in the same archive. If extracted into an existing directory 
instead of a designated new directory, the contents can appear to 
"explode" and make locating existing files difficult (such an archive is 
known as a "tarbomb"). Furthermore, when encoding data in this format, 
personal data such as user and group permissions from a source computer 
system can be surreptitiously included in the format as a method of 
exfiltrating that data. The format permits extensions ("pax 
extensions")--these extensions may have their own security risks.

Published specification:

Additional information:

Intended usage: COMMON

Author: