Bug 49181 - rexec lets anyone inpersonate anyone with a .rhosts file
Summary: rexec lets anyone inpersonate anyone with a .rhosts file
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rsh   
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact: David Lawrence
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-16 17:35 UTC by leonb
Modified: 2015-03-05 01:09 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-20 17:36:17 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description leonb 2001-07-16 17:35:38 UTC
Description of Problem:

/etc/pam.d/rexec specifies
  auth sufficient /lib/security/pam_rhosts_auth.so                       
This allows rhosts authentication like rsh.
But, unlike the rsh daemon, the rexec daemon
does not require that the tcp connection
originates from a privileged port 
and therefore that the remote username is
provided by a trusted application.
Any user can replicate the rexec protocol
and specify arbitrary remote username.  This username
will then be considered for rhost authentication.

Steps to Reproduce:

1.   Enable rexec service
2.   Setup user joe on machine foo and bar
3.   On bar, insert foo in joe's .rhosts file
4.   Log as guest user on foo
5.   Connect to rexec service on bar  
     using an unprivileged port number.
6.   Execute rexec protocol specifying joe
     as local and remote user name to joe.
     Any password will do.  Command is "rm *".
7.   PAM performs rhost authentication for joe
     and accepts the connection.
8.   Joe's files on bar are detroyed


Remove the offending line in /etc/pam.d/rexec.
Traditional rexec does not honor rhost
authentication anyway.

Rhost authentication should only be used
when the remote user name can be trusted.
Meaning that :
1) the remote machine is trusted 
     (the user should not specify untrusted machines in .rhost)
2) the protocol was executed by a trusted program
     (i.e. by a hopefully secure setuid program
         that is allowed to open privileged sockets) 

Neither rsh nor rlogin nor rexec are very secure to start 
with (monitoring ip traffic reveals clear text passwords,
fake ip packets can pass as privileged packers, etc.)

But rhost authentication in rexec makes it a lot weaker,
because the attacker does not even need local root

Comment 1 Phil Knirsch 2001-07-24 11:33:40 UTC
Ok, removed the line.

Fix should appear in rawhide soon.

Read ya, Phil

Note You need to log in before you can comment on or make changes to this bug.