Hi, Richard,
Problems comes from careless CGI handling.
keep the following result in mind
term% 'fn#foo'='fn foo {echo yes}; echo no
'
term% rc
no
term%
today, we have a number of malicious request to our web server.
assume a web server accept a request with a query
query='fn#foo=fn%20foo%20{echo%20yes};%20echo%20no%0a’
if the query is processed as follows: (the explanation is only for demo)
term% query='fn#foo=fn%20foo%20{echo%20yes};%20echo%20no%0a'
term% echo $query
fn#foo=fn%20foo%20{echo%20yes};%20echo%20no%0a
term% ifs='=' a=`{echo -n $query}
term% b=`{echo -n $a(2) | sed 's/%20/ /g; s/%0a/\n/g'}
term% echo -n $b
fn foo {echo yes}; echo no
term% $a(1)=$b
term% rc
no
term%
we can avoid such attacks by putting a prefix (say ‘QS_' as Pegasus does) at
the last stage.
QS_$a(1)=$b
assume the input field is “name”, then some people believe $a(1) is “name”, and
may carelessly
execute for simplicity
$a(1)=$b
and such CGI will work for almost all cases (because they are not malicious).
even if extra command in
fn foo {…}; maliciouscommand
is removed in starting rc, careless handling makes problem.
however it is much different in dangerousness between some environment variable
are destroyed
and arbitrary commands can be executed.
Kenji Arisawa
2014/09/28 18:39、Richard Miller <[email protected]> のメール：
>> when rc is invoked, rc reconstructs shell variable and shell functions using
>> files in /env/.
>> in case of shell functions, rc evaluates whole data in the file.
>> this feature makes problem if the content is
>> fn foo {…}; maliciouscommand
>
> How would a malicious agent put something into /env? If it's possible,
> how is this different from putting something into $home/bin/rc or
> binding something into /rc/bin ?
>
>
