* security risk in source builtin? @ 2003-09-16 14:58 Dominik Vogt 2003-09-17 6:58 ` Thomas Köhler [not found] ` <20030917102420.GA2522@mail.guild.uwa.edu.au> 0 siblings, 2 replies; 7+ messages in thread From: Dominik Vogt @ 2003-09-16 14:58 UTC (permalink / raw) To: Zsh Users A colleague and I just noticed that the "source" builtin looks for its argument in the $PATH. I guess that's something POSIX demands, but isn't it also a security risk? In this case, the following happened: $ ls -F test $ cat test echo hello world $ source test /usr/bin/test:3: bad pattern: ^@^F^@(... Unless it is really important to have this behaviour for compatibility reasons, shouldn't searching the $PATH be at least disabled by default? Ciao Dominik ^_^ ^_^ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: security risk in source builtin? 2003-09-16 14:58 security risk in source builtin? Dominik Vogt @ 2003-09-17 6:58 ` Thomas Köhler 2003-09-17 7:35 ` Dominik Vogt [not found] ` <20030917102420.GA2522@mail.guild.uwa.edu.au> 1 sibling, 1 reply; 7+ messages in thread From: Thomas Köhler @ 2003-09-17 6:58 UTC (permalink / raw) To: Zsh Users [-- Attachment #1: Type: text/plain, Size: 2416 bytes --] Dominik Vogt wrote [2003/09/17]: > A colleague and I just noticed that the "source" builtin looks for > its argument in the $PATH. I guess that's something POSIX > demands, but isn't it also a security risk? In this case, the > following happened: > > $ ls -F > test > $ cat test > echo hello world > $ source test > /usr/bin/test:3: bad pattern: ^@^F^@(... Are you really sure you typed "source" here? > Unless it is really important to have this behaviour for > compatibility reasons, shouldn't searching the $PATH be at least > disabled by default? Quoting the manpage: source file [ arg ... ] Same as ., except that the current directory is always searched and is always searched first, before directo- ries in $path. Testing myself: /tmp> cat test echo hello world /tmp> ls -l test -rw-r--r-- 1 jean-luc jean-luc 17 2003-09-17 08:49 test /tmp> . test /usr/bin/test:12: parse error near `)' /tmp> source test hello world Seems you have typed ". test" :-) . file [ arg ... ] Read commands from file and execute them in the current shell environment. If file does not contain a slash, or if PATH_DIRS is set, the shell looks in the components of $path to find the directory containing file. Files in the current directory are not read unless `.' appears somewhere in $path. If a file named `file.zwc' is found, is newer than file, and is the compiled form (created with the zcompile builtin) of file, then commands are read from that file instead of file. If any arguments arg are given, they become the positional parameters; the old positional parameters are restored when the file is done executing. The exit status is the exit status of the last command executed. > Ciao > > Dominik ^_^ ^_^ Ciao, Thomas -- Thomas Köhler Email: jean-luc@picard.franken.de | LCARS - Linux <>< WWW: http://jeanluc-picard.de | for Computers IRC: jeanluc | on All Real PGP public key available from Homepage! | Starships [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: security risk in source builtin? 2003-09-17 6:58 ` Thomas Köhler @ 2003-09-17 7:35 ` Dominik Vogt 2003-09-17 12:42 ` Phil Pennock 0 siblings, 1 reply; 7+ messages in thread From: Dominik Vogt @ 2003-09-17 7:35 UTC (permalink / raw) To: Zsh Users On Wed, Sep 17, 2003 at 08:58:02AM +0200, Thomas Köhler wrote: > Dominik Vogt wrote [2003/09/17]: > > A colleague and I just noticed that the "source" builtin looks for > > its argument in the $PATH. I guess that's something POSIX > > demands, but isn't it also a security risk? In this case, the > > following happened: > > > > $ ls -F > > test > > $ cat test > > echo hello world > > $ source test > > /usr/bin/test:3: bad pattern: ^@^F^@(... > > Are you really sure you typed "source" here? I may have confused the test cases for bash and zsh. Thanks for pointing that out. However, that does not change my concern that "source" (as well as ".") is a security risk. > > Unless it is really important to have this behaviour for > > compatibility reasons, shouldn't searching the $PATH be at least > > disabled by default? > > Quoting the manpage: > > source file [ arg ... ] > Same as ., except that the current directory is always searched > and is always searched first, before directo- ries in $path. > > Testing myself: > /tmp> cat test > echo hello world > /tmp> ls -l test > -rw-r--r-- 1 jean-luc jean-luc 17 2003-09-17 08:49 test > /tmp> . test > /usr/bin/test:12: parse error near `)' > /tmp> source test > hello world > > Seems you have typed ". test" :-) > > . file [ arg ... ] > Read commands from file and execute them in the > current shell environment. > > If file does not contain a slash, or if PATH_DIRS > is set, the shell looks in the components of $path > to find the directory containing file. Files > in the current directory are not read unless `.' > appears somewhere in $path. If a file named > `file.zwc' is found, is newer than file, and is the > compiled form (created with the zcompile > builtin) of file, then commands are read from that > file instead of file. > > If any arguments arg are given, they become > the positional parameters; the old positional > parameters are restored when the file is done > executing. The exit status is the exit status of > the last command executed. Ciao Dominik ^_^ ^_^ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: security risk in source builtin? 2003-09-17 7:35 ` Dominik Vogt @ 2003-09-17 12:42 ` Phil Pennock 0 siblings, 0 replies; 7+ messages in thread From: Phil Pennock @ 2003-09-17 12:42 UTC (permalink / raw) To: Zsh Users On 2003-09-17 at 09:35 +0200, Dominik Vogt wrote: > I may have confused the test cases for bash and zsh. Thanks for > pointing that out. However, that does not change my concern that > "source" (as well as ".") is a security risk. Could you please explain how it's a security risk? I think I'm missing something. My viewpoint is based around the idea that when I type a command-name, a process is started running from a program stored somewhere in $PATH, and runs with all my access rights. So if someone untrusted can write to somewhere in $PATH then execlp()/execvp() become dangerous and most of Unix suddenly has security holes. Don't add directories to $PATH unless you absolutely trust everyone who can write to that directory, or move it aside somewhere up the filesystem tree, or can write to a file in that directory. Hence the presence of "." as an element of $PATH (or the equivalent empty element, indicated by double, leading or trailing colons) is a very dubious practice. And using "source" is dubious, unless you're very sure of where you are. I've trained myself to use ". ./filename" so that at least it's explicit that I know that it's the current directory. Now, if the modern ACL and MAC unices have a way for executables to inherit privilege-dropping flags from a directory, so that a directory can be flagged so that all executables within it automatically revoke some set of privileges, _then_ having "source"/"." use the same $PATH becomes an issue. But AFAIK, none of the systems about support this sort of inheritance of extended attributes (I could well be wrong). -- 2001: Blogging invented. Promises to change the way people bore strangers with banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php> ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <20030917102420.GA2522@mail.guild.uwa.edu.au>]
* Re: security risk in source builtin? [not found] ` <20030917102420.GA2522@mail.guild.uwa.edu.au> @ 2003-09-17 11:07 ` Dominik Vogt 2003-09-17 11:48 ` James Devenish 0 siblings, 1 reply; 7+ messages in thread From: Dominik Vogt @ 2003-09-17 11:07 UTC (permalink / raw) To: Zsh Users On Wed, Sep 17, 2003 at 06:24:20PM +0800, James Devenish wrote: > In message <20030916145820.GC4583@gmx.de> > on Tue, Sep 16, 2003 at 04:58:20PM +0200, Dominik Vogt wrote: > > but isn't it also a security risk? In this case, the > > following happened: > > > > $ ls -F > > test > > $ cat test > > echo hello world > > $ source test > > /usr/bin/test:3: bad pattern: ^@^F^@(... > Could you please explain to me how this is a security risk? Are you > merely trying to say that is offers the possibility of the wrong command > being executed, or are you saying it could lead to some exploitable > condition such as execution of a file that could not normally be > executed? To the casual user, it is not obvious why the $PATH should be searched. After all, scripts read with "source" or "." should usually not be executable, so they do not belong into any directory in the $PATH. On the other hand scripts in the $PATH normally begin with "#!<path to parser>" and should never be read with "source" or "." (it's not guaranteed that the "#" character introduces a comment). This is not a vulnenrability per se and is not exploitable unless the user makes an additional mistake (like using "." in the PATH). The security risk here is that it is by no means obvious that or why the $PATH is searched for the script. At the very least, I think "source" and "." should not attempt to read files in the $PATH that are not executable. Of course this is only my mersonal opinion > How is this different to simply feeding arbitrary bytes to the > command line with your terminal or pipe? Only in the way it is invoked. P.S.: I'm now subscribed to the mailing list. It's not necessary to answer to me personally. Ciao Dominik ^_^ ^_^ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: security risk in source builtin? 2003-09-17 11:07 ` Dominik Vogt @ 2003-09-17 11:48 ` James Devenish 2003-09-17 12:52 ` Dominik Vogt 0 siblings, 1 reply; 7+ messages in thread From: James Devenish @ 2003-09-17 11:48 UTC (permalink / raw) To: Zsh Users In message <20030917110731.GA535@gmx.de> on Wed, Sep 17, 2003 at 01:07:31PM +0200, Dominik Vogt wrote: > > > $ source test > > > /usr/bin/test:3: bad pattern: ^@^F^@(... [...] > To the casual user, it is not obvious why the $PATH should be > searched. After all, scripts read with "source" or "." should > usually not be executable, so they do not belong into any > directory in the $PATH. [...] > At the very least, I > think "source" and "." should not attempt to read files in the > $PATH that are not executable. Of course this is only my mersonal As you mentioned, the . command is provided by the POSIX shell. I would expect that changing its behaviour would cause existing scripts to fail, as well as affecting portability. I think that it is bad to be scripting with ". test" if you desire the semantics of ". ./test" (in the case that you use "./test", $path will not be searched). You are right that it is a "trap" to fall into, but there is a definite difference between ". test" and ". ./test" and it is probably more important that authors code carefully (as always applies to coding). ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: security risk in source builtin? 2003-09-17 11:48 ` James Devenish @ 2003-09-17 12:52 ` Dominik Vogt 0 siblings, 0 replies; 7+ messages in thread From: Dominik Vogt @ 2003-09-17 12:52 UTC (permalink / raw) To: Zsh Users On Wed, Sep 17, 2003 at 07:48:53PM +0800, James Devenish wrote: > In message <20030917110731.GA535@gmx.de> > on Wed, Sep 17, 2003 at 01:07:31PM +0200, Dominik Vogt wrote: > > > > $ source test > > > > /usr/bin/test:3: bad pattern: ^@^F^@(... > [...] > > To the casual user, it is not obvious why the $PATH should be > > searched. After all, scripts read with "source" or "." should > > usually not be executable, so they do not belong into any > > directory in the $PATH. > [...] > > At the very least, I > > think "source" and "." should not attempt to read files in the > > $PATH that are not executable. Of course this is only my mersonal > > As you mentioned, the . command is provided by the POSIX shell. I would > expect that changing its behaviour would cause existing scripts to fail, > as well as affecting portability. I think that it is bad to be scripting > with ". test" if you desire the semantics of ". ./test" (in the case > that you use "./test", $path will not be searched). You are right that > it is a "trap" to fall into, but there is a definite difference between > ". test" and ". ./test" and it is probably more important that authors > code carefully (as always applies to coding). Okay, this is what POSIX says for ".": If file does not contain a slash, the shell shall use the search path specified by PATH to find the directory containing file. Unlike normal command search, however, the file searched for by the dot utility need not be executable. which is implemented correctly in zsh, but not in bash (who cares ;-) ) or pdksh. I.e. zsh looks in the $PATH only while bash tries . if $PATH fails. "source" is not part of POSIX. So it seems the security problem is in the POSIX spec itself :-P Ciao Dominik ^_^ ^_^ ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2003-09-17 12:51 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-09-16 14:58 security risk in source builtin? Dominik Vogt 2003-09-17 6:58 ` Thomas Köhler 2003-09-17 7:35 ` Dominik Vogt 2003-09-17 12:42 ` Phil Pennock [not found] ` <20030917102420.GA2522@mail.guild.uwa.edu.au> 2003-09-17 11:07 ` Dominik Vogt 2003-09-17 11:48 ` James Devenish 2003-09-17 12:52 ` Dominik Vogt
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).