jc@heart-of-gold (John M Chambers) (11/22/88)
In article <8623@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: > In article <196@libove.UUCP> root@libove.UUCP (Jay M. Libove) writes: > |I allow the commands (in /usr/lib/uucp/L.cmds) > | rmail, /usr/lib/uucp/uucico, rnews, cunbatch, uucp, uux > | > |and my /usr/lib/uucp/USERFILE contains > | uucp, / > | , / > | > |So, how vulnerable am I? > > What did you say that phone number was? This I have to take a crack > at. The /etc/passwd file should be snatchable with one simple UUCP > command. Then, several whiles of work should produce the root password, > and since he is running stock SCO Xenix, I should be able to login as > root over the serial line. Hey, would you tell me (or even better, the newsgroup) how to do this? I've tried it with quite a few uucp installations (as part of security testing, of course :-), and the obvious ways usually fail. If the local administrators are on the ball, the USERFILE will prevent you from using just rpp386!/etc/passwd (or ~root!etc/passwd), since they start with '/'. Most versions of uucp silently drop any requests that contain "/../". So you must know of some bug that allows you to reference /etc/passwd without using any of these strings. I'd like to hear about it, so I can start looking for ways to stop you. > Surprize Jay, all of your files have just been turned to mush. And > since I can get the L.sys info for your neighbors from your machine, I > should be wrecking havoc on the net for days to come. Normally, L.sys (or Systems) is owned by uucp and has 400 or 600 permissions; the uucico daemon runs as a different id, so it can't read this file. How do you get around that? Oh, sure, if a uucp installation uses the same uid for all uucp logins, it's easy, but no admin interested in security would do something that silly, I hope. There's also the point that L.sys is outside the directory listed in the USERFILE, but I guess your answer to the above paragraph will tell me how to get around that. > You lose. Next victim. Let's see; I can volunteer my home system. There's a bit of a problem, though: I could give out the phone number (and in fact, you can get it from the uucp maps), but it won't answer. I only allow outgoing calls, because it's a home line used by humans, too. Perhaps if you send me your system's phone number plus uucico login info (or even better, post it to the newsgroup like jfh@rpp386.Dallas.TX.US did :-), I can have my system call yours, and you can have some bombs waiting for me. OK? I keep hearing all sorts of rumors about fatal uucp security bugs, but so far I haven't been able to learn much about them. Does someone have a document describing them? I don't mean the obvious ones (such as I've hinted at above). I mean bugs that are there even when you use all the normal uucp security mechanisms. Are the claims just sour grapes from uucp's competitors, or does someone know things they aren't telling the rest of us? You'd think that, since the phone companies use uucp to download stuff across the phone lines, there should be a lively group of uucp equivalents of Phone Phreaks that are breaking in all over and subverting the switches (which are mostly running Unix nowadays). But I haven't read about it yet. Am I out of touch, or is this a problem? -- From: John Chambers <heart-of-gold.mitre.org!jc> From ...!linus!!heart-of-gold!jc (John Chambers 617/217-2285) [The above opinions were packaged by volume, not by weight; some settling of contents may have occurred during distribution.]
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (11/23/88)
In article <178@heart-of-gold> jc@heart-of-gold (John M Chambers) writes: >In article <8623@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: > >Normally, L.sys (or Systems) is owned by uucp and has 400 or 600 permissions; >the uucico daemon runs as a different id, so it can't read this file. How >do you get around that? Oh, sure, if a uucp installation uses the same uid >for all uucp logins, it's easy, but no admin interested in security would do >something that silly, I hope. There's also the point that L.sys is outside Since when? The uucico program runs setuid to uucp! L.sys is used in the connection routines for dialing and for verifying system names. Both of which need to be done by uucico. Running uucico as a separate ID would be possible perhaps if you made L.sys readable by a group and put uucico in that group. But probably not without changes to uucico. >uucp's competitors, or does someone know things they aren't telling the >rest of us? Yes they do. I don't pretend to be a uucp guru (uupc yes, but thats a different story); but I know of a couple of ways to circumvent uucp. Unfortunately I don't have time to work out fixes so I'm not broadcasting details. Most of the problems I know about are fixed in modern uucp's but still are extent in a lot of running systems. The moral is if you arn't running HDB on a System V or Xenis system, bug your system provider and get it if at all possible. HDB is rumoured to have problems but is probably orders of magnitude safer than the older versions. -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
honey@mailrus.cc.umich.edu (peter honeyman) (11/24/88)
Stuart Lynne writes: >HDB is rumoured to have problems but is probably orders of magnitude safer >than the older versions. honey danber doesn't have any problems that i know of, notwithstanding the little ditty i posted last week, but that exploited a bug that was fixed in svr3.1, i.e., many years ago. (which is not to say that there are no sites running the buggy stuff, but it's easily fixed, and vendors are (now) fully aware of the problem. furthermore, my posting was incredibly buggy itself -- and i was severely chastised by norman wilson for posting "typical code produced by uucp hackers and mailer science experts: fill of bugs, written apparently without deep undestanding of the tools, and gratuitously complicated." touche', norman, and i might add "poorly tested.") peter
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (11/25/88)
In article <1970@van-bc.UUCP> sl@van-bc.UUCP (pri=-10 Stuart Lynne) writes: >In article <178@heart-of-gold> jc@heart-of-gold (John M Chambers) writes: >>In article <8623@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: >> >details. Most of the problems I know about are fixed in modern uucp's but >still are extent in a lot of running systems. The moral is if you arn't >HDB is rumoured to have problems but is probably orders of magnitude safer >than the older versions. True, even HDB has security problems (at least some recent versions). As most systems are set up, breaking uucp allows you to plant trojan horses that just about everyone will run. This *is* a serious problem. Here is one thing you can do to help: /* As things are, if someone breaks uucp they can probably break everything else by planting trojan horses in /usr/bin. Here is a secure version of uux. Copy the real uux to /usr/lib/uucp and install this as /usr/bin/uux. Make it suid root. ---s--x--x 1 root sys 684 Nov 21 11:17 /usr/bin/uux* Note that other uucp programs and news have the same problem (no one should be executing programs owned by a possibly unsecure id). */ #include <stdio.h> #define PROGRAM "/usr/lib/uucp/uux" /* change these to fit */ #define UID 105 /* nobody */ #define GID 13 /* none */ main(argc,argv) int argc; char **argv; { setuid(UID); setgid(GID); execv(PROGRAM,argv); return 1; } -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Support ISO 8859/1 zeeff%b-tech.uucp@umix.cc.umich.edu Ann Arbor, MI umix!b-tech!zeeff
honey@mailrus.cc.umich.edu (peter honeyman) (11/26/88)
if you break into bin, you can ... if you break into adm, you can ... if breaking into accounts is so easy, why not break into root and be done with it? peter
fyl@ssc.UUCP (Phil Hughes) (12/02/88)
Just to put our fears in perspective I learned the following while
teaching a UNIX seminar earlier this week:
Some vendor (I don't know their name) markets a software package for
Hospitals that runs under UNIX. The vendor requires that you have dial-in
access to your system avaiable to them and that you give them root access.
If this isn't bad enough, they require that you use a root password that
they specify. It turns out that they actually require all of their
customers use the same root password so that they won't have to remember
the specific one for your system.
I think I convinced my student to quit her job as the systems
administrator if her boss doesn't let her change their root password but
apparently there are a hundred hospitals all over the US with the same
root password and dial-in access available.
--
Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155 (206)FOR-UNIX
uw-beaver!tikal!ssc!fyl or uunet!pilchuck!ssc!fyl or attmail!ssc!fylwaters@dover.uucp (Mike Waters) (12/04/88)
In article <1555@ssc.UUCP> fyl@ssc.UUCP (Phil Hughes) writes: >Just to put our fears in perspective I learned the following while >Some vendor (I don't know their name) markets a software package for >Hospitals that runs under UNIX. The vendor requires that you have dial-in >access to your system avaiable to them and that you give them root access. >If this isn't bad enough, they require that you use a root password that >they specify. It turns out that they actually require all of their >customers use the same root password so that they won't have to remember >the specific one for your system. The first version of VMS (1.0) came with ann account FIELD, password SERVICE !!!!! DEC's field service got upset if you changed the password. Since my installation was expected to run classified (just confidential but ...), they got REAL mad at me! Since then I have reported this to DEC from several other sites, but STILL occasionally find this. > >I think I convinced my student to quit her job as the systems >administrator if her boss doesn't let her change their root password but I would hope that a demonstration of the harm (and violations of confidentiality etc.) would convince the admin.. But you are quite right some people just don't WANT to hear before something happens. -- Mike Waters (for your EDIFication) * Motorola CAD Group * Witty remark goes *HERE* Mesa, AZ ...!sun!sunburn!dover!waters * OR moto@cad.Berkley.EDU *
karl@ddsw1.MCS.COM (Karl Denninger) (12/05/88)
In article <573@dover.uucp> waters@dover.UUCP (Mike Waters) writes: >In article <1555@ssc.UUCP> fyl@ssc.UUCP (Phil Hughes) writes: >>Just to put our fears in perspective I learned the following while >>Some vendor (I don't know their name) markets a software package for >>Hospitals that runs under UNIX. The vendor requires that you have dial-in >>access to your system avaiable to them and that you give them root access. >>If this isn't bad enough, they require that you use a root password that >>they specify. It turns out that they actually require all of their >>customers use the same root password so that they won't have to remember >>the specific one for your system. > >The first version of VMS (1.0) came with ann account FIELD, password >SERVICE !!!!! DEC's field service got upset if you changed the >password. That's nothing unusual. We have a customer that sells VMS (small VAX) systems. Each is equipped with a 1200 baud modem, set up so that CD is FORCED ON, as is DTR. The terminal port is defined as a TERMINAL, not a modem. They do this because they're too cheap to (1) figure out how to make a proper cable which will enable the modems to work right, (2) they like to use REALLY cheap modems which don't handle the EIA signals right anyways, and (3) they want to be able to log out and back in without calling back long-distance. This is bad enough. If you hang up, the system doesn't know about it, and your job stays active...... if you were logged in privileged, and you're not the first person back to the machine after the disconnect...... What's worse is that DEC ships VMS with a "SYSTEM" account, with the password "MANAGER". This firm neither changes that password nor tells others to do so; as a result there are some 200 VMS systems across the country where the default system password IS valid! As a further "slap" at security, all of these machines have a second, also-privileged account, which is the same at each site (with the same password) for vendor maintenance. So, their laziness extends to an inability to keep a password database or call voice for a password first! ARRRRRGHHH!! We successfully got one site to remove this firm's access to their machine by changing these passwords (actually, change system password and disable the other account entirely, as well as enable all security audit alarms). We _failed_ in our attempts to get two other sites to do the same thing; they simply would NOT offend this vendor and risk being without their "service", even when reminded that a formatting of their disk would cause much more trouble than the need to reset a password! Security is _useless_ on an Operating System when you have vendors doing this kind of thing with their clients. None of their systems have ever been _provably_ attacked from the outside, but there have been several strange occurrances on a few of them, including the disappearance of several directories.... -- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"
paul@taniwha.UUCP (Paul Campbell) (12/06/88)
In article <2343@ddsw1.MCS.COM> karl@ddsw1.MCS.COM(Karl Denninger) writes: >In article <573@dover.uucp> waters@dover.UUCP (Mike Waters) writes: >> >>The first version of VMS (1.0) came with ann account FIELD, password >>SERVICE !!!!! DEC's field service got upset if you changed the >>password. >What's worse is that DEC ships VMS with a "SYSTEM" account, with the password >"MANAGER". This firm neither changes that password nor tells others to do To be fair the System Manager documentation tells you to change these passwords as part of system installation (also the password for UETP). It was always the first thing I did after installing a VMS system. Anyone who installs such a system and doesn't read the release notes and/or doesn't do this isn't doing their job!! Field Service only complained once, I just showed them the manual ... Paul -- Paul Campbell ..!{unisoft|mtxinu}!taniwha!paul (415)420-8179 Taniwha Systems Design, Oakland CA "Read my lips .... no GNU taxes"