Re: cd with multiple arguments?
Le 16/12/2010 17:03, Bob Proulx a écrit : > I didn't say anything about quoting. The topic here was security > vulnerabilities of an suid script. For example the classic race > condition between stat'ing the #! interpreter and launching the > privileged process on the file. If the system has that behavior then > any #! interpreter (including non-interpreters such as 'ls') are > vulnerable to an attack of slipping a different interpreter in at the > last moment. Sorry I did not know about this race condition. This is more or less the type of problems I had in mind: http://hea-www.harvard.edu/~fine/Tech/cgi-safe.html The number of security recommendations on this page is impractical for any programmer but an expert one. This is just too complicated. I see this as yet another demonstration that shell scripting is very good for interactive use and relatively small system administration tasks but does not scale beyond that. Actually, I doubt any language could do that. Safety and "scalability" are more often than not opposed to convenience. (OK: maybe Perl is just as bad)
Re: cd with multiple arguments?
Le 15/12/2010 18:08, Illia Bobyr a écrit : > On 12/15/2010 4:17 AM, Marc Herbert wrote: >> [...] >> I use and abuse the shell but I do not consider it as a "real" >> programming language is because it was not really designed as one from >> day one. It rather grew from the command line interface as explained >> in this great interview of Steve Bourne: >> >> >> http://www.computerworld.com.au/article/279011/a-z_programming_languages_bourne_shell_sh/ >> >> [...] > > Actually, I got a completely opposite impression after reading the > article :) > I understand Steve Bourne came up with a brand new *internal* design; but from an external language perspective he preserved how the previous interactive shell was used. From a user perspective he added programming features but it looks like he did NOT change anything to existing interactive features. Which obviously made an easier sell. But also prevented the shell to be a "real" programming language IMHO. Do not get me wrong: I LOVE the programming features of the shell and I abuse them everyday. I think the shell is one of the key productivity difference between Unix and Windows. But I also think the shell does not scale up to bigger programming tasks. As a matter of fact, I do not know of any large and popular project developed with it.
Re: cd with multiple arguments?
On Fri, Dec 17, 2010 at 09:47:00AM +, Marc Herbert wrote:
> This is more or less
> the type of problems I had in mind:
>
> http://hea-www.harvard.edu/~fine/Tech/cgi-safe.html
Wow, there is some atrocious code on that page (being shown as "what not
to do"). I have no doubt that code just like it is written every day,
however. We see it all the time in IRC and on this mailing list
The single biggest problem demonstrated by that page is the tendency
of people to invoke a shell from some other language to do something
for them. The example they use (from perl) is:
open ("/bin/ls /data/cardfiles | grep $searchspec |");
Even if we fix all the shell mistakes (and this line trips three major red
flags for me just at the shell level!), there's still a fundamental flaw --
it's passing user input data to a command interpreter, namely /bin/sh
(which is hidden by the perl syntax, but which is invoked implicitly).
And there's absolutely no good reason to do so, either -- as the page
says, "Avoid starting external programs where possible." This should
be handled by iterating through the filenames within perl and filtering
out the ones that aren't wanted -- not by invoking three external programs.
That sidesteps not only the three huge mistakes in the shell code, but
the *entire shell*.
> The number of security recommendations on this page is impractical for
> any programmer but an expert one. This is just too complicated.
I would claim that writing a secure CGI program in any language requires
an extremely pedantic (possibly even paranoid) approach. Novices are
well advised to stay far away from it, without some experienced guidance.
Granted, the shell makes it easier (compared to most languages) to fall
into traps... but the traps are there in every language. CGI programs are
exposed to the nastiest, most malevolent input strings you can imagine,
plus all the ones you couldn't imagine -- but someone else certainly did.
All input must be thoroughly and aggressively sanitized.
Re: cd with multiple arguments?
On 12/17/2010 7:37 AM, Greg Wooledge wrote:
> [...]
> The single biggest problem demonstrated by that page is the tendency
> of people to invoke a shell from some other language to do something
> for them. The example they use (from perl) is:
>
>open ("/bin/ls /data/cardfiles | grep $searchspec |");
>
> Even if we fix all the shell mistakes (and this line trips three major red
> flags for me just at the shell level!), there's still a fundamental flaw --
> it's passing user input data to a command interpreter, namely /bin/sh
> (which is hidden by the perl syntax, but which is invoked implicitly).
>
> [...]
There is a "Taint Mode" in Perl that helps catch this kind of errors:
http://gunther.web66.com/FAQS/taintmode.html
In a few words in this mode everything that comes from "the outside",
like user input or an environment variable value, is marked as
"tainted". And the interpreter will give you an error if
you will try to pass this data into anything like open(), system() or
other security sensitive things.
It is still possible to make an error that will cause user input to go
into sensitive system calls but requires more effort, so it will
unlikely to happen by acident.
This mode is designed to help writing CGI scripts.
Ilya Bobyr
Re: cd with multiple arguments?
> Le 15/12/2010 18:08, Illia Bobyr a écrit : >> On 12/15/2010 4:17 AM, Marc Herbert wrote: >>> [...] >>> I use and abuse the shell but I do not consider it as a "real" >>> programming language is because it was not really designed as one from >>> day one. It rather grew from the command line interface as explained >>> in this great interview of Steve Bourne: >>> >>> >>> http://www.computerworld.com.au/article/279011/a-z_programming_languages_bourne_shell_sh/ >>> >>> [...] >> Actually, I got a completely opposite impression after reading the >> article :) >> > I understand Steve Bourne came up with a brand new *internal* design; > but from an external language perspective he preserved how the > previous interactive shell was used. From a user perspective he added > programming features but it looks like he did NOT change anything to > existing interactive features. Which obviously made an easier > sell. But also prevented the shell to be a "real" programming language > IMHO. I worked on a pretty huge project written 99% in TCL. TCL looks is very much like Bash, except that, I would say, it is cleaner in the quoting area. And by "cleaner" I mean that it is just cleaner, it have issues with incorrect quoting that are very similar to one you may have with Bash. So, I guess, syntax is not that important... And by the way, in the interview Steve Bourne says that he did change some of the interactive features to make them more useable for complex operations. One example he gives is filters: "I did change the shell so that command scripts could be used as filters. In the original shell this was not really feasible because the standard input for the executing script was the script itself. This change caused quite a disruption to the way people were used to working." > Do not get me wrong: I LOVE the programming features of the shell and > I abuse them everyday. I think the shell is one of the key > productivity difference between Unix and Windows. But I also think the > shell does not scale up to bigger programming tasks. As a matter of fact, > I do not know of any large and popular project developed with it. Comparing, again, with TCL, I think that TCL is more sutable for big project only because it have more features to support larger programs, like object oriented support, threading, GUI, libraries and others. In the interview Steve Bourne says "My own view, as I have said, was that the shell had reached the limits of features that could be included without making it rather baroque and certainly more complex to understand." My feeling is that it is not the quoting syntax but the fact that sh does not have certain features is what has more infuence on the fact that it is not used to write large applications. And TCL was developed almost 13 years later than sh, so developers had much more overal experience to base their decisions upon... :) Ilya Bobyr
Re: cd with multiple arguments?
On Fri, Dec 17, 2010 at 12:47:49PM -0600, Illia Bobyr wrote: > I worked on a pretty huge project written 99% in TCL. TCL looks is very > much like Bash, except that, I would say, it is cleaner in the quoting area. The substantial difference is that bash does word splitting and globbing on the results of a substitution, unless you quote it. Tcl does not. If you want word splitting from Tcl, you have to call eval.
Re: cd with multiple arguments?
Marc Herbert wrote: > Sorry I did not know about this race condition. This is more or less > the type of problems I had in mind: > > http://hea-www.harvard.edu/~fine/Tech/cgi-safe.html In addition to the fine recommendations from the others I wanted to specifically point out that the problems on that page are not from launching a setuid script and providing a priviledge escalation path. I just had time to skim it briefly but I didn't see setuid mentioned there at all. It is talking about other things. Instead they stem from a script running unverified user provided input. CGI scripts are not normally setuid but are running as the web server process owner and they usually allow connections from anonymous attackers on the hostile internet. By consuming and executing untrusted input they allow an attack against the web server process owner. It is a problem, and a big one, but completely different from having a local user attack against an setuid script and be able to gain the priviledge of the script owner. > The number of security recommendations on this page is impractical for > any programmer but an expert one. This is just too complicated. I see > this as yet another demonstration that shell scripting is very good > for interactive use and relatively small system administration tasks but > does not scale beyond that. Actually, I doubt any language could do > that. Safety and "scalability" are more often than not opposed to > convenience. Using user provided input as commands is a problem no matter what language you use. > (OK: maybe Perl is just as bad) Perl and Ruby and others do provide taintmode that tracks data flow through the program. That does help significantly. But it *is* still complicated. That is why there have been so many successful attacks in the past. There isn't any magic sauce to make all of the complication go away. Attackers are as clever as you. It is a classic battle between armorer and weapons maker. Bob There are two types of complicated programs. Those that were built up from smaller simpler ones and those that do not work.
Referencing empty array with "set -u" active throws error
Configuration Information [Automatically generated, do not change]:
Machine: sparc
OS: solaris2.9
Compiler: /sapmnt/global/tools/compiler/SS11/SUNWspro/bin/cc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc'
-DCONF_OSTYPE='solaris2.9' -DCONF_MACHTYPE='sparc-sun-solaris2.9'
-DCONF_VENDOR='sun'
-DLOCALEDIR='/sapmnt/oraicall/home/tools/bash-4.1/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DSOLARIS -I. -I. -I./include
-I./lib -I./lib/intl
-I/net/sapmnt.home2/oraic/tmp/bash_sunos_sun4u/bash-4.1/lib/intl -g
uname output: SunOS us0111 5.9 Generic_117171-12 sun4u sparc SUNW,Sun-Fire-V440
Machine Type: sparc-sun-solaris2.9
Bash Version: 4.1
Patch Level: 0
Release Status: release
Description:
Referencing empty array with "set -u" active throws unbound variable error.
Repeat-By:
$ set -u
$ declare -a array
$ array=( )
$ echo "${arr...@]}"
bash: arr...@]: unbound variable
For an empty "$@" this does not throw an "unbound" error, which seems to be
an inconsistent behaviour to me.
Workaround:
Use the infamous empty array work-around:
$ echo ${argv[0]+"${ar...@]}"}
complete options not working with read -e
I'm writing a script with a command line interpreter and I can most things
working (eg. history etc.) except for one thing. The filename completion
works well for some of the commands, but I'd like to use other completion
options for others. Works well from the "real" command line, but I can't
get it to work properly in my "read -e, eval" loop..
For example, in trying to set up arguments for debug, verbose, trace etc..
In the example below I indicate where I tab with [TAB] and I have editing-mode
set to vi.
marion:~/tmp$ ls
./ ../ file1 file2 file3 file4 file5 file6 file7 file8 file9
marion:~/tmp$ complete -W 'on off true false' debug trace errexit verbose
marion:~/tmp$ debug [TAB]
false offon true
marion:~/tmp$ read -e -p 'FUBAR->' fubar
FUBAR->debug [TAB]file[TAB]
file1 file2 file3 file4 file5 file6 file7 file8 file9
FUBAR->
Is there any way to modify the behaviour of "read -e" so that it does
what I want (and not filenames)?
I did do one neat trick for most of the commands and use fake filenames
to give me the expansions I need. While this works for most, it doesn't
work for all of the commands I want.. This is at the top of my read/eval
loop where I cd into a directory with fake files set up specifically to
give me the arguments I need for most of the commands.
if [ -t 0 -a -t 1 ] ; then
interactivemode=true
dobanner
[ -r "$historyfile" ] && history -r "$historyfile"
touch "$historyfile"# make sure that we can save it when done
realpwd="$PWD"
cd "${tabcomplete}" > /dev/null && {
echo "$SEARCH_HOST $SEARCH_TYPE" | tr '|' '\012' | xargs touch ;
cd - > /dev/null
}
complete -W 'clean'history
complete -W 'on off' debug trace errexit verbose
complete -W 'view clear' results
fi
while : ; do
$interactive && cd "$tabcomplete" > /dev/null# get ready for tab
complete
$debug && prompt="[$PROGNAME debug]->" || prompt="$PROMPT"
if read -e -p "$prompt" action hostgroup; then
if [ -n "$action" ] ; then
history -s $action "$hostgroup"
$interactive && cd "$realpwd" > /dev/null# restore the real pwd
where we are
if doactions $action $hostgroup ; then
: continue
else
echo "usage: action host-or-group"
fi
else
: continue
fi
else
break
fi
done
Any suggestions?
Thanks!!
--
Bill Duncan, | http://www.servermetrix.com/
bdun...@servermetrix.com | - linux/unix/network security
+1 416 697-9315 | - web and application hosting
Regular expressions with word boundaries no longer working in bash
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall
uname output: Linux ochof070 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2
02:41:37 UTC 2010 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.1
Patch Level: 5
Release Status: release
Description:
Doing string matching based on word boundaries no longer works:
$ bash --version
GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
$ cat test.sh
input="foocombo foo foo bar bar foo bar some stuff foo" # the input
expected="foocombo foo bar some stuff" # this what we expect
for i in ${inp...@]}; do
[[ ! ${o...@]} =~ \\b"${i}"\\b ]] && old=( ${o...@]} $i )
done
for i in ${inp...@]}; do
[[ ! ${n...@]} =~ \b${i}\b ]] && new=( ${n...@]} $i )
done
echo "input:$input"
echo "expected: $expected"
echo "old code: ${old[*]}"
echo "new code: ${new[*]}"
$ bash test.sh
input:foocombo foo foo bar bar foo bar some stuff foo
expected: foocombo foo bar some stuff
old code: foocombo foo bar some stuff
new code: foocombo foo foo bar bar foo bar some stuff foo
Repeat-By:
$ bash --version
GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ cat test.sh
input="foocombo foo foo bar bar foo bar some stuff foo" # the input
expected="foocombo foo bar some stuff" # this what we expect
for i in ${inp...@]}; do
[[ ! ${o...@]} =~ \\b"${i}"\\b ]] && old=( ${o...@]} $i )
done
for i in ${inp...@]}; do
[[ ! ${n...@]} =~ \b${i}\b ]] && new=( ${n...@]} $i )
done
echo "input:$input"
echo "expected: $expected"
echo "old code: ${old[*]}"
echo "new code: ${new[*]}"
$ bash test.sh
input:foocombo foo foo bar bar foo bar some stuff foo
expected: foocombo foo bar some stuff
old code: foocombo foo foo bar bar foo bar some stuff foo
new code: foocombo foo foo bar bar foo bar some stuff foo
The information in this e-mail is intended only for the person or entity to
which it is addressed.
It may contain confidential and /or privileged material. If someone other than
the intended recipient should receive this e-mail, he / she shall not be
entitled to read, disseminate, disclose or duplicate it.
If you receive this e-mail unintentionally, please inform us immediately by
"reply" and then delete it from your system. Although this information has been
compiled with great care, neither IMC Financial Markets & Asset Management nor
any of its related entities shall accept any responsibility for any errors,
omissions or other inaccuracies in this information or for the consequences
thereof, nor shall it be bound in any way by the contents of this e-mail or its
attachments. In the event of incomplete or incorrect transmission, please
return the e-mail to the sender and permanently delete this message and any
attachments.
Messages and attachments are scanned for all known viruses. Always scan
attachments before opening them.
