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.
