Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: [NSE] Adding mkdir support
From: Djalal Harouni <tixxdz () opendz org>
Date: Wed, 4 Apr 2012 23:04:06 +0100

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/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]