Xref: utzoo comp.unix.wizards:23692 alt.security:1466 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!funic!santra!news From: jkp@cs.HUT.FI (Jyrki Kuoppala) Newsgroups: comp.unix.wizards,alt.security Subject: Re: SunOS and shared libraries, security aspects Keywords: sunos shared-libraries (non)security Message-ID: <1990Aug29.033933.10062@santra.uucp> Date: 29 Aug 90 03:39:33 GMT References: <1990Aug27.115140.27772@veritas.uucp> <1990Aug27.171211.16272@maverick.ksu.ksu.edu> Sender: news@santra.uucp (Cnews - USENET news system) Reply-To: jkp@cs.HUT.FI (Jyrki Kuoppala) Organization: Helsinki University of Technology, Finland Lines: 575 In-Reply-To: terry@eece.ksu.edu (Terry Hull) [ 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!