Stefan Pfetzing noticed that lshd leaks a couple of file descriptors, related to the randomness generator, to user shells which are started by lshd. This is a security problem, in at least two ways: * A user can truncate the server's seed file, which may prevent the server from starting. * By reading the file, a user can get information that may be useful for cracking other user's session keys, as well as public keys that are generated from the disclosed seed file. (To understand what the impact is, one must understand how yarrow generates and uses the seed file. My initial analysis is that reading the seed-file is advantageous only if it is read just prior to the start of some process using the seed for initialization.) This is a local hole. It provides for fairly easy denial of service by local users, and with some more effort, maybe also cracking of session keys. The below patch, relative to lsh-2.0.1, seems to solve the problem. After applying the patch, you should remove and then regenerate the server's seed file (since users may still have open fd:s), and restart lshd. I hope to be able to put together a new release sometime next week. I'll be off-line over the weekend. In the mean time, feel free to inform other distributors and appropriate security fora about the problem. Sorry for the inconvenience, /Niels *** unix_random.c.~1.17.~ 2004-11-17 22:13:27.000000000 +0100 --- unix_random.c 2006-01-20 14:26:05.000000000 +0100 *************** *** 258,263 **** --- 258,264 ---- if (self->device_fd < 0) return 0; + io_set_close_on_exec(self->device_fd); self->device_last_read = now; } *************** *** 381,386 **** --- 382,388 ---- return NULL; } + io_set_close_on_exec(self->seed_file_fd); trace("random_init, reading seed file...\n"); if (!read_initial_seed_file(&self->yarrow, self->seed_file_fd))
well, no maintainer but spanky is the (un)lucky one who is mentioned 7 times in the changelog, would you do the bumping pls? thx in advance
2.0.1-r1 in portage
arches, cast your magic spell :)
Created attachment 77994 [details] lsh-2.0.1-r1.log Fails on ppc, see attached logfile. [ebuild N ] net-misc/lsh-2.0.1-r1 USE="X pam tcpd zlib -ipv6" 0 kB
mhh, probably back to ebuild status then, any comments vapier?
(In reply to comment #4) fails at the same spot in x86, not that any of that is surprising.
it bombed because you guys dont have guile installed forced guile into DEPEND
Back to stable with fixed ebuild.
well it goes about fine until we check for collisions..it then fails because it collides with /usr/share/man/man8/sftp-server.8.gz, this naturally belongs to openssh-4.2_p1. Another fix to fix ~_~
Stable on x86 for security reasons. Sorry about the delay on this. Also please note something is missing metadata.missing 1 net-misc/lsh/metadata.xml If we can get one in there, it'd be a good thing (TM)
ppc stable
ready for glsa vote, i tend to say no.
Tend to vote NO too.
lsh-2.0.1-r2 fixes the file collision
Back to stable to let ppc and x86 mark the latest fixed version stable. Would be nice to get -r1 removed once -r2 is stable.
i dont really think we must move to 2.0.1-r2 for security 2.0.1-r1 is Good Enough imho for GLSA
lsh-2.0.1-r2 stable on ppc
thank you for the fixes, its stable on x86
Back to GLSA vote. 1 full NO and 0 YES votes so far.
Second full no and closing as resolved fixed.
