Bug 159212 - openssh account password may leak through syslog
openssh account password may leak through syslog
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: openssh (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
: Security
Depends On:
  Show dependency treegraph
Reported: 2005-05-31 12:45 EDT by J. Foehrkolb
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-06-09 18:10:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description J. Foehrkolb 2005-05-31 12:45:52 EDT
Description of problem:
This is not a bug, but rather a possible security breach vector, for which a 
trivial patch may be applied.

When a user connects and/or attempts login to openssh (any version up through 
4.x AFAIK), whether the username is valid or not, openssh writes the username 
attempted to /var/log/secure (on RedHat in particular, other systems may use 
different filenames depending on the syslog config) -- sounds fine. If, for 
whatever reason, the user logging is is legitimate, and *accidently* enters the 
password instead of the username when prompted for their username (this is 
easily done, e.g. when using PuTTY), then a cleartext password is dropped in 
the syslog! Since the chances are [should be] small of having an account 
password even close to something recognizable as a username, wouldn't it be 
prudent to never write the username given to the syslog, *if* there is no valid 
account on the system? If the account is valid, there should be less of a 
problem with writing a username, as the username should never also be the 
password (of course!). 

Couple with this observation, that if you allow logwatch to send mail daily, 
and you decide to alias
root:     someone@somwhere-else.com
in /etc/aliases, now instead of being *relatively* safe on the local system, a 
cleartext password can be transmitted through email. Ugh!

I suppose the openssh maintainer(s) (Theo) are ultimately responsible for 
enhancing their product as they see fit, however, since there is little chance 
that this "bug report" will be suitably worrisome to plenty of people, I doubt 
any action will be taken on their part. And even if it did, it would not be 
officially backported most likely, thus, users of RHEL will be stuck using an 
sshd which might eventually abet a system compromise -- not likely perhaps for 
most systems, but there's a chance.

I therefore, humbly offer, this trivial (?) patch to be included in the next 
official RHEL release of the OpenSSH package:

## cut here

--- openssh-3.6.1p2/auth.c      2003-01-18 00:24:06.000000000 -0500
+++ openssh-3.6.1p2/NEWauth.c   2005-05-31 10:47:43.000000000 -0400
@@ -263,7 +263,7 @@
            authctxt->valid ? "" : "illegal user ",
-           authctxt->user,
+           authctxt->valid ? authctxt->user : "UNKNOWN",
@@ -494,8 +494,8 @@

        pw = getpwnam(user);
        if (pw == NULL) {
-               log("Illegal user %.100s from %.100s",
-                   user, get_remote_ipaddr());
+               log("Illegal user UNKNOWN from %.100s",
+                   get_remote_ipaddr());

## cut here

this will keep from happening to you, what happened to me, using putty when I 
was tired ;)

Version-Release number of selected component:

How reproducible:
Every time

Steps to Reproduce:
1. Login to sshd with PuTTY
2. Give the cleartext password when prompted "login as: " rather than the 
expected username
3. tail /var/log/secure

Actual results:
The cleartext password is written to /var/log/secure AND when logwatch runs 
next time, the cleartext password is sent to root (and whoever else root is 
aliased to!!)

Expected results:
These are expected, but not desirable (at least not to me) results.

Additional info:
This is truly an openssh "bug", but I don't have the intestinal fortitude to 
get into an argument with Theo (who I respect greatly!) about why this is/is 
not a big deal.

If in fact the syslog file has sufficiently stingy permissions, and you never 
mail excerpts of it off-system, then this is all far from critical. But since 
there is logwatch on RHEL, I think it's quite appropriate to address this issue.

Note that this patch *only* changes the logging behavior when the login name 
does not exist in the system passwd database. In that case, instead of

May 31 11:00:12 RHEL-3 sshd[10275]: Illegal user YourPassword from
May 31 11:00:17 RHEL-3 sshd[10275]: Failed password for illegal user 
YourPassword from port 63377 ssh2

you get:

May 31 11:00:12 RHEL-3 sshd[10275]: Illegal user UNKNOWN from
May 31 11:00:17 RHEL-3 sshd[10275]: Failed password for illegal user UNKNOWN 
from port 63377 ssh2

Existing /etc/passwd users get their name logged just the same as always. 
(Maybe I should be paranoid and worry about that too? Naa!)
Comment 1 Josh Bressers 2005-06-09 18:10:27 EDT
Knowning the usernames someone is attempting to log into your system with is
both useful and wise.  There are a great deal of automated attacks against ssh
servers, knowing which users are being tried is helpful especially in the event
one of the attacks is successful.

If this is a problem for you, please consider setting a default username for
putty to use to prevent this behavior.

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