thanks for all.
our conclusion is: worthless to fix.
Kenji Arisawa
> today, we have a number of malicious request to our web server.
i don't see any malicious requests that could possibly bother the standard
release.
plan 9 is just too obscure to bother with.
- erik
On Fri, Sep 26, 2014 at 12:32 PM, Kurt H Maier wrote:
> Quoting Russ Cox :
>
> The right fix is to eliminate all possible interaction between (1) and
>> (2).
>> The first public fix focused instead on making (1) more robust, and guess
>> what, it wasn't good enough and now there is a *second* CV
On 29 September 2014 14:03, arisawa wrote:
> 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’
>
but why should a web server put arbitrary data from a remote user
un
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#fo
> 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 /e
Hello,
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
I think this problem must be fixed.
Kenji Arisawa
Russ Cox writes:
> Thanks to name space hygiene on td's part, the rc function space and the
> CGI variable space do not overlap, so rc already has no possible
> interaction with CGI, which is as it should be. I don't think it is super
> important to try to make rc defend against malicious environ
Quoting Skip Tavakkolian :
you misrepresent. rsc addressed the non-web-centric issue:
I don't think it is super important to try to make rc defend against
malicious environments, any more than
it is to make it somehow defend against malicious $paths. If those are
security-relevant, you've a
With manipulating a path you still need access to a writable filesystem to
subvert a child shell. That step is not necessary if you can pass functions in
the environment.
> On Sep 26, 2014, at 8:54 AM, Russ Cox wrote:
>
> +9fans, since a few people have asked
>
>> On Thu, Sep 25, 2014 at 6:1
you misrepresent. rsc addressed the non-web-centric issue:
> I don't think it is super important to try to make rc defend against
malicious environments, any more than
> it is to make it somehow defend against malicious $paths. If those are
security-relevant, you've already lost.
On Fri, Sep 26,
Quoting Russ Cox :
The right fix is to eliminate all possible interaction between (1) and (2).
The first public fix focused instead on making (1) more robust, and guess
what, it wasn't good enough and now there is a *second* CVE about this
problem, and a *second* attempt at making (1) more robus
+9fans, since a few people have asked
On Thu, Sep 25, 2014 at 6:15 PM, Scott Schwartz wrote:
> Reading about the latest bash bug, I tried this with rc.
> Is it a bug? Feature? Other?
>
> bash$ env 'fn#foo'='{true}
> date
> ' rc
> Thu Sep 25 15:07:16 PDT 2014
> % whatis foo
> fn foo {true}
>
I
13 matches
Mail list logo
