Don Cragun <don.cragun at sun.com> wrote: > >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.
> 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. Nothing in this quote prevents to disallow the extraction of files with absolute path names by default for security reasons. > 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'')." Nothing in this quote prevents to disallow the extraction of files with absolute path names by default for security reasons. > 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. To understand the text you quote, you need to read this before: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html The POSIX standard explicitly allows/requires to base file creation on permissions and on security policies. It is obvious that security policies have a higher precedence than not fully qualified utility descriptions. > 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 Besides the fact that using -x in extract mode may cause problems, this does not solve the security issues I was talking about. It is interesting to see that you now try to think in the pax philosogy while this ARC case ignores the pax philosohy. We did mention a methods thay better fit the pax philosophy for the purpose of this ARC case. How could this happen? > >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. A secure archiver implementation grants you that if you extract an archive into an empty directory, no file outside this directory will be harmed. Star is by default nearly fully secure and fully secure if you specify the option "-secure-links". The archivers provided by Sun are not security aware by amy means. Insisting in having a highly vulnerable system does not look promising. > >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. The current tar/cpio/pax implementations from the star package adhere to standards. If you believe that you found a bug, file a bug description and give evidence for claiming that there is a bug. > 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 Please do not claim that star violates the standard without proving it. > >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. I did not call you a liar, so it seems that you are trying to become personal..... I did do my homework, you have not been able to prove your POSIX related claims - sorry. > 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 "I have a gun" is no argument in a technical based discussion. 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
