>Date: Thu, 16 Aug 2007 12:35:47 +0200
>From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
>Subject: Re: CIFS system attributes support for cpio(1), pax(1), tar(1)
[PSARC/2007/459 FastTrack timeout 08/17/2007]
>
>Don Cragun <don.cragun at sun.com> wrote:
>
>> >Date: Wed, 15 Aug 2007 19:50:25 +0200
>> >From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
>> >
>> ... ... ...
>> >
>> >If interface stability is really important for OpenSolaris, then tar(1),
>> >cpio(1) and pax(1) cannot implement an incomatible way of handling the -/
>> >option. The option -/ (introduced in 1994) has the following meaning:
>> >
>> > -/ Don't strip leading slashes from file names when
>> > extracting an archive. Tar archives containing abso-
>> > lute pathnames are usually a bad idea. With other tar
>> > implementations, they may possibly never be extracted
>> > without clobbering existing files. Star for that rea-
>> > son, by default strips leading slashes from filenames
>> > when in extract mode. As it may be impossible to
>> > create an archive where leading slashes have been
>> > stripped while retaining correct path names, star does
>> > not strip leading slashes in create mode.
>>
>> J?rg,
>> The only way these four cases (PSARC/2007/459 [cpio, pax, &
>> tar], 423 [compress, cp, pack, uncompress, & unpack], 410 [chmod], and
>> 394 [ls]) create any incompatibility with star is if star is intended
>> to replace cpio, pax, or tar. When you chose to add -/ to star, you
>> guaranteed that star could NEVER replace tar, cpio, or pax in /usr/bin
>
>This is if course incorrect: When _you_ chose to add -/ to Sun's current
>tar/cpio/pax implementation, you plan to boycott a possible future integration
>of an star based implemention to replace the old Sun programs. This is because
>_you_ chose to deliberately add an incompatible interface.
>
>> (which supply behavior conforming to SVID3, XPG3, XPG4, SUS, SUSv2,
>> SUSv3 and all of the POSIX standards). Stripping leading slashes from
>> absolute pathnames (by default) as files are extracted from archives
>> violates standards requirements for all of these utilities.
>
>This is a hazardous claim. I know of no part of the POSIX standard that
>prevents tar/cpio/pax from implementing a security aware behavior by default.
>It seems that you also know this - otherwise you could give a pointer that
>proves your claim.
As we all know, the POSIX standards never described the behavior of the
tar and cpio utilities; they only specify the cpio c_magic=="070707"
(pax -x cpio, Sun cpio -H odc, and Sun cpio -[io] -c) and tar ustar
(pax -x ustar and Sun tar without the E and @ function modifiers)
archive formats.
The descriptions of cpio in SVID3 (Volume V, pages 8-2 through 8-4),
XPG3 (Volume 1, pages 74 through 76), XPG4 (Commands and Utilities
Volume, pages 219-222), SUS (Commands and Utilities Volume, pages 219
through 222), SUSv2 (Commands and Utilities Volume, pages 226-229) all
say essentially the same thing (the following quote is from SUSv2) in
the description of the -i option:
"(Copy in.) Extract files from the standard input, which is
assumed to be the product of a previous cpio -o. Only files
with names that match patterns are selected. The extracted
files are conditionally created and copied into the current
directory tree based on the options described below. The
permissions of the files will be those of the previous cpio
-o. The owner and group of the files will be that of the
current user unless the user has appropriate privileges, which
causes cpio to retain the owner and group of the files of the
previous cpio -o. If the archive being read does not match the
modifier specified**1, cpio may consider this an error and exit
or may recognise the archive and continue processing. Only a
user with appropriate privileges can extract block special or
character special files from an archive."
**1 This refers to the presence or absence of the c modifier which
specifies whether or not character mode headers (as defined by
POSIX) or binary mode headers are used. SVID3 specifies -H odc,
-H crc, -H tar, and -H ustar formats as well as the -c option.
Nothing in the description of cpio nor any of its options or option
modifiers in these standards allow cpio to arbitrarily change the
pathname of a file being extracted from an archive. Sun's cpio does
add a -r option allowing files to be interactively renamed as they are
extracted.
I won't quote the references for tar in SVID3, XPG3, XPG4, SUS, or
SUSv2, but the requirements for arbitrarily renaming files on
extraction are the same (i.e., it is not allowed unless you add an
option that enables renaming or define a new archive format that makes
all absolute pathnames relative to the CWD).
For the pax utility, POSIX.2-1992, XPG4, SUS, SUSv2, and
SUSv3/POSIX.1-2001 the requirements are (quotes from SUSv3/POSIX.1-2001
with corrigenda 1 and 2 applied):
XCU6, P698, L26888-26893 (first part of pax utility description
of read mode):
"In read mode (when -r is specified, but -w is not), pax
shall extract the members of the archive file read from
the standard input, with pathnames matching the
specified patterns. If an extracted file is of type
directory, the file hierarchy rooted at that file shall
be extracted as well. The extracted files shall be
created performing pathname resolution with the
directory in which pax was invoked as the current
working directory."
XBD6, P100, L3136-3142 (second paragraph of the description of
the General Concept "Pathname Resolution"):
"Each filename in the pathname is located in the
directory specified by
its predecessor (for example, in the pathname fragment
a/b, file b is located in directory a). Pathname
resolution shall fail if this cannot be accomplished.
If the pathname begins with a slash, the predecessor of
the first filename shall be taken to be the root
directory of the process (such pathnames are referred
to as ``absolute pathnames''). If the pathname does
not begin with a slash, the predecessor of the first
filename of the pathname shall be taken to be the
current working directory of the process (such
pathnames are referred to as ``relative pathnames'')."
So the standards clearly require that absolute pathnames extracted from
archives by pax have / as their parent directory; not the current
directory unless you use an option that changes this default behavior.
The standard provides an option that mimics star's default behavior.
When extracting files from an archive, three ways to specify it would
be:
pax -r -s ",^/,," -x cpio < cpio_archive
pax -r -s "/^\///" -x pax < pax_archive
pax -r -s "x^/xx" -x ustar < ustar_archive
>
>In fact, the behavior of the current Sun implementaions for tar/cpio/pax
>allow people to easily attack the integrity of Solaris installation by adding
>simple hand-crafted changes into tar or cpio archives that are going to be
>unpacked by the administrator with sufficient privileges.
If an administrator copies files onto his or her system without
verifying what files are being copied, the underlying system will
always be vulnerable.
>
>Star and it's different CLI implementations just care anbout vulnerability
>issues from hand crafted archives or archives that have been created in a
>problematic way by accident, the current Sun implementations of the same
>programs ignore this problem.
The current Sun implementations adhere to the standards. If you
believe this is a serious security flaw in pax, you should file an
interpretation request to The Austin Group and suggest changes that
need to be made to the standard to avoid the issue. If you want a fix
for this to get into the next revision of the standard, you have until
the end of this month to file the interpretation request.
>
>
>> Since star cannot replace tar, cpio, or pax without changing
>> the default behavior of star and the meaning of the -/ option as it has
>> been defined by star for the last 13 years, I see no reason why -% and
>> -/ cannot behave as described in these four PSARC cases without causing
>> any incompatibilities to the existing star nor to possible future star
>> enhancements described in PSARC/2004/480.
>
>This is of course incorrect. Pleae inform yourself about the star project
before
>trying to judge. The optins -/ and -.. are _needed_ in star's CLI emulations
>for the Sun programs in case that someone needs to switch off the "security
>by default" behavior. If Sun did introduce the incompatible meaning of -/,
>either integration of star based implementaions would be boycotted or these
>programs would need to become unstable just from the will of the Sun PSARC
>commitee.
I don't need to inform myself anymore about the star project. The fact
that star violates the standard by modifying the pathnames of extracted
files means that star can't be renamed /usr/bin/tar and maintain
standards conformance. If you would have reversed the meaning of -/
when you created it (i.e., -/ would cause absolute pathnames to be
treated as relative and would ignore any pathnames that used .. to get
above the CWD when extracting files from an archive), it would have
made sense for the project teams to hunt for a different option
letter. Since star ignored the standards when -/ was added and changed
the default behavior to be something that does not conform to the
standards, compatibility with star's definition of -/ didn't seem
important to either of the project teams that filed the four cases in
question.
>
>Going OpenSource with Solaris and trying to benefit from other OpenSource
>Software cannot be seen for serious in case that Sun claims that interface
>stability is important but at the same time ignores interface stability.
>If you like to retain interface stability, you need to follow the following
>rules:
>
>- Interfaces need to be defined in a way that allows them to be stable
> for a long time. This is true for star.
>
>- If there are possible conflicts with newer programs (like the current
> Sun implementations for tar/cpio/pax) the only way to retain interface
> stability is to use the "first come first serve" rule.
>
> The Option -/ has already been in use by star for a long time
> _and_ you have been warned about the problem _before_ you started
> to introduce incompatibility.
>
> If you introduce -/ for Sun's tar/cpio/pax, you try to prevent other
> software (with older rights) from retaining CLI long term stability.
>
>Now, please do your homework....
I have done my homework. You have called me a liar and you have said I
don't know the standards. Please do your homework and quote text in
any of the standards I mentioned above that allow cpio, pax, and tar to
arbitrarily change the pathnames of files being extracted from archives.
Sincerely,
Donald W. Cragun
Chair of the IEEE PASC Shell and Utilities Working Group
Member of the IEEE PASC Sponsor Executive Committee
IEEE PASC's Organizational Representative to The Austin Group
Sun's primary representative to The Open Group's Base Working Group
>
>J?rg
>
>--
> EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353
> Berlin
> js at cs.tu-berlin.de (uni)
> schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
> URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
