openssh unix dev - Feb 2002 - [Bug 131] Problems with sshd's compiled in default PATH.

http://bugzilla.mindrot.org/show_bug.cgi?id=131

djm at mindrot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From djm at mindrot.org  2002-03-01 09:49 -------
Such an option exists: your shell initialisation files - /etc/profile,
/etc/csh.cshrc, etc. I can't possibly imagine how using the system-defined
path
could be a security risk, unless the system itself is busted.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=131





------- Additional Comments From markus at openbsd.org  2002-03-01 10:01 -------
but /etc/profile is only sourced for interactive shells, i think.

adding /etc/ssh/environment could help



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=131





------- Additional Comments From smithj9870 at yahoo.com  2002-03-02 03:03
-------
About the shell initialization files:  I MUST strongly disagree with this
statement from both a security and system administration point of view.  Your
solution does not change the fact that the potentially dangerous/insecure path
is still compiled into the sshd binary, plus it is the responsibility of the ssh
subsystem to configure itself properly.  This path is required by the ssh daemon
so it can find its scp program, it should NOT be up to the sys admin to modify
every possible shell config file to fix this potential problem and security
hole.  Also, editing one config file is much simpler than editing at least two
(and maybe more) shell config files.  Since sshd makes the requirement that it
has to be able to find its scp program, it should be up to the ssh subsystem to
solve the problem and not leave it to shell config files.  I find your suggested
solution totally unacceptable and ask that you think about this problem a little
more.

About /etc/ssh/environment:  I did not see this mentioned in the ssh
documentation/man pages, only the $HOME/.ssh/environment file.  Will this always
be read even if the user has the corresponding file in their home directory and
will it override the PATH setting compiled into the sshd binary?

~Jason




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=131





------- Additional Comments From mouring at eviladmin.org  2002-03-02 03:32
-------
> About the shell initialization files:  I MUST strongly disagree with this
> statement from both a security and system administration point of view. 
Your
> solution does not change the fact that the potentially dangerous/insecure
path
> is still compiled into the sshd binary [..]
from defines.h
# define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin"

My God.. if that is 'potentailly dangerous/insecure'  then every UNIX
in the world's default path is insecure.   I am speaking as an admin.

At worse it addes on $PREFIX/bin.  To the *END* of the search path.  

And if you change it via --with-default-path  (like what Redhat does to include
/usr/local/bin FIRST which is lame) then you should should know what your 
doing.  
> [..], plus it is the responsibility of the ssh subsystem to configure 
> itself properly.  This path is required by the ssh daemon so it can find 
> its scp program, it should NOT be up to the sys admin to modify every
Subsystem != scp.  Subsystem is a v2 feature that is *NOT* used by scp.  
If you want to ensure that the subsystem ALWAYS finds the RIGHT file.. 
FULLY path it out in the sshd_config.  (Which is is by default: 'Subsystem 
sftp /usr/libexec/sftp-server').

Subsystem has *NOTHING* to do with scp.  Do you see a 'Subsystem scp
..'?
I sure don't.  Pretty much what scp is doing is a 'ssh user at site scp
[..]'.
No subsystems here..

I'm sorry, but if you want to complain that there is is not a
'DefaultPATH'
configuration directive do so (Better yet write up a simple patch and
provide it).  Just leave this dribble about 'security' out of it since
it is a
load of crap.

But in any case I can tell you have not a CLUE as to what the difference 
between 'remote command exec' and 'subsystems'.  You really
should do your
homework better before ranting.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=131





------- Additional Comments From smithj9870 at yahoo.com  2002-03-02 04:15
-------
Obviously you didn't read the beginning of this thread, the original
submission
was about the problem of making a relocatable package, possibly installing ssh
in an unusual path, for example lets say /home/username/bin.  That path will get
added to _PATH_STDPATH and compiled into the sshd binary.  Now install it
somewhere else and that useless and potentially dangerous path will still be in
the sshd binary, and on the new system, who knows what will be in there.  Do you
honestly believe that isn't a security problem?  What I am complaining about
is
that I am NOT adding that path by hand, instead ssh's configure script
decides
all by itself that it MUST include that path to find scp, which is a completely
WRONG assumption made by the configure script if the ssh package is relocated! 
Am I being clear enough now?

And don't make assumptions when you start your rant.  By subsystem I am
being
more general and referring to the ssh subsystem of a running computer system,
ie. the ssh programs and their config files.  The ssh configure script should
NOT make assumptions about where it thinks its scp program will always be and
compile that into the ssh daemon.  And if you don't think having an
incorrect
and unnecessary path component compiled into a root level daemon is a potential
security problem then I think you have more to learn about system administration
and security.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=131





------- Additional Comments From mouring at eviladmin.org  2002-03-02 05:42
-------
Two things.

1.  --with-default-path  will disable OpenSSH adding in the $PREFIX/bin (we 
assume that since you are smart enough to set your own default path, you will
be smart enough to know where you are putting scp).

2. 'subsystems' vs 'remote exec'.  Use the right terms if you
are going to
argue for including a feature.  Otherwise it makes you look like you've not 
bothered to learn the product.

No, I still don't feel this is a security hole unless you are doing stupid
things like --with-prefix=/home/user/  while building your package.  And if
you are then we can not do much stop you from doing stupid things. =)

And I have nothing against something called 'DefaultPATH'.. I do have
something
against people shouting the sky is falling.  As I said.. drop the 'It is a 
security issue', provide a patch, and show 
that /etc/profile, /etc/ssh/enviroment, etc are not valid generic solutions.

Relocatable packages are problematic at best depending on the web of 
dependancies.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=131





------- Additional Comments From smithj9870 at yahoo.com  2002-03-02 08:07
-------
> 1.  --with-default-path  will disable OpenSSH adding in the $PREFIX/bin (we
> assume that since you are smart enough to set your own default path, you
will
> be smart enough to know where you are putting scp).
That will only solve one of the problems, having the incorrect path compiled
into the sshd binary, not how sshd will be able to find scp if it has been moved
or installed somewhere unusual.
> 2. 'subsystems' vs 'remote exec'.  Use the right terms if
you are going to
> argue for including a feature.  Otherwise it makes you look like you've
not
> bothered to learn the product.
I am not responsible for your misunderstanding me and going on a rant.  Maybe I
should have been a little more clear, but you do not have to assume I mean
something else by subsystem and imply that I am an idiot.
> No, I still don't feel this is a security hole unless you are doing
stupid
> things like --with-prefix=/home/user/  while building your package.  And if
> you are then we can not do much stop you from doing stupid things. =)
That path was just an example.  Just because you can't think if a way to
take
advantage of a vulnerability doesn't mean the current method is 100% safe. 
Also
try to remember that not everyone installs software in the "standard"
places,
some sites might have other requirements.  Do you agree that a system with the
smallest number of vulnerabilities is more secure?  Why would you advocate
adding a directory to the path just so a daemon can find one file?  Is that
really being minimal?
> And I have nothing against something called 'DefaultPATH'.. I do
have
> something against people shouting the sky is falling.  As I said.. drop the
> 'It is a security issue', provide a patch, and show that
/etc/profile,
> /etc/ssh/enviroment, etc are not valid generic solutions.
So I guess no one ever uses ssh to login as root to do remote system
administration then?  You know for sure that there is absolutely no security
risk with the current design then?  And root doesn't have to worry about
what
sshd decides to stick in it's path just because it thinks scp is somewhere? 
Like I said before, the simplest and correct solution is to have a config option
that tells sshd where scp is, instead of adding another directory to the path
that the user might not need.  This might not be a problem if ssh is being
installed in a usual place like /usr or /usr/local, but try to think of the more
general case where some site decides to install it somewhere you never thought
of.  /etc/profile is NOT the appropriate place to put this path, it is only an
ugly kludge to fix the real problem, especially when it might only be needed so
sshd can find one thing (scp).  Why should the sys admin have to add that path
to the general system shell config scripts, and have to make sure all possible
scripts are correct, just because sshd can't find something without it?  It
should be the responsibility of sshd to configure this since it needs to know
about it.  And about patches, tell me why I should waste my time writing a patch
when my suggestion has been shot down from the very beginning and negatively
criticized over and over.  If you want people to contribute patches to an
opensource project then you should have an open mind and treat them with
respect.  Again, try to look at the more general case, not just the
"normal"
install everything in /usr case.  I think you will see that the current design
is not the best possible one.
> Relocatable packages are problematic at best depending on the web of 
> dependancies.
I know about the problems with relocatable packages, but ssh is fairly simple,
just a few executables, some documentation and a few config files.  Built
correctly, it should be easily relocatable except for one or more of the config
files.

~Jason




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=131





------- Additional Comments From markus at openbsd.org  2002-03-02 08:16 -------
% grep _PATH_DEFPATH /usr/include/paths.h 
#define _PATH_DEFPATH  
"/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin"

i don't see why it's insecure to use this path.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=131





------- Additional Comments From markus at openbsd.org  2002-03-02 08:22 -------
"the simplest and correct solution is to have a config option
that tells sshd where scp is"

that's very wrong.  sshd should not know about scp at all.
it has nothing to do with scp.  if scp is not in the default
path, then your setup is broken.  if there are dangerous things
in the default path, then the default path is wrong or your
system is broken.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=131





------- Additional Comments From mouring at eviladmin.org  2002-03-02 08:30
-------
His issue stems from two things.

1. portable may add a $PREFIX/bin if --with-default-path is not used
and $PREFIX != /usr

2. He seems to think that one can magicly detect we are doing a 'scp'
and
handle it via some magic.  What he forgets is that END USERS also need
to be able to type 'scp' at the prompt to run the command.  So either we
add the path to an internal default path or to a 'commonly used'
configuration
file (/etc/profile, /etc/ssh/enviroment, etc).

<shrug> That is my last 0.02c on the issue since it is pointless.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=131





------- Additional Comments From smithj9870 at yahoo.com  2002-03-02 09:32
-------
> % grep _PATH_DEFPATH /usr/include/paths.h 
> #define _PATH_DEFPATH  
> "/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin"
> 
> i don't see why it's insecure to use this path.
Where did I ever mention _PATH_DEFPATH?  Your point here is completely
irrelevent to what I was talking about.
> "the simplest and correct solution is to have a config option
> that tells sshd where scp is"
> 
> that's very wrong.  sshd should not know about scp at all.
> it has nothing to do with scp.
If sshd is going to execute scp on behalf of the user because of a remote scp
command, then you are wrong, it should know exactly what it is executing and
from where.  It should NOT rely on the user to have setup their path correctly. 
If you are talking about an interactive shell then you are correct.  But these
are two completely different cases!




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=131





------- Additional Comments From markus at openbsd.org  2002-03-02 09:57 -------
sshd should not know where 'ls' is stored.
sshd should not know where 'pwd' is stored.
sshd should not know where 'scp' is stored.

sshd must rely in the path, since it does not know that
there is a 'ls', a 'pwd' or a 'scp' binary.

sshd does not rely on the user setting up the path.
sshd relies on the admin to setup the path correctly, and the
path set by the admin has to be trusted.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.