• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Item4382: configure no longer has a good default for {SafeEnvPath}

Item Form Data

AppliesTo: Component: Priority: CurrentState: WaitingFor: TargetRelease ReleasedIn
Engine   Urgent Closed   minor 4.2.0

Edit Form Data

Summary:
Reported By:
Codebase:
Applies To:
Component:
Priority:
Current State:
Waiting For:
Target Release:
Released In:
 

Detail

I have installed TWiki at least 100 times now as part of years of testing.

This time I run into many simple problems so expect to see several reports.

First problem I run into is {SafeEnvPath} being empty

This always had a good default value for Linux/Unix at least

But probably bad for Windows.

Now it is empty and bad for all.

The idea is that the default used is based on the host OS.

I see two possibilities.

Either we make configure's check more intelligent.

Or we default the path in the code based on detected OS.

I find the first most transparent from a security point of view. Today we already guess well the different path names for all the TWiki directories. It should be possible to guess this as well.

-- TWiki:Main/KennethLavrsen - 19 Jul 2007

Today we already guess well the different path names for all the TWiki directories. - yes, but that's a very different challenge to guessing system paths.

The reason I cleared the safe env path is as you analysed - it was causing a major headache on Windows, because the default path is linux, and overwriting the path on Windows meant that it lost sight of some key (and very obscure) DLL components. These components were not used by TWiki - in fact they were used by a program invoked from a plugin - and It took hours to track the problem down. It would be a considerable effort to guess the SafeEnvPath on Windows, because different versions of Windows have had all sorts of different install locations for the operating system. Even if you succeed, you will probably fail, because some programs used in plugins still rely on the system path to find DLLs. But is there any point? My reasoning goes as follows:

  • External programs used by TWiki - RCS, and Grep, should always be specified using absolute paths, to help remove any risk of hijacking these programs.
  • Therefore the only reason the 'safe env path' may be required is to block possible exploits that arise from someone working out how to execute an arbitrary shell program from within TWiki.
  • But if they can execute an arbitrary shell program, why can't they also put in an absolute path?
  • So the SafeEnvPath option offers virtually no added security here. In fact it misleads people into thinking it does offer some added security.
  • IMHO the only thing the SafeEnvPath does is to add confusion and a potential source of error for installers. At the end of the day, if someone works out how to deliver a program name to a perl backtick, then the SafeEnvPath sure as heck isn't going to save them frown
I think if there is any change, it should be:
  • Improve the checks in configure to ensure that absolute paths are used for all external components
  • Enhance Sandbox to refuse any attempt to execute a program without an absolute path
After reasoning this way, and clearing the default, the only reason I kept the setting was compatibility, for the (probably extremely rare) case where a site relies on the path defined there to find programs. If you are convinced that the SafeEnvPath adds value to security (and from the above you can see that I am certainly not convinced) then you can restore the Linux defaults, but only if you add a checker to configure that ensures the path components actually represent real directories on disc. i considered doing this, but had already spent a lot of time on the analysis.

CC

I agree with your assessment. It is pseudo security.

What I noticed was that when I did a clean installation and skipped this field because I am used to not having to touch it - TWiki could not find my normal programs like rcs and grep. So I assume this is going to be a trap many newbies will fall into. There are so many fields in configure and the newbie will typically not touch those he do not understand.

And in this case - not setting this field to the value suggested "/bin:/usr/bin" means that things fail.

Like saving a topic generates


Error saving topic

During save of HeyHo an error was found by the version control system. Please notify your TWiki administrator.

/usr/bin/rcs -i -t-none -ko %FILENAME|F% of .../Myweb/HeyHo.txt,v failed to create history file

Go back in your browser and save your changes locally.


This is an error we see often because of wrong access rights. Now we add another reason for a newbie to get into trouble. Apache when it runs does not have a default path.

But then I also need to ask - why does rcs fail? It is specified by an absolute path in the Store settings and it is correct on my installation.

-- TWiki:Main.KennethLavrsen - 20 Jul 2007

Here is a trace of a save with {SafeEnvPath} blank.

[Fri Jul 20 18:18:19 2007] [error] [client 192.168.1.9] /usr/bin/rcs '-i' '-t-none' '-ko' '/usr/local/apache2/twiki4/data/Myweb/SomeTestTopicAgain.txt', referer: http://merlin.lavrsen.dk/twiki/bin/edit/Myweb/?onlywikiname=&onlynewtopic=on&topic=SomeTestTopicAgain&templatetopic=
[Fri Jul 20 18:18:19 2007] [error] [client 192.168.1.9]  -> , referer: http://merlin.lavrsen.dk/twiki/bin/edit/Myweb/?onlywikiname=&onlynewtopic=on&topic=SomeTestTopicAgain&templatetopic=
[Fri Jul 20 18:18:19 2007] [error] [client 192.168.1.9] Status: 302 Moved\r, referer: http://merlin.lavrsen.dk/twiki/bin/edit/Myweb/?onlywikiname=&onlynewtopic=on&topic=SomeTestTopicAgain&templatetopic=
[Fri Jul 20 18:18:19 2007] [error] [client 192.168.1.9] Set-Cookie: TWIKISID=8a9be723a0dd89f882e1dcbf95dc3033; path=/\r, referer: http://merlin.lavrsen.dk/twiki/bin/edit/Myweb/?onlywikiname=&onlynewtopic=on&topic=SomeTestTopicAgain&templatetopic=
[Fri Jul 20 18:18:19 2007] [error] [client 192.168.1.9] Date: Fri, 20 Jul 2007 16:18:19 GMT\r, referer: http://merlin.lavrsen.dk/twiki/bin/edit/Myweb/?onlywikiname=&onlynewtopic=on&topic=SomeTestTopicAgain&templatetopic=
[Fri Jul 20 18:18:19 2007] [error] [client 192.168.1.9] Location: http://merlin.lavrsen.dk/twiki/bin/oops/Myweb/SomeTestTopicAgain?twiki_redirect_cache=2d469c41c9c49e03203ad3fd540ab131\r, referer: http://merlin.lavrsen.dk/twiki/bin/edit/Myweb/?onlywikiname=&onlynewtopic=on&topic=SomeTestTopicAgain&templatetopic=
[Fri Jul 20 18:18:19 2007] [error] [client 192.168.1.9] \r, referer: http://merlin.lavrsen.dk/twiki/bin/edit/Myweb/?onlywikiname=&onlynewtopic=on&topic=SomeTestTopicAgain&templatetopic=
[Fri Jul 20 18:18:19 2007] [error] [client 192.168.1.9] , referer: http://merlin.lavrsen.dk/twiki/bin/edit/Myweb/?onlywikiname=&onlynewtopic=on&topic=SomeTestTopicAgain&templatetopic=

-- TWiki:Main.KennethLavrsen - 20 Jul 2007

Strange error here.

I tried to see which part of the path it needs.

It is the /bin part. Not the /usr/bin

So it is not the rcs command that is the problem

-- TWiki:Main.KennethLavrsen - 20 Jul 2007

On more for the puzzle. It is only when I create a topic that I see it. Not when I edit and save an existing.

I have to save a not yet existing topic for the first time to trigger the error

-- TWiki:Main.KennethLavrsen - 20 Jul 2007

Need hint where and how to search to get deeper into this.

Obviously we must have a system call requiring path to /bin which does not pass through the sandbox.

-- TWiki:Main.KennethLavrsen - 23 Jul 2007

As far as I know, all system calls go through the sandbox. I don't know what to suggest. Hmmmm.

-- TWiki:Main.CrawfordCurrie - 23 Jul 2007

Just adding the default /bin:/usr/bin as it was before will "cure" the problem for Unix users (which most of our users most likely are because Windows installation is pretty difficult anyway).

And that may be the work around we can take. But I would really prefer to find out why the /bin part has to be there. Which program is called from /bin? How do I trace that?

Can it be the rcs stuff that again needs to call some other program in /bin and needs a path for that?

-- TWiki:Main.KennethLavrsen - 27 Jul 2007

When the {SafeEnvPath} is empty - as it is by default - then TWiki doesn't attempt to modify the path. Therefore when you run, TWiki inherits the default path as used by the web server user. Since /bin and /usr/bin are by default on the web server users path (on all the systems I have access to, anyway), any program findable with the safe env path should be findable with the default path. First thing to check what is the $ENV{PATH} if SafeEnvPath isn't set? If /bin and /usr/bin are on the webserver users path, but something is still going wrong, then there must be a program that TWiki is trying to use that is on the path somewhere before /usr/bin or /bin that is blocking the correct path. To narrow this down we need to examine the webserver user's default path.

CC

Mystery still unresolved but here is some more info

The $ENV{PATH} on my machine is by default /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin

When the {SafeEnvPath} is empty then the $ENV{PATH} remains /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin

When the {SafeEnvPath} is set to /bin:/usr/bin then the $ENV{PATH} gets redefined to /bin:/usr/bin

So my natural reaction is to try and set {SafeEnvPath} to /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin and expect to see the topic creation fail. But it does not fail???!!!

I really do not understand this. First I thought that the problem could be that it finds something in /sbin or /usr/sbin. But this is not the case since it works when the same path is defined in {SafeEnvPath} instead of being the default.

Then I tried different test code lines.

I tried to add $ENV{PATH}=""; right after the $ENV{PATH} is defined in TWiki.pm. And that also works??!

I will keep on playing with this. This is really really goofy. It seems the default value of $ENV{PATH} gives trouble. But setting it to empty string makes it work again. And setting it to garbage makes it fail so the set value is important. Mysterious.

Setting this to urgent because not understand this is a potential security issue. I have not given up on this yet.

-- KennethLavrsen - 28 Jul 2007

HA! I finally found out why. The $ENV{PATH} is tainted and we have use strict.

When we set the PATH we use an untainted variable seen from Perl. When we do not set it the default is considered tainted.

The possible fix is

    if( $TWiki::cfg{SafeEnvPath} ) {
        $ENV{PATH} = $TWiki::cfg{SafeEnvPath};
    } else {
        $ENV{PATH} = TWiki::Sandbox::untaintUnchecked( $ENV{PATH} );
    }

But seen from a safety point of view shoudn't we rather give a sensible default instead of allowing a silly default that includes sbin directories? We should think safety first here.

Should the code use /bin:/sbin as default on any kind of Unix/Linux?

And if not unix let the default rule or use a common Windows path for Windows. Or let the Windows default really be the empty path to force them to use a safe path.

Comments welcome. Will try and surf a little to see how others resolve this.

-- KennethLavrsen - 28 Jul 2007

Excellent debug, Kenneth.

Since the Apache user default path applies to any program run on the server via HTTP, IMHO all the {SafeEnvPath} achieves is to make TWiki harder to configure. There is no justification for this path in Codev that I can find (TWiki:Codev.SafeCGIPath is the only relevant mention). Some possible rationales:

  1. A hacker could set the path and add their own versions of the programs that TWiki execs
    • Should always use absolute paths to programs. The defaults are absolute, and all the doc advises absolute.
  2. A hacker could seed an unprivileged directory in the path with their own versions of programs
    • See 1.
  3. Another application that uses Apache could put it's own binaries in front of the ones TWiki uses
    • See 1.
  4. A plugin might rely on the path to find executables, so triggering 1..3 above
    • Then the plugin deserves a -5 in its appraisal, and no-one with any sense will install it.
This is reinforced in http://www.w3.org/Security/Faq/wwwsf4.html - TWiki is only vulnerable if it assumes that the PATH is good. If you require absolute pathnames, then you can ignore the PATH. My suggestion is:
  1. Deprecate {SafeEnvPath}
  2. Do not untaint PATH (if you don't use it, why care if it's tainted?)
  3. Enhance configure to check that the paths used for external programs are absolute. The checker for the COMMAND type (lib/TWiki/Configure/Types/COMMAND.pm) could easily be written to check this, which would allow Plugins authors to also apply this constraint (IIRC this is actually why I added the COMMAND type in the first place).

-- CrawfordCurrie - 30 Jul 2007

I think the reason why you need to untaint the PATH is that we have "use strict". It is exactly when we do not define a {SafeEnvPath} that we do not touch ENV{PATH} and then TWiki fails. As far as I have been able to read the problem occurs when a CGI program creates a sub process using an external program. So even if we call RCS with an absolute path - Perl still barfs because we do not give the new RSC process a safe path. The external program gets the same PATH as the TWiki script. In this case a path that more belongs to a root than an apache user. So I think we have to untaint the PATH.

I do not agree we should deprecate the {SafeEnvPath}. It enables the user to define a path that adds additional paths to tools he installed himself and that are not in the normal PATH. This is very useful and I am sure important for many installations.

The user may not have root access to Apache but has access to TWiki configure. This setting now enables him to define a PATH that includes maybe his own local install of RCS or some tool used in a plugin.

What I had in mind was...

All Unix variants will have a path that includes /bin. I cannot imagine any server running on any Unix without a /bin.

Windows on the other hand will have a path with C: I was thinking about making this code (PSEUDO CODE).

  • If {SafeEnvPath} is not empty, set $ENV{PATH} = {SafeEnvPath}
  • else if $ENV{PATH} contains string /bin set $ENV{PATH} = /bin:/usr/bin
  • else untaint $ENV{PATH}

This way anyone using Unix/Linux/Sun etc will have a useful default which will work in 99% of the times. And it is a safe path to directories in which Apache cannot write new files or alter existing files. If their installation is special they simply add a path to {SafeEnvPath}.

Anyone with Windows will never have a secure path anyway in practical because you never know what is setup in Windows and the installation of TWiki in Windows is not standard. People will almost always need to modify the path anyway. We could guess a path for Windows also but I am sure we will miss the placement of RCS in 90% of the times so then it is better to leave the path as default.

Only cygwin users will have a /bin in the path and here the default /bin:/usr/bin will not work. But also with cygwin we cannot know where the user installed RCS or where he installed cygwin. But maybe we can somehow detect that we are dealing with cygwin and then not set the default /bin:/usr/bin

If you agree I can implement the simple case easily I outlined above and update the help text in TWiki.conf also.

If someone has experience to share for cygwin then please share.

-- TWiki:Main.KennethLavrsen - 30 Jul 2007

I have looked at quite a lot of sources to see how this is handled. The conclusion is that there is no safe and effective way to define a default PATH for certain OSes.

Surely I have seen a lot of code using $^O but at the end of the day we end up with a situation where some OSes have a default value for PATH and some don't and in one month we will all have forgotten. And as Crawford assessed - if someone hacks TWiki and can write and run perl code they can for sure also call programs by absolute path or by writing the evil code in the perl itself. It is pseudo security.

I fear we add confusion and problems by guessing paths for certain OSes while leaving others at the default PATH.

Removing {SafeEnvPath} is a bad option.

  • The features enables people to enhance a path even though they are not root. This can be important when installing certain plugins.
  • The setting enables a safer path if you want it. And the doc in configure is already well written and suggests good safe path for unix variations.

So the conclusion is to keep configure default blank, and untaint the default path ONLY when no value has been given for the {SafeEnvPath}

I have checked this in. Closing.

-- TWiki:Main.KennethLavrsen - 01 Aug 2007

ItemTemplate
Summary configure no longer has a good default for {SafeEnvPath}
ReportedBy TWiki:Main.KennethLavrsen
Codebase ~twiki4
SVN Range TWiki-4.1.2, Tue, 17 Jul 2007, build 14423
AppliesTo Engine
Component

Priority Urgent
CurrentState Closed
WaitingFor

Checkins TWikirev:14493
TargetRelease minor
ReleasedIn 4.2.0
Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r13 - 2007-08-01 - TWikiUserMapping_KennethLavrsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback