Substitution within system quoted string

Ruby
1

Team,

I would like to enter a value at execution time within the system key
world environment.
However, I am having difficulties entering a value within a quoted
string.

For example, I can hard code the following and it works fine:

system(“start putty.exe -X -ssh -pw mypassword myuserid@myhostname”)

But this requires hard coding the password in the script.
I would like to do something like the following:

system(“start putty.exe -X -ssh -pw " ARGV[0] " myuserid@myhostname”)

Where: ARGV[0] holds the password entered by the invoker of the script.

Is there a way to substitute within a quoted string?
Is there a better way to do this?

Thank you

Victor

2

Alle lunedì 27 agosto 2007, Victor R. ha scritto:

But this requires hard coding the password in the script.

Victor

You need string interpolation:

system(“start putty.exe -X -ssh -pw #{ARGV[0]} myuserid@myhostname”)

In a double quoted string (as well as in a regexp or backtick
expression) you
can substitute insert the value of any expression by enclosing it in
#{}:

a = 2

puts “a is #{a}”

=> a is 2

This doesn’t work in single-quoted strings.

puts ‘a is #{a}’

=> a is #{a}

I hope this helps

Stefano

3

world environment.
system(“start putty.exe -X -ssh -pw " ARGV[0] " myuserid@myhostname”)

system(“start putty.exe -X -ssh -pw #{ARGV[0]} myuserid@myhostname”)

4

On 27.08.2007 22:34, Felix W. wrote:

system(“start putty.exe -X -ssh -pw #{ARGV[0]} myuserid@myhostname”)

never trust parameters or their encoding, or you beg for privilege
escalation problems. The given command will perform both shell
expansion (consider a password like “%PATH%”) and parameter
separation (consider a password like “pw; rm -rf /*”).

It’s much wiser to disallow expansion:

system(“start”,“putty.exe”,"-X","-ssh","-pw",ARGV[0],“myuserid@myhostname”)

  • Matthias
5

escalation problems. The given command will perform both shell

It’s generally a very bad idea to give a password on the command line.
I’m
not sure if Windows keeps a command line history, but all it would take
is
for the DOS Prompt to still be open, and for someone to arrow up.

Felix

6

On 27.08.2007 23:35, Felix W. wrote:

On 27.08.2007 22:34, Felix W. wrote:

system(“start putty.exe -X -ssh -pw #{ARGV[0]} myuserid@myhostname”)
never trust parameters or their encoding, or you beg for privilege
escalation problems. The given command will perform both shell
expansion (consider a password like “%PATH%”) and parameter
separation (consider a password like “pw; rm -rf /*”).

It’s generally a very bad idea to give a password on the command line. I’m
not sure if Windows keeps a command line history, but all it would take is
for the DOS Prompt to still be open, and for someone to arrow up.

Sure, but the problem is not limited to passwords. Any input you
cannot control or carefully check is bad if it is used in shell
expansion like the above. So better not start with it at the first
place, neither for passwords, nor for something like username@host
or other thought-to-be-friendly parameters.

  • Matthias
7

Hi,

Am Dienstag, 28. Aug 2007, 05:34:59 +0900 schrieb Felix W.:

I would like to do something like the following:

system(“start putty.exe -X -ssh -pw " ARGV[0] " myuserid@myhostname”)

Is there a way to substitute within a quoted string?
Is there a better way to do this?

system(“start putty.exe -X -ssh -pw #{ARGV[0]} myuserid@myhostname”)

I don’t know what Windows does with this command line. On
Linux you may say a simple

$ ps aux | grep ssh

and the whole command line is shown. Some programs like
GnuPG offer the facility to pipe the password to $stdin;
as far as I know BSD Ssh forbids entirely to pass it from
outside.

Maybe host-based authentication is a better solution for
you.

Bertram

8

On 28.08.2007 03:05, Simon K. wrote:

place, neither for passwords, nor for something like username@host
or other thought-to-be-friendly parameters.

You are talking about two different things. Felix is about sensitive
data, you seem to be about injection. The latter is only a problem, when
the program is executed with other rights than its user, which is
normally not the case with command line programs.

You are right about the two different topics. Sure, it’s very,
very bad to write the password into the command line. But on a
single-user computer, this might be OK nevertheless, so this is up
to the user to decide. He can use public key authentication, then
this is no matter anymore (see PuTTY documentation for more details).

Injection is very bad irrespective of the user rights and which
parameter is vulnerable. If it’s not the password, he might pass the
username to the executed command, then it’s the same. Finally, a
parameter (like the given password) like “%PATH%” will make the
command not work, a password like “; rm -rf /*;” will have other
side effects that are certainly not assumed by the programmer.

String substitution is a good thing if you know precisely what
goes into this string and what is done with the resulting string. If
it is put into Kernel#system() with shell expansion, it’s like
Kernel#eval() – you certainly don’t want to put any arbitrary,
unquoted string into that without careful data checking. But
that’s happening here.

Very bad, indeed, but common practice and good triggers for long
security-related stories in newspapers.

  • Matthias
9

On 27.08.2007 23:35, Felix W. wrote:

It’s generally a very bad idea to give a password on the command line. I’m
not sure if Windows keeps a command line history, but all it would take is
for the DOS Prompt to still be open, and for someone to arrow up.

Sure, but the problem is not limited to passwords. Any input you
cannot control or carefully check is bad if it is used in shell
expansion like the above. So better not start with it at the first
place, neither for passwords, nor for something like username@host
or other thought-to-be-friendly parameters.

You are talking about two different things. Felix is about sensitive
data, you seem to be about injection. The latter is only a problem, when
the program is executed with other rights than its user, which is
normally not the case with command line programs.

mfg, simon … l

10

This worked like a charm!

Thank you

Victor

11

Injection is very bad irrespective of the user rights and which
parameter is vulnerable. If it’s not the password, he might pass the
username to the executed command, then it’s the same. Finally, a
parameter (like the given password) like “%PATH%” will make the
command not work, a password like “; rm -rf /*;” will have other
side effects that are certainly not assumed by the programmer.

But it doesn’t enable the user to do things he isn’t allowed to do, so
it’s not a security problem. But It might make it easier to shoot
yourself in the foot.

mfg, simon … l