root@libove.UUCP (Jay M. Libove) (11/11/88)
From article <74@dsoft.UUCP>, by root@dsoft.UUCP (Super user): > I see a lot of discussion going on about the virus that hit the net, and all > I can think of is my past experiences and what I've seen as a result. > > The Amiga's original virus came about as a harmless joke, similar to this > one. It got a great deal of coverage in the news as a result. A very short > time after that, at least three new viruses infected Amiga owners, and the > war's been running ever since. [ some text deleted ] > The point here, is that now we've got a virus on the nets. It's made > big news in the process. People are going to see this and some brilliant > idiot is going to think "Wow, what an easy way to get public recognition!" > No matter that he's going to screw someone over royally and take down systems > all over the world. He wants the prestige, he wants the audience, he wants > to be able to say he pulled something over on the bigshots. [ warning deleted ] I agree with this philosophy. That is, one incidence of anything tends to lead to other incidences of the same; physchologists will say this of suicides in high schools, police departments will say it of violent crimes, and from operating a bulletin board system some years ago I can say it (like the fellow I quoted) of trojan horses and virii on computers. So, my question is this: What bugs are known about in the many assorted versions on UUCP software that the net at large is running? I, for myself, am most concerned about whatever version SCO Xenix 286 v2.2.1 runs, but I'm sure that everyone would be interested in knowing how they are vulnerable and what they can do about it. I'll give a test case - me; I run SCO Xenix 286 v2.2.1 with the telebit trailblazer uucico upgrade (though I don't have a trailblazer modem), and I run smail 2.5 configured pretty much in the default for SCO Xenix (as patches were posted some time back). 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? -- Jay Libove ARPA: jl42@andrew.cmu.edu or libove@cs.cmu.edu 5731 Centre Ave, Apt 3 BITnet: jl42@andrew or jl42@drycas Pittsburgh, PA 15206 UUCP: uunet!nfsun!libove!libove or (412) 362-8983 UUCP: psuvax1!pitt!darth!libove!libove
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (11/14/88)
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. 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. You lose. Next victim. -- John F. Haugh II +----Make believe quote of the week---- VoiceNet: (214) 250-3311 Data: -6272 | Nancy Reagan on Artifical Trish: InterNet: jfh@rpp386.Dallas.TX.US | "Just say `No, Honey'" UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
dtynan@sultra.UUCP (Der Tynan) (11/15/88)
In article <196@libove.UUCP>, root@libove.UUCP (Jay M. Libove) writes: > > So, my question is this: What bugs are known about in the many assorted > versions on UUCP software that the net at large is running? I, for myself, > am most concerned about whatever version SCO Xenix 286 v2.2.1 runs, but I'm As far as 'smail' is concerned, you cannot send mail to a process (yet!). This will be changed in 3.0, but my guess is, the authors will make sure that it is secure. The final onus is on you. As for uucp, it is *not* safe. It has some bugs which I will publish soon. I don't think there is a problem with "anonymous" UUCP, but that doesn't mean I've tested it exhaustively either. I'll quote my new anti-virus catch-phrase; "If in doubt, cut it out!". If you're worried about security and anonymous uucp, I suggest turning it off until you are sure. As far as site-to-site UUCP is concerned, make sure the 'control' files are safe. See below. > > I allow the commands (in /usr/lib/uucp/L.cmds) > rmail, /usr/lib/uucp/uucico, rnews, cunbatch, uucp, uux Wrong. You should ONLY allow 'rnews' and 'rmail'. What you have is a big security hole. For example, cunbatch is called by rnews only. None of the other commands should be allowed. As an example, try logging in as UUCP. If you have the 'x' protocol, you can pretend to be another uucico process. Now, try transferring files from your root directory. If this works, you have a problem. I found it takes quite a bit of 'playing around' with the control files, before you can get it right. For example, the *only* publicly accessable directory should be /usr/spool/uucppublic. Anything else is bad news (unless you know what you're doing). Unfortunately, when setting this up, it can break things. Thus, logging in as uucp (or nuucp) can help. As a 'quick-n-dirty' rule for L.cmds, if the first letter of the command is not 'r', it doesn't belong in L.cmds. Of course, rsh is a BIG exception here. It should *never* appear in L.cmds. Don't be gratuitous here. If you're not convinced that the program is ABSOLUTELY necessary, keep it out. > > and my /usr/lib/uucp/USERFILE contains > uucp, / > , / > > So, how vulnerable am I? > Jay Libove ARPA: jl42@andrew.cmu.edu or libove@cs.cmu.edu I'd have to go and wade through the UUCP documentation again, but it seems to me that your USERFILE will allow me (or anyone else) to copy *anything* off your system. This is very wrong. Try simulating an attack on yourself, by logging in as 'uucp' (or nuucp). See above. - Der -- dtynan@sultra.UUCP (Dermot Tynan @ Tynan Computers) {mips,pyramid}!sultra!dtynan --- God invented alcohol to keep the Irish from taking over the planet ---
daveb@geaclib.UUCP (David Collier-Brown) (11/16/88)
From article <8623@rpp386.Dallas.TX.US>, by jfh@rpp386.Dallas.TX.US (John F. Haugh II): > 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 In general, any system which will do work for another system, such as forward mail, can act as a mechanism for the owrm to transport itself. If the system will allow any (other) operation, each permitted operation has to be considered case-by-case to see what it can do, and therefor whether it can be used in asecurity breach. Uux, given permission to "pass on this mail", can in principle be misused to pass on (or back) other things. Once upon a time, it was incautious enough to do far too much. --dave (was my SysAdmin **ever** pissed off) c-b -- David Collier-Brown. | yunexus!lethe!dave Interleaf Canada Inc. | 1550 Enterprise Rd. | HE's so smart he's dumb. Mississauga, Ontario | --Joyce C-B
pengo@tmpmbx.UUCP (Hans H. Huebner) (11/16/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: >| [...] >|So, how vulnerable am I? >What did you say that phone number was? This I have to take a crack >at. [And more stuff like this] What do you call this, helpful ? Jay seemed like he'd like to know what he should do to make his system more secure. Simply posting that it is in fact insecure doesn't help anybody. Maybe Mr. Haugh should attend the next course on ethics. Hans -- Hans H. Huebner, netmbx | PSIMail: PSI%026245300043100::PENGO Woerther Str. 36 | DOMAIN: pengo@tmpmbx.UUCP D-1000 Berlin 20, W.Germany | Bang: ..!{pyramid,unido}!tmpmbx!pengo Phone: (+49 30) 882 54 29 | BITNET: huebner@db0tui6
judy@moray.UUCP (Judy Scheltema) (11/17/88)
>> and my /usr/lib/uucp/USERFILE contains >> uucp, / >> , / >> >> So, how vulnerable am I? >> Jay Libove ARPA: jl42@andrew.cmu.edu or libove@cs.cmu.edu >I'd have to go and wade through the UUCP documentation again, but it seems to >me that your USERFILE will allow me (or anyone else) to copy *anything* off >your system. This is very wrong. Try simulating an attack on yourself, by >logging in as 'uucp' (or nuucp). See above. > - Der > dtynan@sultra.UUCP (Dermot Tynan @ Tynan Computers) With that listing in your USERFILE, I can write *anywhere* on your hard disk. Another 3b1 user lost his root password and additionally had garbled his L.sys file. He told me what he had in his L.sys file, and I logged in on my machine as root and made him up another L.sys and then proceeded (with his permission and the other party on voice line as this was occuring) to *overwrite* his garbaged L.sys so he could call and pick up his mail/files or whatever. This is one large security hole, and it comes that way right out of the box from AT&T. Default needs to be uucp, /usr/spool/uucppublic. Then, as the novice users learn what it is all about, if they want to change it to permit access to other areas, at least at this point they should have a bit more knowledge about the implications of the change (theoretically :-)). Judy Newsgroups: news.admin Subject: Re: How safe is UUCP? (Was: Virus in the future?) Summary: Expires: References: <74@dsoft.UUCP> <196@libove.UUCP> <2654@sultra.UUCP> Sender: Reply-To: judy@moray.UUCP (Judy Scheltema) Followup-To: Distribution: Organization: Houston, Tx Bbslist Headquarters Keywords: -- Judy Scheltema | uunet!nuchat!moray!judy Houston, Texas | bellcore!texbell!moray!judy
root@killer.DALLAS.TX.US (Admin) (11/19/88)
> Another 3b1 user lost his root password and additionally had garbled his > L.sys file. He told me what he had in his L.sys file, and I logged in on my > machine as root and made him up another L.sys and then proceeded (with his > permission and the other party on voice line as this was occuring) to > *overwrite* his garbaged L.sys so he could call and pick up his mail/files > or whatever. This is one large security hole, and it comes that way right > out of the box from AT&T. Default needs to be uucp, /usr/spool/uucppublic. ^^^^ Never ! Use nuucp. > The uucp login should NEVER be used for remote access as this is the owner of /usr/lib/uucp with write permissions on the directory AND files therein. And, the allowed commands should, at most, be COMMANDS=rmail:rnews. If uucp is an allowed command, what that machine could be made to do from a remote is rather interesting to say the least. As a guess, you were probably using the uucp login for the above process. Do you think it would not be possible for this to be done from any remote site that could access that machine as uucp ? It would also be possible to request the L.sys (Systems) file, masquerade as his machine to one his "knows" and it would be his machine supposedly doing the damage. The security "hole" is not in the way it "comes out of the box from ATT" but in how the SA sets the thing up - it comes with absolutely no setup, leaving this for the owner to do. Most all *nix systems come "out of the box" with no passwords at all on any id. It is the owners responsibility to place these or suffer the results and not doing so isn't a defect in the way the operating system is delivered. > Judy Scheltema | uunet!nuchat!moray!judy > Houston, Texas | bellcore!texbell!moray!judy Charlie Boykin killer!root killer!sysop
kls@ditka.UUCP (Karl Swartz) (11/20/88)
In article <2654@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) 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 > >Wrong. You should ONLY allow 'rnews' and 'rmail'. What you have is a big >security hole. For example, cunbatch is called by rnews only. Jay's machine happens to receive news from a machine that's still running 2.10 news. Incoming compressed batches from a 2.10 machine cause cunbatch to be run directly -- not rnews -- so in this case it is appropriate that cunbatch be listed in L.cmds. (Or in Permissions on an HDB/BNU system.) -- Karl Swartz |UUCP {ames!hc!rt1,uunet!dasys1}!ditka!kls 1-505/667-7777 (work) |ARPA rt1!ditka!kls@hc.dspo.gov 1-505/672-3113 (home) |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (11/21/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? >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. If you have a USERFILE, L.sys can be stolen from most SCO Xenix systems (i.e. if you are not running HDB). A lot of generic System V systems too! Irregardless of *what* is in USERFILE. Moral: Get HDB if at all possible if you allow anything other than *very* trusted sites to login into your system. -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
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"