Matthias Wächter
8/28/2007 8:30:00 AM
On 28.08.2007 03:05, Simon Krahnke wrote:
> * Matthias Wächter <matthias@waechter.wiz.at> (23:41) schrieb:
>
>> On 27.08.2007 23:35, Felix Windt 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.
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