Re: [NSE] Adding mkdir support

[Djalal Harouni <tixxdz () opendz org>]

On Wed, Apr 04, 2012 at 05:13:46PM -0400, Patrick Donnelly wrote:
> On Wed, Apr 4, 2012 at 3:55 PM, Djalal Harouni <tixxdz () opendz org> wrote:
[...]
> > make_dir() function calls mkdir() in this way:
> >
> >   mkdir (path, S_IRUSR | S_IWUSR | S_IXUSR | S_IRGRP |
> >                S_IWGRP | S_IXGRP | S_IROTH | S_IXOTH );
> >                ^^^^^^^
> >
> > At least we should use 0755 regardless of the current value of umask
> > and avoid situations where groups are shared...
> >
> > Other solutions:
> > 1) use 0700 mode ? (I like this one).
> > 2) add an extra argument to control the mode ?
> >
> > David, Patrick what do you think ? should we report this upstream ?
>
> I believe the reason they don't support a mode argument for mkdir is
> because it's not supported for Windows. In any case, I agree that 0700
> is the correct mode. It should be reported upstream.
Ok I'll try to report it.

For the mode argument this is in general the status of all the high level
languages and libraries that do not give full control over syscalls
behaviour.

> > BTW while we are at this thing, IMHO we should add checks to only write
> > to directories owned by the current user and writable only by the current
> > user, and try to avoid issues that can raise from following crafted urls
> > and links from servers. Perhaps we should define something like "/" root
> > directory and write all the stuff there in case...
>
> I really think we should avoid modifying lfs as much as possible. The
> main reason I encouraged using lfs is because it is fairly standard in
> the community and mostly portable.
I must say that I fully agree here, we should not modify lfs.

I was more thinking of adding our wrappers that calls the lfs functions,
functions that can fit in what Nmap tries to do, epsecially if we are mirroring
remote files...

> > > something searching for this when new code is committed as an additional
> > > check maybe?
> > That would be nice, a simple script that evaluates or identifies Lua
> > functions will help.
> >
> > This can be a simple and nice GSoC task.
>
> This is non-trivial. It is quite easy to have Lua code reference
> something like os.execute without actually being obvious (from a code
> analysis standpoint) about it:
>
> local os = require "os"
>
> os[string.gsub("dwdbtsd", ".", function(a) return
> string.char(string.byte(a)+1) end)]("echo hi")
Yes, it can be done, but as you have said this is also suspicious, well
someone can just improve this :)

> Of course that's suspicious code but you get the idea. The only safe
> thing to do is remove os.execute which is not something we've wanted
Actually I don't have a strong opinion about this, reviwing scripts is
just fine and simple warnings about these functions might perhaps help.

> to do in the past. I also use the term "safe" cautiously. I don't
> think we can ever truly protect against malicious scripts without
> seriously hamstringing the available freedoms scripts currently enjoy.
I agree.

> -- 
> - Patrick Donnelly
Thanks.

-- 
tixxdz
http://opendz.org
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/