Bug 167986

This is now fixed with release tog-pegasus-2.4.1-4.2.rhel4 .

To clarify: the PAM authentication stack used in previous versions would always
invoke the PAM_FAIL_DELAY processing and delay for at least 1 second on
authentication failures, which would also be logged to /var/log/secure.

Also, it always has been impossible to connect with the pegasus HTTPS service
(the only one enabled by default) without copying the /etc/Pegasus/*.pem 
SSL certificate files from the server .

There is also the option of associating user names with the client.pem file
so that no user names or passwords ever have to be exchanged at all, ie. no
HTTP authentication needs to be done at all, but this takes configuration 
effort from users.

Now, with the new release there are new /etc/pam.d/wbem and
/etc/Pegasus/access.conf pam_access.so configuration files, which disallow any
root authentication attempt from the  network, so the pegasus network services
cannot be used to crack the root password in any way.

There is a new 'pegasus' user that will be the only user allowed to authenticate
using a system userid and password over the network with the HTTP authenticate 
method, as configured in the default access.conf. All userids and passwords are
encrypted so that snooping is not possible, unless users specifically enable 
plaintext HTTP, which they are explicitly warned not to do in the documentation.

The pegasus user need not be in the system password database; it could be 
a kerberos, nis or ldap user as configured with the nsswitch.conf and PAM stack.

The access.conf allows only the 'pegasus' or 'root' users to access the 
service over the localhost ports . root is allowed to authenticate via
the localhost ports for testing purposes, but the passwords are still
encrypted.

Users can also disable authentication altogether so that no userid / password
is ever exchanged.

There used to be a separate 'cimservera' process whose only purpose was to
invoke the pam authentication stack - the cimserver used to write the 
userid and password in plaintext over this process' pipe .

The cimservera process has now been removed as no need for it could be 
determined, removing another possible attack in using 'strace' to view
the plaintext passwords sent over the pipe.

Any authenticated user may still use the pegasus service locally through
the unix socket - such users are deemed to be authenticated already by
the system.

There is also a full featured hierarchical 'authorisation' system to grant
or deny 'authenticated' users access to different CIM namespaces and resources,
as configured through the 'cimauth' and 'cimuser' commands, so different users
can have privileges to view different resources or access different providers.

So I don't think that all use of the system authentication system by tog-pegasus
should be removed, since it is now used in a safe way, existing pegasus users
will expect to be able to use system userids, and there are serveral methods
whereby administrators can configure pegasus not to do system user
authentication at all.

Jason, did you intend for this bug to be public?

Which part is going to set the password for this user? It is very unwise to have
a default the-same-everywhere password....

In reply to Arjan's Comment #3:
Users must set the password for the pegasus user before they can access the
network services.
There is a document explaining these security features shipped in 
  /usr/share/doc/tog-pegasus-2.4.1/README.RedHat.Security

In reply to Marks's Comment #4:
Hi Mark - yes, all tog-pegasus bugs need to be public so that people from the
OpenGroup can read them.
 

This statement is incorrect:  "Also, it always has been impossible to connect
with the pegasus HTTPS service (the only one enabled by default) without copying
the /etc/Pegasus/*.pem  SSL certificate files from the server .".  My
demonstration showed that you can quite happily connect and authenticate on a
default installation without any certificate authentication.

Okay, so you're restricting this to the pegasus user from remote.  

However this still means that an attacker who is able to connect to the pegasus
port on a server could still end up with a password for a valid local user.  (a
server which has the pegasus port open allowing anyone to connect and also has
ssh running - the attacker devines the pegasus user password then logs into the
server using ssh).  Sure, you could stop this attack by making sure that the
pegasus port is correctly firewalled to allow only trusted hosts, or by making
sure all your other pam configurations explicitly deny the 'pegasus' user, but
that isn't the default we're shipping.

Sharing passwords between applications and the system is a bad idea.  If
existing pegasus users are expecting to be able to use system userids then they
ought to be educated why this is a bad idea.

Can we not default to using the old pegasus method of authentication, a separate
password file, by default out of the box.  Or an alternative perhaps would be to
just enable client certificate checking.

In reply to the last Comment #5:

It really is impossible to connect to the HTTPS port 5989 
(the only port listened to by default) without having the
same client.pem file on the server and the client, or having
set up client trust-store (SSL certificate) userid association
and authentication without passwords. 

To clarify:
If you install 2 default tog-pegasus systems on different machines,
run the server on one, and on then on the do
  # osinfo -s -h $server -u pegasus
You will get a 'failure to connect' error because the client.pem SSL
certificate file is not shared.
No host is allowed to do:
  # osinfo -s -h $server -u root
anymore, unless authentication is disabled or userid trust-store
SSL certificate authentication is enabled (bypassing PAM), in which
case no passwords are exchanged.

If you can find a way breaking the above, please let me know - this
would be a new bug.

Hence clients must have been able to authenticate with 
the server (or vice versa) to share the client.pem file.

Only if the user is unwise enough to enableHttpService is
the plaintext HTTP port 5988 listened to; yes, in this case,
if authentication is enabled, then plaintext system passwords 
will be sent .

This statement is incorrect:
"
However this still means that an attacker who is able to connect to the pegasus
port on a server could still end up with a password for a valid local user.
"
The pegasus user is an "/sbin/nologin" user account, and use of the pegasus
account with ssh would not grant anyone access to the system - this is why
the new pegasus network authentication policy is more secure than the previous
version - no passwords that grant system login access are exchanged by pegasus
over the network by default.

Speaking of openssh, sshd rather breaks the rule about 
"Sharing passwords between applications and the system is a bad idea" .

Pegasus' use of system passwords is in fact more secure than sshd's because 
a client SSL certificate must be shared between the server and client,
and pegasus, unlike ssh, does not grant login access to users, nor does it
provide a plaintext authentication mechanism by default. 

Also, sshd has no SELinux policy in RHEL-4 .

By default, pegasus provides no security sensitive information.

Many pegasus users choose to disable authentication altogether and not use
any system userids / passwords. Providers can be enabled which do provide
security sensitive information, but this requires modifying the default
configuration. 

The most common use of pegasus is simply to automatically deploy it on all
machines on the network, so that a central network management application
can check the OS, platform, and runtime status of all machines on the network,
which really does not require much security, unless traffic goes accross a
DMZ to the WAN.

RE: "If existing pegasus users are expecting to be able to use system userids
    then they ought to be educated why this is a bad idea."
Yes, this was the idea behind enabling only a non-login nominal "pegasus"
userid over the network by default, and of providing the README.RedHat.Security
file. 

Really, I do not think tog-pegasus-2.4.1-4.2.rhel4 presents any security
threat anymore - if you can prove otherwise, please do so with concrete
examples.

> It really is impossible to connect to ... 5989 without having the
> same client.pem file on the server and the client, or having
> set up client trust-store (SSL certificate) userid association
> and authentication without passwords. 

Although you are correct, osinfo won't connect without a client.pem I'm still
able to divine the pegasus user password.

So here is what I'm doing

On machine 1 I downloaded and installed "tog-pegasus-2.4.1-4.2.rhel4".  I then
ran /sbin/service tog-pegasus start to start it running.  I made no
configuration changes, this is the out-of-the-box configuration.  As root I set
the pegasus password to be 'x'

On machine 2, which does not have a pegasus installation and is a clean install
of RHEL3 I use OpenSSL to probe Machine 1 on port 5989.  By sending queries by
hand I can figure out what the pegasus user password is.  Worked out in advance,
basic http encoding of 
       user: pegasus   password: y  -> cGVnYXN1czp5
       user: pegasus   password: x  -> cGVnYXN1czp4

example runs on machine 2  ( >>> is what I type )

>>> openssl s_client -connect 192.168.0.2:5989
    ...
    New, TLSv1/SSLv3, Cipher is AES256-SHA
    ...
    ---
>>> POST / HTTP/1.0
>>> Content-Length: 60
>>> Authorization: Basic cGVnYXN1czp5
    HTTP/1.1 401 Unauthorized

Okay, so user pegasus with password 'y' isn't correct.

>>> openssl s_client -connect 192.168.0.2:5989
    ...
    New, TLSv1/SSLv3, Cipher is AES256-SHA
    ...
    ---
>>> POST / HTTP/1.0
>>> Content-Length: 60
>>> Authorization: Basic cGVnYXN1czp4
    HTTP/1.1 400 Bad Request

Aha, user "pegasus" with password "x" is correct (I'm expecting to see this is a
bad request since I didn't send anything useful to pegasus)

Looking at cimconfig it appears that the build doesn't require a client
certificate to allow a connection by default.  To make it do so you have to set
the following:

enableHttpConnection=true
sslClientVerificationMode=required
sslTrustStoreUserName=pegasus

Once I'd done that configuration I was unable to connect remotely to port 5989
without a client certificate.

RE: Comment #8: The setting 
  'enableHttpConnection=true
  '
only enables the plain text HTTP connection on port 5988, which is a bad idea.

RE: Comment #7: 'Although you are correct, osinfo won't connect without a
client.pem I'm still able to divine the pegasus user password.'

Yes, none of the pegasus client tools, including osinfo will allow connections
on the SSL port without a client certificate being shared between the server
and client.

You can use the 'openssl s_client -connect' to use the server certificate by
default, but none of the pegasus client tools operate that way.

And even if you are able to hack in with 'openssl s_client -connect', you must
still guess the pegasus user's password, so you're no better off than having
the client certificate installed and using 'osinfo' to try password values .
At no point are the passwords sent unencrypted over the network, and all 
authentication failure attempts are still subject to PAM's >1 second delay .

Even if we did not use any system passwords, people could still try connecting 
and guessing the password value; but with a 1 second delay on failures, many
years could be needed before a correct guess was made.

And even if a user was able to guess the pegasus password, it wouldn't get them
anywhere : they are unable to login at all using the pegasus account.

The default pegasus installation provides NO security sensitive information.

In a situation where pegasus security was an issue, eg. if security sensitive
information was provided by enabling non-default providers, then administrators
would use the sslClientVerificationMode / sslTrustStoreUserName SSL client 
certificate authentication, which bypasses password authentication entirely.

The majority of users of pegasus would want to automatically install it on
all machines on an internal LAN to just give basic 'osinfo' information to a 
central network management application. If we made sslClientVerificationMode
the default, then it would be a major headache for administrators to have to
set up client certificates on all clients.

I really think the new pegasus version as shipped is secure enough .

[Just to note that the reason my configuration section above enabled http is
that you cannot set Client Certificate authentication to required unless you do
so, as documented.]

A "one second delay" on failure is not useful unless correct attempts also get
delayed -- otherwise if you get a delay you just disconnect and try again before
the 1 second is up.

RE: comment #11, From Mark J. Cox (Security Response Team) (mjc)  	
on 2005-09-12 11:18 EST:
> 
> So I believe that your new package meets the requirements for this specific bug
> to be closed.  
>
Yes, I agree, tog-pegasus-2.4.1-4.2.rhel4 is secure enough.

The context of that statement was the following message:

"Let me relist the facts based on your new package:

1. You need to have installed tog-pegasus, started it, and supplied a pegasus
user password.  Folks who want to use pegasus will have done this, others will
not.  This is a mitigation of the issue raised by this bug.

2. If you do that and your port 5989 is open to the internet then any remote
attacker could connect using their own tool and attempt to crack the pegasus
user password.  You only get one shot per connection and you'll probably end up
with a limited number of connections per second, but you'll eventually get it.  
However the mitigation here is that the pam failures are logged.

3. The pegasus user is created /sbin/nologin.  This limits the effects if an
attack based on #2 is sucessful.

So I believe that your new package meets the requirements for this specific bug
to be closed."

http://rhn.redhat.com/errata/RHEA-2005-494.html