How to avoid warning of 'Insecure world writable dir /local_vol1_nobackup in PATH, mode 040777'

Ruby
1

I tried in my ruby script to call an external program, then it report a
warning of ‘Insecure world writable dir /local_vol1_nobackup in PATH,
mode 040777’, my script stopped.

My question is how to make my script not impacted by this issue with the
condition that the path keep to be world-writable, cause the script must
work in a public disk!

The option could be don’t check the directory’s attribute, or the script
won’t be stopped by warning, or something else,but I don’t know how?
Could any one help with me? Thanks a lot!

Sidney

2

Hi, all

Is anyone have idea about this issue? Thanks very much.

Thanks
Sidney

From: ruby-talk [mailto:[email protected]] On Behalf Of
Luo, Sidney
Sent: Monday, July 21, 2014 9:07 AM
To: [email protected]
Subject: how to avoid warning of ‘Insecure world writable dir
/local_vol1_nobackup in PATH, mode 040777’

I tried in my ruby script to call an external program, then it report a
warning of ‘Insecure world writable dir /local_vol1_nobackup in PATH,
mode 040777’, my script stopped.

My question is how to make my script not impacted by this issue with the
condition that the path keep to be world-writable, cause the script must
work in a public disk!

The option could be don’t check the directory’s attribute, or the script
won’t be stopped by warning, or something else,but I don’t know how?
Could any one help with me? Thanks a lot!

Sidney

3

This is a warning only, it is not likely causing your script to stop. If
you actually post your script and it’s output, perhaps then someone can
help.

4

On Tuesday 22 July 2014, 07:41:12, Luo, Sidney wrote:

Is anyone have idea about this issue? Thanks very much.

Are you spawning a zsh instance with oh-my-zsh?

  --- Eric
5

I can’t help you fix this problem without seeing your code, but the
problem
is pretty straight forward and the warning message is not something that
should be taken lightly. This warning occurs when your PATH contains
something that is world writable and your Ruby code calls something like
system(cmd) or other method whose behavior is impacted by PATH. If PATH
contains a world writable location and the command that you are trying
to
execute can be found in that world writable location before its
legitimate,
(hopefully) non-world-writable location, your ruby code will end up
executing potentially malicious code.

Take this very simple example. I have a directory ~/test that is world
writable (777):

$ ls -ld .
drwxrwxrwx 2 jhart jhart 4096 Jul 23 10:00 .

In it are two scripts, test1 and test2. The former prints the output of
the date command whereas the later prints Time.now:

$ ls -l test*
-rwxr-xr-x 1 jhart jhart 36 Jul 23 09:54 test1
-rwxr-xr-x 1 jhart jhart 35 Jul 23 09:54 test2
$ cat test1
#!/usr/bin/env ruby

system(‘date’)
$ cat test2
#!/usr/bin/env ruby

puts Time.now

With my normal, “secure” PATH, both work OK and don’t warn:

$ ./test1
Wed Jul 23 10:04:29 PDT 2014
$ ./test2
2014-07-23 10:04:31 -0700

If I modify PATH to include this world writable, unsafe directory, I see
the warnings for test1 because it uses system but not for test2 because
PATH doesn’t impact any of the Ruby code (but yes, it can effect what
Ruby
executable is run, but …):

$ PATH=$PATH:. ./test1
./test1:3: warning: Insecure world writable dir /home/jhart/test/. in
PATH,
mode 040777
Wed Jul 23 10:06:39 PDT 2014
$ PATH=$PATH:. ./test2
2014-07-23 10:06:43 -0700

If I throw caution to the wind and put the current working directory
earlier in my PATH and this directory contains an executable matching
what
I want to execute, it will execute this (potentially)
untrusted/malicious
executable instead:

$ ls -l date
-rwxr-xr-x 1 jhart jhart 13 Jul 23 09:55 date
$ cat date
#!/bin/sh
id
2014/07/23 10:09:55 jhart@jhart-laptop ~/test
$ PATH=.:$PATH ./test1
./test1:3: warning: Insecure world writable dir /home/jhart/test/. in
PATH,
mode 040777
uid=1000(jhart) gid=1000(jhart) groups=1000(jhart)
$ PATH=.:$PATH ./test2
2014-07-23 10:10:04 -0700

Notice how test1 now ended up running the “other” date command which
simply
invokes ‘id’ for demonstration purposes.

Again, the fix largely depends on your code but likely involves some
combination of setting a secure PATH in the first place, correcting the
permissions on /local_vol1_nobackup (this sounds like a problem all by
itself) and perhaps reevaluating your use of system/etc.

-jon

On Wed, Jul 23, 2014 at 9:35 AM, Eric MSP Veith
[email protected]

6

zsh may or may not have its own complications/peculiarities here, but
the
OP’s situation is reproducible in bash too and should not be
shell-specific. The reason you don’t see the problem crop up in your
third
command is because Ruby knows the full path to what it is told to
execute
(/bin/bash) so the insecure PATH does not come into play for Ruby, but
it
does come into play for bash itself. You don’t see this because bash
doesn’t have this check like Ruby does and you presumably don’t have a
malicious date in PATH:

$ ls -l date
-rwxr-xr-x 1 root root 13 Jul 23 11:21 date
$ cat date
#!/bin/sh
id
$ PATH=.:$PATH irb
irb(main):001:0> system(“date”)
(irb):1: warning: Insecure world writable dir /tmp/. in PATH, mode
041777
uid=1000(test) gid=1000(test) groups=1000(test)
=> true
irb(main):002:0> system(“/bin/bash”, “-c”, “date”)
uid=1000(test) gid=1000(test) groups=1000(test)
=> true

In that example, $SHELL is bash and zsh isn’t even installed.

-jon

On Wed, Jul 23, 2014 at 11:12 AM, Eric MSP Veith
[email protected]

7

On Wednesday 23 July 2014, 10:15:31, Jon H. wrote:

I can’t help you fix this problem without seeing your code, but the problem
is pretty straight forward and the warning message is not something that
should be taken lightly. This warning occurs when your PATH contains
something that is world writable and your Ruby code calls something like
system(cmd) or other method whose behavior is impacted by PATH. If PATH
contains a world writable location and the command that you are trying to
execute can be found in that world writable location before its legitimate,
(hopefully) non-world-writable location, your ruby code will end up
executing potentially malicious code.

Again, I guess this is a feature of zsh:

[eveith@kazumi:~]% irb
irb(main):001:0> system("date")
(irb):1: warning: Insecure world writable dir /tmp/foo in PATH, mode 
040777
Mi 23. Jul 20:09:01 CEST 2014
=> true
irb(main):002:0> system("/bin/bash", "date")
/usr/bin/date: /usr/bin/date: Kann die Datei nicht ausfhren.
=> false
irb(main):003:0> system("/bin/bash", "-c", "date")
Mi 23. Jul 20:09:22 CEST 2014
=> true
irb(main):004:0>
[eveith@kazumi:~]% /bin/bash -c "echo $PATH"
/tmp/foo:(...omitted...)

Cheers,
Eric

8

On Jul 23, 2014, at 11:12, Eric MSP Veith [email protected]
wrote:

=> false
irb(main):003:0> system(“/bin/bash”, “-c”, “date”)
Mi 23. Jul 20:09:22 CEST 2014
=> true
irb(main):004:0>
[eveith@kazumi:~]% /bin/bash -c “echo $PATH”
/tmp/foo:(…omitted…)

You didn’t read any of his explanation. He clearly explains how and why
this happens. It has nothing to do with zsh. A simple grep will show
that it is ruby:

% grep -C5 “Insecure world writable dir” file.c
if (STAT(p0, &st) == 0 && S_ISDIR(st.st_mode) && (st.st_mode &
S_IWOTH)
#ifdef S_ISVTX
&& !(p && execpath && (st.st_mode & S_ISVTX))
#endif
&& !access(p0, W_OK)) {
rb_warn(“Insecure world writable dir %s in %sPATH, mode 0%”
PRI_MODET_PREFIX"o",
p0, (execpath ? “” : “LOAD_”), st.st_mode);
if (p) *p = ‘/’;
RB_GC_GUARD(path);
return 0;

9

Ryan,

On Wednesday 23 July 2014, 12:10:35, Ryan D. wrote:

  rb_warn("Insecure world writable dir %s in %sPATH, mode 0%"
    PRI_MODET_PREFIX"o",
    p0, (execpath ? "" : "LOAD_"), st.st_mode);
  if (p) *p = '/';
  RB_GC_GUARD(path);
  return 0;

thanks for highlighting the source code.

I stumpled upon the very same warning emitted by zsh just some days ago,
so
that was the reason for my assumption.

I did read Jon H.'s explanation. You’ll notice that his code examples
include these lines:

$ cat test1
#!/usr/bin/env ruby

system('date')

Which would invoke the default shell of the caller, and if that happened
to be
zsh, it could as well have emitted the warning. Of course, I could have
counter-checked Ruby’s source code, which I obviously didn’t. Mea culpa.

    --- Eric