jkp@cs.HUT.FI (Jyrki Kuoppala) (08/29/90)
[ I'll also send this to security-alert@sun.com ] In article <1990Aug27.171211.16272@maverick.ksu.ksu.edu>, terry@eece (Terry Hull) writes: >Hmmm. If my memory serves me correctly, executables that are suid >root and linked with shared libraries, must have those libraries in >/usr/lib or /lib. Could it be these executables are trying to find >shared libraries in /usr/local/lib? The shared library path environment variable is not taken into account if uid != euid. This restriction exists to reduce the possiblity of trojan horse-style shared libraries owned by the user and executed in a privileged state. It seems, however, that Sun has again hacked together and included in their OS something without taking security aspects into account. The uid != euid check is not enough in current Unix systems; some programs which are setuid set their euid to the uid to which they're suid under and so the linker happily links in the user's own library (which could have an interesting "malloc" which does system ("cp /bin/sh /tmp/sh; chmod u+s /tmp/sh"). The problem is quite similar to the notorious IFS problem which probably still lurks around in some systems. I tried to think of a few quick ways to exploit it and came up with only /bin/login -p sync (preserver environment), if sync is an account with no password and daemon id as a common convention is. Works for any other non-password account, also. I remember somebody in alt.security earlier said that the X programs can be used to exploit the problem. Probably there are programs with which you can exploit this in the standard distribution as well, what come into mind (I haven't tested) are uucp programs and rdist. And on the subject of Sun-originated half-baked new security-hole hacks, I'll bore you a bit with an old yellow pages hole which I think I posted in September 1989 the first time to the net: Well here's something that could cause flames beginning to burn me: something about Yellow Pages I wrote last September (or perhaps before, there was no date attached). I slightly edited it to not make it such an exact recipe it was. [ written September 1989 by jkp@cs.hut.fi] Something you don't want to know about the yellow pages It appears that you can't win at all with SunOS 4.0.3c (and probably all earlier versions, too) even if you're not running yellow pages. Or for that matter with most Unixes using Sun's Yellow Pages. Let's assume three machines; securemachine, evilmachine and friendlymachine. Also, let's assume that you have a normal account on securemachine and root access to evilmachine. You want to get root access on securemachine. You also know that there's the line `friendlymachine root' on securemachine's /.rhosts. Securemachine is SunOS 4.0.3c which is not running YP. I'll explain how you can get the root access on securemachine if the domainname on securemachine is set. The relation of securemachine, evilmachine and friendlymachine is irrelevant as long as they're on the same TCP/IP network; they don't even need to be on the same continent. Get SunOS 4.0.1 binaries for ypbind, ypset and ypserv or write your own. Modify ypserv so it used your own yp database instead of the system's. Make the database contain evilmachine's IP address with the name entry as friendlymachine. Start the modified ypserv on securemachine (doesn't need to be a privileged process). Start your own ypbind on securemachine. Print the domainname of securemachine - let's assume it's `noname' as it often is when yp is not running. Give the appropriate ypset command from evilmachine as root with the 4.0.1 or your own version of ypset to set securemachine's yp server. Give the command `rsh securemachine -l root sh -i' from evilmachine and do your merry way. This probably works also on other YP implementations and you don't even need to give the ypset command from another machine. FIX: I don't see a clean fix applicable to all cases. Setting the domainname to the null string seems to help, but I haven't checked it deep enough. I don't know if running YP helps; probably not, as the portmapper didn't practice any access control last I looked (older versions even allow you to remap things from a remote host !) so anyone can just remap the ypserv to their own version. Anyway, if you choose to run YP, you're in another kind of mess altogether if you don't have the latest versions (I don't know if 4.0.3c is good enough, but I don't think it is). Running the domain name server and using the resolver libraries for host name lookup helps, but depending on your flavor of unix the group, sendmail alias, services etc. files might also be under YP. They sure are on a Sun. REAL FIX: Just fix the YP libraries to check that the ypbind process is running on a privileged IP port (that is, between 513 and 1023) and recompile all binaries. While youre at it, fix the ypbind process to bind only to ypserv processes which are on a privileged port on an IP address which corresponds to a list stored in a local file. What's that, you don't have source ? AARRGGGHH, time to reach for that PANIC switch disconnecting you from the power network and CYFV (Call Your Friendly Vendor) !!! //Jyrki Jyrki Kuoppala Helsinki University of Technology, Finland. [ Update: there are some `fixed' binaries provided by Sun; I don't know how they change the situation. Also, I don't know how SunOS 4.1 behaves. ] -- Jyrki Kuoppala Helsinki University of Technology, Finland. Internet : jkp@cs.hut.fi [130.233.251.253] BITNET : jkp@fingate.bitnet Gravity is a myth, the Earth sucks! Newsgroups: alt.security From: jkp@cs.HUT.FI (Jyrki Kuoppala) Subject: Yellow pages (was: Re: SunOS uuencode / uudecode) Message-ID: <1990May4.085957.22487@santra.uucp> Reply-To: jkp@cs.HUT.FI (Jyrki Kuoppala) Organization: Helsinki University of Technology, Finland References: <1990May2.175128.23652@santra.uucp> <1990May3.222439.23887@agate.berkeley.edu> Date: Fri, 4 May 90 08:59:57 GMT Lines: 212 In article <1990May3.222439.23887@agate.berkeley.edu>, shipley@soda (Peter Shipley) writes: >In article <1990May2.175128.23652@santra.uucp> jkp@cs.HUT.FI (Jyrki Kuoppala) writes: >>There are serious problems with the uudecode program and the default >>mail alias `decode' in SunOS. The bugs aren't specific to SunOS; they >>just occur on Suns because of stupid defaults SunOS traditionally has. [ .. ] >a bug!]. the setuiding of uudecode is a sun problem. The only reasion >for it is to stop the problems caused by the mail alias: > > decode: |/usr/bin/uudecode > >where you can overwrite deamon owned files. (no flames for posting >that line please, I have seen it on the net before). Well, you can overwrite files owned by anyone other than root as well in most cases (networked machines). The problem about telling holes still is how much to tell. If you don't tell what can be done with a hole, it's not easy for the reader to decide whether the hole is serious enough to have a serious look at. If you tell what can be done, you are pointing way to abusers. By the way, I have started keeping a list of security holes mentioned in alt.security. There hasn't been anything new in alt.security, but the point is that now when the hole has got this much publicity it finally can be considered public knowledge and can be discussed without `being careful' who you discuss it with. I'm planning to make a list of alt.security-mentioned bugs with classifications and directions for fixing the bugs. Here's an example of the classifications I've used: Classification: Is the hole external - internal to the machine: HE - can be exploited external to the machine (external) HI - can be exploited by first having a normal account on the machine Exploiting methods (for external holes): EN - via the TCP/IP network ED - via decnet EU - via uucp EL - via normal login EM - via sending mail Privileges gained by exploiting the hole: PS - by exploiting superuser status can be obtained in a few minutes or so (superuser) PA - by exploiting status as any user can be obtained in a few minutes or so (any user); usually implies PS PC - by exploiting status as one certain user (like uucp) can be obtained in a few minutes or so (certain user) PH - no status can be acquired, but something possibly harmful can be done which normally couldn't be done (like reading a file or crashing the machine) (harmful) PI - something possibly irritating can be done, like hiding oneself from programs like who, finger etc. or sending binary stuff to another user's tty Reason(s) of the hole: RG - general bad configuration manners from the vendor RB - a bug in a program causing the hole (like overrunning a buffer) RD - stupid design of a program or service causing the security hole (like the famous Sun rpc.rexd) RA - bad configuration manners from the administrator Fix availability: FF - A correct version of the program is available as free source; depending on vendor the free version might not have all the same features as the vendor's version FB - A binary fix is freely available from the net FS - A source-level fix is available for free from the net FV - A fix available from the vendor for the asking (not necessarily free) FL - Fixed in the latest OS release (for OS-specific holes) FN - No fix available short of closing the service / not running the program FC - No program fix needed; changing of modes or configuration file is sufficient OS environment / version: OG - general Unix OB - general Berkeley 4.3 OS - SunOS OX - Xenix OU - Ultrix ON - Sony NEWS O2 - System V rel. 2 O3 - System V rel. 3 O4 - System V rel. 4 OG - GNU programs OU - programs posted on Usenet OF - other free programs available by anon. ftp etc. OC - other commercial programs A list of holes of which a mention has been in alt.security: - restore suid root security problem (sunOS 4.0 ->) HI, PS, RD, OS - NFS caches may put wrong data blocks in files - possibly exposing sensitive data HI, PI, RB, FN, OB - forging USENET messages and control messages (cancel, rmgroup etc.) HE, EN, EU, PI, RD, FN, OU - unrestricted tftpd HE, EN, PI, RG, RD, RA, FC, OB - sendmail < 5.61 security holes HE, HI, EN, EM, PA, RB, FF, OB etc., the list is not ready yet. >Needless to say, I have received a bit of heat for posting bug >information to this group. Surprisingly, I haven't received much negative feedback from publishing security holes (some time ago on the Sun-Spots mailing list, also somewhere else I think). Well here's something that could cause flames beginning to burn me: something about Yellow Pages I wrote last September (or perhaps before, there was no date attached). I slightly edited it to not make it such an exact recipe it was. [ written September 1989 by jkp@cs.hut.fi] Something you don't want to know about the yellow pages It appears that you can't win at all with SunOS 4.0.3c (and probably all earlier versions, too) even if you're not running yellow pages. Or for that matter with most Unixes using Sun's Yellow Pages. Let's assume three machines; securemachine, evilmachine and friendlymachine. Also, let's assume that you have a normal account on securemachine and root access to evilmachine. You want to get root access on securemachine. You also know that there's the line `friendlymachine root' on securemachine's /.rhosts. Securemachine is SunOS 4.0.3c which is not running YP. I'll explain how you can get the root access on securemachine if the domainname on securemachine is set. The relation of securemachine, evilmachine and friendlymachine is irrelevant as long as they're on the same TCP/IP network; they don't even need to be on the same continent. Get SunOS 4.0.1 binaries for ypbind, ypset and ypserv or write your own. Modify ypserv so it used your own yp database instead of the system's. Make the database contain evilmachine's IP address with the name entry as friendlymachine. Start the modified ypserv on securemachine (doesn't need to be a privileged process). Start your own ypbind on securemachine. Print the domainname of securemachine - let's assume it's `noname' as it often is when yp is not running. Give the appropriate ypset command from evilmachine as root with the 4.0.1 or your own version of ypset to set securemachine's yp server. Give the command `rsh securemachine -l root sh -i' from evilmachine and do your merry way. This probably works also on other YP implementations and you don't even need to give the ypset command from another machine. FIX: I don't see a clean fix applicable to all cases. Setting the domainname to the null string seems to help, but I haven't checked it deep enough. I don't know if running YP helps; probably not, as the portmapper didn't practice any access control last I looked (older versions even allow you to remap things from a remote host !) so anyone can just remap the ypserv to their own version. Anyway, if you choose to run YP, you're in another kind of mess altogether if you don't have the latest versions (I don't know if 4.0.3c is good enough, but I don't think it is). Running the domain name server and using the resolver libraries for host name lookup helps, but depending on your flavor of unix the group, sendmail alias, services etc. files might also be under YP. They sure are on a Sun. REAL FIX: Just fix the YP libraries to check that the ypbind process is running on a privileged IP port (that is, between 513 and 1023) and recompile all binaries. While youre at it, fix the ypbind process to bind only to ypserv processes which are on a privileged port on an IP address which corresponds to a list stored in a local file. What's that, you don't have source ? AARRGGGHH, time to reach for that PANIC switch disconnecting you from the power network and CYFV (Call Your Friendly Vendor) !!! //Jyrki Jyrki Kuoppala Helsinki University of Technology, Finland. [ Update: there are some `fixed' binaries provided by Sun; I don't know how they change the situation. Also, I don't know how SunOS 4.1 behaves. ] -- Jyrki Kuoppala Helsinki University of Technology, Finland. Internet : jkp@cs.hut.fi [130.233.251.253] BITNET : jkp@fingate.bitnet Gravity is a myth, the Earth sucks! Newsgroups: alt.security From: jkp@cs.HUT.FI (Jyrki Kuoppala) Subject: Yellow pages (was: Re: SunOS uuencode / uudecode) Message-ID: <1990May4.085957.22487@santra.uucp> Reply-To: jkp@cs.HUT.FI (Jyrki Kuoppala) Organization: Helsinki University of Technology, Finland References: <1990May2.175128.23652@santra.uucp> <1990May3.222439.23887@agate.berkeley.edu> Date: Fri, 4 May 90 08:59:57 GMT Lines: 212 In article <1990May3.222439.23887@agate.berkeley.edu>, shipley@soda (Peter Shipley) writes: >In article <1990May2.175128.23652@santra.uucp> jkp@cs.HUT.FI (Jyrki Kuoppala) writes: >>There are serious problems with the uudecode program and the default >>mail alias `decode' in SunOS. The bugs aren't specific to SunOS; they >>just occur on Suns because of stupid defaults SunOS traditionally has. [ .. ] >a bug!]. the setuiding of uudecode is a sun problem. The only reasion >for it is to stop the problems caused by the mail alias: > > decode: |/usr/bin/uudecode > >where you can overwrite deamon owned files. (no flames for posting >that line please, I have seen it on the net before). Well, you can overwrite files owned by anyone other than root as well in most cases (networked machines). The problem about telling holes still is how much to tell. If you don't tell what can be done with a hole, it's not easy for the reader to decide whether the hole is serious enough to have a serious look at. If you tell what can be done, you are pointing way to abusers. By the way, I have started keeping a list of security holes mentioned in alt.security. There hasn't been anything new in alt.security, but the point is that now when the hole has got this much publicity it finally can be considered public knowledge and can be discussed without `being careful' who you discuss it with. I'm planning to make a list of alt.security-mentioned bugs with classifications and directions for fixing the bugs. Here's an example of the classifications I've used: Classification: Is the hole external - internal to the machine: HE - can be exploited external to the machine (external) HI - can be exploited by first having a normal account on the machine Exploiting methods (for external holes): EN - via the TCP/IP network ED - via decnet EU - via uucp EL - via normal login EM - via sending mail Privileges gained by exploiting the hole: PS - by exploiting superuser status can be obtained in a few minutes or so (superuser) PA - by exploiting status as any user can be obtained in a few minutes or so (any user); usually implies PS PC - by exploiting status as one certain user (like uucp) can be obtained in a few minutes or so (certain user) PH - no status can be acquired, but something possibly harmful can be done which normally couldn't be done (like reading a file or crashing the machine) (harmful) PI - something possibly irritating can be done, like hiding oneself from programs like who, finger etc. or sending binary stuff to another user's tty Reason(s) of the hole: RG - general bad configuration manners from the vendor RB - a bug in a program causing the hole (like overrunning a buffer) RD - stupid design of a program or service causing the security hole (like the famous Sun rpc.rexd) RA - bad configuration manners from the administrator Fix availability: FF - A correct version of the program is available as free source; depending on vendor the free version might not have all the same features as the vendor's version FB - A binary fix is freely available from the net FS - A source-level fix is available for free from the net FV - A fix available from the vendor for the asking (not necessarily free) FL - Fixed in the latest OS release (for OS-specific holes) FN - No fix available short of closing the service / not running the program FC - No program fix needed; changing of modes or configuration file is sufficient OS environment / version: OG - general Unix OB - general Berkeley 4.3 OS - SunOS OX - Xenix OU - Ultrix ON - Sony NEWS O2 - System V rel. 2 O3 - System V rel. 3 O4 - System V rel. 4 OG - GNU programs OU - programs posted on Usenet OF - other free programs available by anon. ftp etc. OC - other commercial programs A list of holes of which a mention has been in alt.security: - restore suid root security problem (sunOS 4.0 ->) HI, PS, RD, OS - NFS caches may put wrong data blocks in files - possibly exposing sensitive data HI, PI, RB, FN, OB - forging USENET messages and control messages (cancel, rmgroup etc.) HE, EN, EU, PI, RD, FN, OU - unrestricted tftpd HE, EN, PI, RG, RD, RA, FC, OB - sendmail < 5.61 security holes HE, HI, EN, EM, PA, RB, FF, OB etc., the list is not ready yet. >Needless to say, I have received a bit of heat for posting bug >information to this group. Surprisingly, I haven't received much negative feedback from publishing security holes (some time ago on the Sun-Spots mailing list, also somewhere else I think). Well here's something that could cause flames beginning to burn me: something about Yellow Pages I wrote last September (or perhaps before, there was no date attached). I slightly edited it to not make it such an exact recipe it was. [ written September 1989 by jkp@cs.hut.fi] Something you don't want to know about the yellow pages It appears that you can't win at all with SunOS 4.0.3c (and probably all earlier versions, too) even if you're not running yellow pages. Or for that matter with most Unixes using Sun's Yellow Pages. Let's assume three machines; securemachine, evilmachine and friendlymachine. Also, let's assume that you have a normal account on securemachine and root access to evilmachine. You want to get root access on securemachine. You also know that there's the line `friendlymachine root' on securemachine's /.rhosts. Securemachine is SunOS 4.0.3c which is not running YP. I'll explain how you can get the root access on securemachine if the domainname on securemachine is set. The relation of securemachine, evilmachine and friendlymachine is irrelevant as long as they're on the same TCP/IP network; they don't even need to be on the same continent. Get SunOS 4.0.1 binaries for ypbind, ypset and ypserv or write your own. Modify ypserv so it used your own yp database instead of the system's. Make the database contain evilmachine's IP address with the name entry as friendlymachine. Start the modified ypserv on securemachine (doesn't need to be a privileged process). Start your own ypbind on securemachine. Print the domainname of securemachine - let's assume it's `noname' as it often is when yp is not running. Give the appropriate ypset command from evilmachine as root with the 4.0.1 or your own version of ypset to set securemachine's yp server. Give the command `rsh securemachine -l root sh -i' from evilmachine and do your merry way. This probably works also on other YP implementations and you don't even need to give the ypset command from another machine. FIX: I don't see a clean fix applicable to all cases. Setting the domainname to the null string seems to help, but I haven't checked it deep enough. I don't know if running YP helps; probably not, as the portmapper didn't practice any access control last I looked (older versions even allow you to remap things from a remote host !) so anyone can just remap the ypserv to their own version. Anyway, if you choose to run YP, you're in another kind of mess altogether if you don't have the latest versions (I don't know if 4.0.3c is good enough, but I don't think it is). Running the domain name server and using the resolver libraries for host name lookup helps, but depending on your flavor of unix the group, sendmail alias, services etc. files might also be under YP. They sure are on a Sun. REAL FIX: Just fix the YP libraries to check that the ypbind process is running on a privileged IP port (that is, between 513 and 1023) and recompile all binaries. While youre at it, fix the ypbind process to bind only to ypserv processes which are on a privileged port on an IP address which corresponds to a list stored in a local file. What's that, you don't have source ? AARRGGGHH, time to reach for that PANIC switch disconnecting you from the power network and CYFV (Call Your Friendly Vendor) !!! //Jyrki Jyrki Kuoppala Helsinki University of Technology, Finland. [ Update: there are some `fixed' binaries provided by Sun; I don't know how they change the situation. Also, I don't know how SunOS 4.1 behaves. ] To soften the Sun-bashing a bit, they have been responsive to bug reports, but one of the main problems seems to be that when a bug is fixed, the fix generally gets to customers only when the next release of the OS is released / distributed, so it may take a year or two. For a security hole, this is not acceptable. If you feel that security fixes should be distributed by Sun, please tell them about this and if you are considering other vendors, please tell that too - I would think that it's in Sun's interests to not scare away customers by not distributing security fixes. The problem with fixes is very serious for those who don't have source; they can't fix the problems for themselves. That's why Sun is needed. And in my opinion, that's one of the reasons binary-only distributions are very bad compared to distributions where you get source, too. -- Jyrki Kuoppala Helsinki University of Technology, Finland. Internet : jkp@cs.hut.fi [130.233.251.253] X400 : /C=fi/A=fumail/P=inet/O=hut/OU=cs/S=Kuoppala/G=Jyrki BITNET : jkp@fingate.bitnet Gravity is a myth, the Earth sucks!
junk1@cbnews.att.com (eric.a.olson) (08/30/90)
In article <1990Aug29.033933.10062@santra.uucp> jkp@cs.HUT.FI (Jyrki Kuoppala) writes: >[ I'll also send this to security-alert@sun.com ] > >In article <1990Aug27.171211.16272@maverick.ksu.ksu.edu>, terry@eece (Terry Hull) writes: >>Hmmm. If my memory serves me correctly, executables that are suid >>root and linked with shared libraries, must have those libraries in >>/usr/lib or /lib. Could it be these executables are trying to find >>shared libraries in /usr/local/lib? > >The shared library path environment variable is not taken into account >if uid != euid. This restriction exists to reduce the possiblity of >trojan horse-style shared libraries owned by the user and executed in >a privileged state. > >It seems, however, that Sun has again hacked together and included in .... Hold on... I thought I had been keeping up-to-date... but I've never heard of a shared library path environment variable! I can understand the reason for such a thing... Can someone please point me to the appropriate mpage for more info? Or is this inappropriate for 386 AT&T 3.2.2?
guy@auspex.auspex.com (Guy Harris) (09/01/90)
>It seems, however, that Sun has again hacked together and included in >their OS something without taking security aspects into account. The >uid != euid check is not enough in current Unix systems; some programs >which are setuid set their euid to the uid to which they're suid under Err, well, if it's set-uid, when it starts up its euid already *is* the uid to which it's suid. I don't think that's what you meant to say.... >and so the linker happily links in the user's own library The libraries are mapped in before "main()" is called, so whether LD_LIBRARY_PATH is ignored depends only on the settings of the effective and real UID and GID at the time the program is initially started up, and is independent of what the program does after that. (Yes, I tried it.) >I tried to think of a few quick ways to exploit it and came up with only >/bin/login -p sync (preserver environment), if sync is an account with no >password and daemon id as a common convention is. OK, so the problem is something quite different from what you were saying it is. The problem isn't that "/bin/login "set(s) (its) euid to the uid to which it's suid", it's that, when invoked with the "-p" flag it passes LD_LIBRARY_PATH (and possibly other dangerous environment variables) through when it runs the login shell of an account with no password and that has a reasonably-privileged user ID. The fix ain't to change "ld.so"s rules for when it should honor LD_LIBRARY_PATH, it's to change "login" to be more selective about which environment variables it'll pass through.
jkp@cs.HUT.FI (Jyrki Kuoppala) (09/02/90)
In article <3991@auspex.auspex.com>, guy@auspex (Guy Harris) writes: >>It seems, however, that Sun has again hacked together and included in >>their OS something without taking security aspects into account. The >>uid != euid check is not enough in current Unix systems; some programs >>which are setuid set their euid to the uid to which they're suid under > >Err, well, if it's set-uid, when it starts up its euid already *is* the >uid to which it's suid. I don't think that's what you meant to say.... Oops, sorry, of course I meant to say that some programs set their real uid to the euid (the uid to which they're suid under), and this is the problem. >>and so the linker happily links in the user's own library > >The libraries are mapped in before "main()" is called, so whether >LD_LIBRARY_PATH is ignored depends only on the settings of the effective >and real UID and GID at the time the program is initially started up, >and is independent of what the program does after that. (Yes, I tried >it.) Yes, but some programs start _other_ programs after setting uid to euid; in this case, euid == uid and when this other program (like when /bin/login starts the login shell /bin/sync) is loaded the LD_LIBRARY_PATH is used. This is the problem, sorry if I was a bit unclear. >>I tried to think of a few quick ways to exploit it and came up with only >>/bin/login -p sync (preserver environment), if sync is an account with no >>password and daemon id as a common convention is. > >OK, so the problem is something quite different from what you were >saying it is. The problem isn't that "/bin/login "set(s) (its) euid to >the uid to which it's suid", it's that, when invoked with the "-p" flag >it passes LD_LIBRARY_PATH (and possibly other dangerous environment >variables) through when it runs the login shell of an account with no >password and that has a reasonably-privileged user ID. The fix ain't to >change "ld.so"s rules for when it should honor LD_LIBRARY_PATH, it's to >change "login" to be more selective about which environment variables >it'll pass through. Yes; and change all those dozen's of other programs (like the ones which come from the Usenet) to also unsetenv LD_LIBRARY_PATH when they do setuid(geteuid()). No, I don't really know if this is common but it's hard to know exactly what programs do this (especially for SunOS binary users) and so the problem is hard to solve this way. And I haven't figured out a good way to change LD_LIBRARY_PATH semantics. Perhaps a kludge to the setuid() function which unsetenv's LD_LIBRARY_PATH when euid != uid and setuid() is used to set it to the real uid ? This would solve the problem in the general case, you would just have to recompile (umm, with shared libraries you wouldn't have to recompile, something useful about them too ;-) However, the security aspects of LD_LIBRARY_PATH should be documented (well, I don't know if they are, I haven't read all the SunOS manuals). So, anyone see somthing wrong with the solution: We write a kludged setuid() to unsetenv LD_LIBRARY_PATH and distribute it with instructions of how to install it in your machine's shared library. We also find out which staticcally-linked programs have the problem and instruct users to recompile them and distribute fixed binaries for binary-only users. //Jyrki [ I vote for creation of a newsgroup called comp.unix.wizards ]
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (09/12/90)
jkp@cs.HUT.FI (Jyrki Kuoppala) writes: >So, anyone see somthing wrong with the solution: We write a kludged >setuid() to unsetenv LD_LIBRARY_PATH and distribute it with >instructions of how to install it in your machine's shared library. >We also find out which staticcally-linked programs have the problem >and instruct users to recompile them and distribute fixed binaries for >binary-only users. Yes. A kludge is a kludge, and should be avoided at all costs. What we really need is an option to ldconfig that allows the system administrator to specify path components in LD_LIBRARY_PATH that will be honoured by setuid programs. Or perhaps the option should just hardwire a value for LD_LIBRARY_PATH that's used by setuid programs. The latter isn't quite as nice a solution, though (IMHO). Something like: ldconfig [ directory ... ] [ [ -T directory ] ... ] where the -T flag is used to specify directories that are "trusted" in the sense that they would be searched by ld when running a setuid program. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca The only thing open about OSF is their mouth. --Chuck Musciano
guy@auspex.auspex.com (Guy Harris) (09/13/90)
>Yes. A kludge is a kludge, and should be avoided at all costs. What we >really need is an option to ldconfig that allows the system administrator >to specify path components in LD_LIBRARY_PATH that will be honoured by >setuid programs. Yes, some mechanism such as that - which might *also* want to, e.g., allow the system administrator to specify path components in boring old PATH that set-UID programs can trust - might be nice. It would, however, *NOT* affect the problem Jyrki is discussing! The problem there isn't with setUID programs, it's with programs that 1) let you run e.g. some user's login shell, under their UID, even if that user's account has no password (in which case it won't ask you for a password), and 2) pass LD_LIBRARY_PATH (or any of various other environment variables, although the others can generally be reamed out of the environment very early on in "main()", while LD_LIBRARY_PATH is used before "main()" is even called) through unmolested when running said login shells.