Bugzilla Bug 189412

I found out that the user "p2p" on my system had a passwordless login.
It was even possible to login via ssh!
I did not create that user; I think it was created by
"net-p2p/mldonkey-2.8.2-r1"
On an older installation that problem was not existing.
I did not check yet what happens with the recent ebuilds.

genlop mldonkey:
 * net-p2p/mldonkey

     Wed Mar 14 18:23:06 2007 >>> net-p2p/mldonkey-2.8.2-r1
     Sun Apr  8 23:29:15 2007 >>> net-p2p/mldonkey-2.8.3
     Wed Apr 11 00:32:12 2007 >>> net-p2p/mldonkey-2.8.4
     Fri Jun 15 16:09:15 2007 >>> net-p2p/mldonkey-2.8.5
     Sun Jul 29 05:50:20 2007 >>> net-p2p/mldonkey-2.9.0

If you need more information please tell. I did not attach an emerge --info
because it might be irrelevant and has probably changed since March.

> I did not check yet what happens with the recent ebuilds.

Still the same thing.

<snip>
enewuser ${MLUSER} -1 /bin/bash /home/p2p users
</snip>

net-p2p please advise and fix as necessary.

(In reply to comment #1)
> enewuser ${MLUSER} -1 /bin/bash /home/p2p users

Unfortunatly I am not to aware of the password-problem in that line, are all
the others that one gets with:
grep enewuser /usr/portage/* | grep bash
fine?

(In reply to comment #3)
> Unfortunatly I am not to aware of the password-problem in that line, are all
> the others that one gets with:

enewuser doesn't set any password, the shell should be -1 (i.e. /bin/false) to
prevent this issue. If that's not possible, then mldonkey has bigger problems
than just enewuser.

If that user does need a valid shell how about a random password?

Since the last argument of enewuser [params] is passed directly to useradd this
should work:
<workaround>
enewuser ${MLUSER} -1 /bin/bash /home/${MLUSER} users --password $(dd count=1
if=/dev/random 2>/dev/null| md5sum | awk '{print $1}')
</workaround>
or am I wrong?
What is done here is I'll get some random data from the kernel (/dev/random)
and calculate the md5sum of that.
If the password is ever needed the admin can still change it.

I'll have to ask again:
Does this problem exist in all packages that use enewuser with a valid shell?

Fixed in -r3.

Arches please test and mark stable. Target keywords are:

mldonkey-2.9.0-r3.ebuild:KEYWORDS="~alpha amd64 hppa ia64 ppc ~sparc x86"

Stable for HPPA.

ia64/x86 stable

ppc stable

net-p2p/mldonkey-2.9.0-r3  USE="gd gtk -doc -fasttrack -gnutella -guionly
-magic"

1. Emerges on AMD64.
2. No collisions etc. 
3. Works on AMD64 and p2p user no longer have a valid shell. 

Portage 2.1.2.12 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.5-r4,
2.6.22-gentoo-r2 x86_64)
=================================================================
System uname: 2.6.22-gentoo-r2 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
Gentoo Base System release 1.12.9
Timestamp of tree: Mon, 03 Sep 2007 21:50:01 +0000
distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632)
[enabled]
ccache version 2.4 [enabled]
app-shells/bash:     3.2_p17
dev-java/java-config: 1.3.7, 2.0.33-r1
dev-lang/python:     2.4.4-r4
dev-python/pycrypto: 2.0.1-r6
dev-util/ccache:     2.4-r7
sys-apps/baselayout: 1.12.9-r2
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17
sys-devel/gcc-config: 1.3.16
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.21
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=nocona -Os -msse3 -pipe -fomit-frame-pointer"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf
/etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/
/etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo"
CXXFLAGS="-march=nocona -Os -msse3 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="ccache collision-protect distcc distlocks metadata-transfer
multilib-strict parallel-fetch sandbox sfperms strict test"
GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/
http://trumpetti.atm.tut.fi/gentoo/
http://ftp.snt.utwente.nl/pub/os/linux/gentoo
http://ds.thn.htu.se/linux/gentoo"
LC_ALL="en_DK.utf8"
MAKEOPTS="-j6"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/portage/local/layman/php-testing /usr/local/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="X a52 aac acl acpi aiglx alsa amd64 apache2 arts atk berkdb bitmap-fonts
cairo cdr cli cracklib crypt cups dbus dga directfb dri dts dvd dvdr dvdread
eds emboss encode evo fam fbcn ffmpeg firefox fortran ftp gd gdbm gif gphoto2
gpm gstreamer gtk hal iconv icq ieee1394 ipv6 isdnlog java jpeg kde kerberos
lm_sensors mad midi mikmod mjpeg mmx mozilla mp2 mp3 mpeg mplayer msn mudflap
ncurses nls nptl nptlonly ogg oggvorbis opengl openmp pam pcre pda pdf perl png
ppds pppd python qt qt3 qt3support qt4 quicktime readline reflection samba sdl
session spell spl sse sse2 sse3 ssl svg tcpd test threads tiff truetype
truetype-fonts type1-fonts unicode vorbis x264 xcomposite xml xorg xscreensaver
xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106
cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0
intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci"
ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file
hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route
share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux"
LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses
text" USERLAND="GNU" VIDEO_CARDS="radeon"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS, LINGUAS,
PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

amd64 stable

Hmmm, if this report is correct it is worth a GLSA in my opinion.
Comments/thoughts?

Yep, GLSA it - there's guaranteed to be systems out there with this user
created, since everyone who emerged it would have added the user.

Just noting here that mere upgrading doesn't actually solve the issue. enewuser
won't do anything if the user already exists - people who have installed this
before need to either userdel the account and then upgrade, or modify it
manually.

>Just noting here that mere upgrading doesn't actually solve the issue. enewuser
>won't do anything if the user already exists - people who have installed this
>before need to either userdel the account and then upgrade, or modify it
>manually.

I may be dense, but if you're not gonna add logic to change the shell then what
exactly is the point of adding a new revision?
FWIW, 4 other users had the same problem (valid shell with no password set) on
my system: uucp, games, postgres and jetty

> exactly is the point of adding a new revision?
Now the problem does not occur anymore on newly installed systems.

> FWIW, 4 other users had the same problem (valid shell with no password set) on
> my system: uucp, games, postgres and jetty

That is what I guessed there are probably some other packages with the same
problem.
I tried it with flexlm-9.5-r1
(enewuser flexlm -1 /bin/bash /opt/flexlm flexlm -c "FlexLM server user")
but that account seems secure.

Maybe a check like in =app-forensics/rkhunter-1.2.9
(/usr/bin/rkhunter in line 4145)
should be put in the ebuilds.

legate you're right. We'll have a GLSA to get this fixed.

GLSA 200710-25, sorry for the delay

(In reply to comment #19)
> GLSA 200710-25, sorry for the delay
> 
JFYI, there is a difference between no password and empty password.

Here is a paragraph from man 5 shadow

If the password field contains some string that is not valid result of
crypt(3), for instance ! or *, the user will not be able to use a unix password
to log in, subject to pam(7).

For the record: As mentioned in the original bug report it affects ssh if you
have PermitEmptyPasswords yes and UsePAM no.

That DOESN'T work in any case!

# cat /etc/passwd /etc/shadow | grep p2p
p2p:x:106:100:added by portage for mldonkey:/home/p2p:/bin/bash
p2p:!:13597:0:99999:7:::

# cat /etc/ssh/sshd_config | egrep "PermitEmpty|UsePAM"
PermitEmptyPasswords yes
UsePAM no

# ssh p2p@localhost
Permission denied (publickey,keyboard-interactive).

Hmmm actually I'm not able to reproduce this using enewuser.

(In reply to comment #23)
> Hmmm actually I'm not able to reproduce this using enewuser.

See Bug 193541. No idea how many people are affected by this and what caused
it.

(In reply to comment #24)
> (In reply to comment #23)
> > Hmmm actually I'm not able to reproduce this using enewuser.
> 
> See Bug 193541. No idea how many people are affected by this and what caused
> it.
Actually i don't care about that bug, but i'm little scared about how easy GLSA
with High importance can be pushed based on the wrong roots and providing
resolution unrelated to the real problem. This drops shadow on GLSA process in
overall.

This seems like a major slip:( Reopning to decide what to do. I propose an
errata.

Or perhaps just an update stating that it have to be an old install?

(In reply to comment #27)
> Or perhaps just an update stating that it have to be an old install?
> 

Close this bug since it's not reproducible
'!' in the second fiel in /etc/shadow  means that user is locked and can't
login anymore 

What mistake are we discussing here?

1) That the passwd/shadow situation cannot be reproduced with recent installs?
2) That the vulnerability (if reproduced) is invalid?

Comment 22 seems to point at (2), but I have to add there: It does work if you
enable PAM (UsePAM yes).

If we talk about (1): To update the GLSA, we'd have to find out when enewuser
was changed to insert a ":!:" instead of "::".

2 Robert Buchholz:
I installed mldonkey on 25 of march 2007, so the bug at least 7 months old.
I.e. all ebuilds later than that date is unaffected.

When updating the GLSA, please add a reference to CVE-2007-5714.

Reworded description slightly and added CVE entry.

-    This user is created with a valid login shell and no password.
+    With older Portage versions this user is created with a valid login
+    shell and no password.