Date: Wed, 22 Apr 1998 13:04:35 +0800 From: Peter Wemm <peter@netplex.com.au> To: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption Message-ID: <199804220504.NAA01624@spinner.netplex.com.au> In-Reply-To: Your message of "Tue, 21 Apr 1998 14:14:37 -0400." <199804211814.OAA23669@brain.zeus.leitch.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg A. Woods wrote: > [ On Tue, April 21, 1998 at 09:35:41 (-0700), Mike Smith wrote: ] > > Subject: Re: Using MD5 insted of DES for passwd ecnryption > > > > > I think it should always be possible to statically link the whole system > > > if one so desires. That's the one sure way to test if shared libraries > > > are causing any weirdness. > > > > How are you supposed to load arbitrary (possibly third-party) > > authentication modules if you have to have the source at build time? > > That's stupid. > > Maybe not the source, but at minimum the objects. Any method of > run-time control over password encryption schemes should permit all > available schemes to be statically linked simultaneously into the > relevant binaries such that a run-time "switch" can select amongst those > that were available at link time. Naturally adding more schemes > requires re-linking -- but that's neither surprising, nor upsetting. And what happens when you've got some static 3rd party binary that you can't relink, and you use a different encryption system locally? (eg: the chained secureware (as used in SCO etc) des hash method). Distributing statically linked binaries has to be strongly discouraged since it prevents things like libc bug fixes (eg: res_send() being adjusted to use poll() or large a fd_set with select() and so on). Anyway, static linking should be supported still, but what I suggested earlier is that we will have to start doing variaions on the library builds... ie: different version of libcrypt for static and dynamic mode. The static libcrypt would have the encryption/hash methods compiled in, while the dynamic version may instead be a runtime switch routine using dlopen(). Somebody (Mark?) raised the possibility of using dlopen() from within a static binary. This is "difficult" because: 1: I believe ld.so needs to be initialized early early before the main() gets called (ie in crt0.o), so your 'static' binary still uses ld.so. 2: there are no runtime symbol tables.. the md5.so routine could not make libc calls as there would not be a dynamic libc. It'd have to have things like strcmp() etc all linked in to the .so from libc_pic.a This isn't a huge problem, but adds complications. You can't safely have md5.so dynamically linked to libc.so.x.x for strcmp since that brings along malloc etc and two mallocs in the same program space (if both are active) is pretty deadly and asking for trouble. 3: ld already has a -Bforcedynamic mode to generate the necessary glue for running ld.so from binaries that don't have any shared library dependencies. All that is needed is that you need to tell gcc to link with crt0.o (the one that opens ld.so) and use -Bforcedynamic and explicitly link with static libraries and you've got a 100% static linked binary that calls ld.so at startup (which doesn nothing yet) and you can later call dlopen(). Obviously crt0.o will need to look elsewhere in case /usr/libexec/ld.so isn't available. Some gcc LINK_SPEC mods might be enough. FWIW, I'm a little amazed at the paranoia about dynamic linking. I have *never* *ever* "lost" or damaged ld.so except through stupidity (made a mistake with a source change and caused an undefined symbol). I have never lost or damaged libc.so except through stupidity (again, generally through normal development accidents with undefined symbols). I have also rendered my system "cactus" by loosing /dev/console, the entire /dev directory, damaging /sbin/init and /sbin/sh, misakes in /etc/rc and so on. ld.so and libc.so have been the *least* of my problems. I can understand the concern of people coming from systems with less robust VM systems, but we've had a system where the executable activation and mmap() etc have been pretty much unified and have been quite been solid since 2.0.5 days. I can't ever recall a situation where ld.so was unable to be successfully mmap'ed while executables themselves were loadable. > -- > Greg A. Woods > > +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> > Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com> Cheers, -Peter -- Peter Wemm <peter@netplex.com.au> Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804220504.NAA01624>