Date: Thu, 18 Sep 2003 14:30:25 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: lemon <lemon@aldigital.co.uk> Cc: freebsd-questions@freebsd.org Subject: Re: upgrading libssh and rtld Message-ID: <20030918133025.GA1773@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <3F69A131.7060102@aldigital.co.uk> References: <3F69A131.7060102@aldigital.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
--zYM0uCDKw75PZbzx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Sep 18, 2003 at 01:12:33PM +0100, lemon wrote:
> hi,
>=20
> with respect to upgrading openssh on various boxes, i note that the=20
> advisory[0] details killing and restarting sshd in order to bring the=20
> new one into play.
>=20
> the base sshd is dynamically linked against libssh, the version of which=
=20
> doesn't appear to change over the upgrade.
>=20
> my question is this: does the rtld notice the change in library and=20
> reload it, or will it re-use the pre-upgrade one already in memory? the=
=20
> latter suggests only a reboot will bring the new library into play,=20
> especially if the work is being carried out over ssh, and so keeping an=
=20
> sshd in play at all times.
>=20
> i can't see any stuff in the rtld-elf source to suggest that it'll=20
> notice a change in library files, but my understanding of the linker is=
=20
> pretty flimsy.
Hmmm... good question. As far as I can tell from the rtld-elf
sources, the runtime loader follows the usual unix paradigm of open(2)
followed by mmap(2) of the shared libraries in question. ld-elf.so.1
is invoked anew for every dynamically linked process that gets
exec(3)'d.
That means that any program started after the shared library has been
updated will mmap(2) the latest version. Processes already running
end up with a file descriptor on the old version, although there's no
way to access that data from the filesystem. (This is similar to a
cunning bit of Unix trickery, where a file is open(2)'d and then
unlink(2)'d, often used to provide temporary filespace that's
absolutely private to the process.)
So, yes, restarting sshd(8) after applying the patches, recompiling
and re-installing will nullify the vulnerability.
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
--zYM0uCDKw75PZbzx
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQE/abNxdtESqEQa7a0RAjdAAJ9f7hueL2SJi4HGQraUiK0iGCDqGgCfb9TO
wItm6R9Y98jTDWfk9CmE62E=
=Lw4l
-----END PGP SIGNATURE-----
--zYM0uCDKw75PZbzx--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030918133025.GA1773>