Bug 88 - Security hole in adduser/useradd tool
Security hole in adduser/useradd tool
Product: Red Hat Linux
Classification: Retired
Component: basesystem (Show other bugs)
i386 Linux
high Severity medium
: ---
: ---
Assigned To: David Lawrence
: Security
Depends On:
  Show dependency treegraph
Reported: 1998-11-16 08:19 EST by soucym
Modified: 2016-07-05 13:48 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1998-11-16 08:49:54 EST
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 soucym 1998-11-16 08:19:22 EST
When you add a user with 5.1 it appears to be breaking a
standard (discussed this with a long-time linux user) but
the big problem I found was when adding an account for
myself other than root my password showed up in
/etc/password file IN PLAIN VIEW! It was NOT encrypted until
I ran passwd on it. Then it was encrypted. This is a serious
bug that needs to be rectified due to ANYONE monitoring that
file (/etc/password) they would be able to get users
passwords. I mailed redhat@redhat.com and got a response to
come and post the bug here. So here it is.  Email me if
there is a patch out to fix this already, but I haven't
located one.
Comment 1 Bill Nottingham 1998-11-16 08:49:59 EST
The -p option to adduser is to set the *encrypted* password;
it assumes whatever you give it is already encrypted. Notice
if you try to use whatever you specified to -p to login that
it won't work...
Comment 2 openshift-github-bot 2016-07-05 13:48:01 EDT
Commits pushed to master at https://github.com/openshift/origin

fix issue#88 - generate unique cookie based on vtep

Merge pull request #89 from rajatchopra/master

fix issue#88 - generate unique cookie based on vtep

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