Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/15/88)
SUN-SPOTS DIGEST Friday, 12 August 1988 Volume 6 : Issue 179
Today's Topics:
Re: Security hole in "lockscreen"
Re: Another security hole in "lockscreen" (2)
Re: ethernet error messages: what do they mean
Re: Problems with forwarding mail
Re: Problems with SCSI drives in 3/160
Re: Finding out what files your programs are opening
Re: Networked Pricing Strategy
Re: mail question: Sun mail aliases
Send contributions to: sun-spots@rice.edu
Send subscription add/delete requests to: sun-spots-request@rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server@rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Fri, 5 Aug 88 14:54:57 MDT
From: Joe Wells <joew%chisholm.USWest.COM@boulder.colorado.edu>
Subject: Re: Security hole in "lockscreen"
In article <1988.07.11.21.19.15.718.20579@rice.edu> Sun-Spots@rice.edu writes:
>From: Ian Phillipps <mcvax!camcon!igp@uunet.uu.net>
>...
>If the control sequence for open window, "^[[1t", is sent to a shelltool
>or cmdtool window which is behind a lockscreen, it pops to the front and
>can then be used normally. All that is required to do this is login or
>rlogin access under any user id.
>
>The cure, if you want to take lockscreen seriously, is to set "mesg n" on
>each and every window.
>
>[[ ... which you cannot do because you don't own the pseudo ttys---root
>does. --wnl ]]
There is an easy trick to gain ownership of the ptys that you are using on
your own workstation. Just run a shelltool on that pty, and once you are
in the shell, run the program /bin/login. When it is done logging in,
just log out. The psuedo tty will now be owned by you. Ownership only
reverts to root when the login is from another system.
The security hole that Ian mentions is one of the smaller holes in
lockscreen. I believe it is a result of the fact that the lockscreen
program cannot detect a window appearing in front of it without polling
the window link database. It does not receive a SIGWINCH signal, since no
new areas of its window are exposed. The window's clipping list is
changed, but the lockscreen program is not notified of this unless it
explicitly asks. Of course, there is no excuse for not doing so, except
for a lack of security consciousness on the part of Sun. Interestingly,
this method does not work while lockscreen is in the mode where it has
blanked the screen and is asking for the password. I would presume that
at that point, the lockscreen program has taken the input/output lock.
Closing this particular hole may not buy you much. I have found another
way to defeat lockscreen. It is possible to forcibly exit another person
from suntools back to their login shell using just the open, close, and
ioctl system calls. The two ioctl calls involved do not check for any
kind of authorization at all. One of the calls will send a SIGTERM signal
to every process that owns a window, and if they do not die, it will send
a SIGKILL signal. It does not matter if the process that invokes the
ioctl call is owned by a different user. (The other call is used to
restore the console input to the login shell, so it does not die.)
The only completely effective way to make lockscreen secure is not to run
the rex and rlogin daemons on individual workstations. Of course, this
means if something locks up the workstation, it must be rebooted. It also
makes it very difficult for the system administrator to edit the
configuration files on individual workstations, but not impossible.
Another less effective solution is not to include this line in
/etc/passwd:
+::0:0:::
This, of course, would result in an administrative nightmare.
The correct way for Sun to solve these security problems would to do
something like what /bin/login does with ttys. When the user allocates a
window device, or a psuedo tty, there should be a way to acquire ownership
of the device, until it is deallocated (closed). Having public *read*
access to your psuedo ttys is simply *not* wise.
--
Joe Wells -- one of these addresses might reach me:
joew@chisholm.uswest.com (officially)
joew%uswest@boulder.colorado.edu joew@uswat.uswest.com
------------------------------
Date: Fri, 05 Aug 88 10:30:11 -0400
From: Chris Walters <walters%community-chest.mitre.org@gateway.mitre.org>
Subject: Re: Another security hole in "lockscreen" (1)
Reference: v6n151
In Sun-Spots Digest, v6n151, brittain@aiu1.ic.ornl.gov (Carlton Ray
Brittain) writes:
>lockscreen -e
>...
You are correct, it does not work as advertised. There are at least two
ways to get around the problem; both are pretty kludgy.
Method 1:
A shell script front end to suntools like (these examples assume that
you are a C-shell fan.) These scripts _have_ to be exec'd for this to work.
csh script sh script
---------- ---------
#!/bin/csh -f #!/bin/sh
onintr - trap "" 1 2 3 15 18
suntools $argv suntools $*
if ($status == 143) then if [ $? -eq 143 ]; then
source ~/.logout exec /bin/csh -f $HOME/.logout
exit exit # should never get here
endif fi
exec /bin/csh -i exec /bin/csh -i
Under 3.4, Suntools will return a status of 143 to the shell after exiting
from 'lockscreen -e'. Under 4.0, this is 137 instead of 143. This is all
undocumented and probably unsupported. It would be much better if
'lockscreen -e' worked properly!
Method 2:
Use 'exec suntools' instead of 'suntools'. This has the possibly
undesirable effect of logging YOU out after suntools is finished, in
addition to other users who might happen along to your lockscreen,
irregardless of how you exit suntools.
-- Dave Ball
-- Chris Walters
ball%community-chest@gateway.mitre.org Q: Whaddya call SunOS bugs
walters%community-chest@gateway.mitre.org on a Sun 4?
Standard Disclaimer Applies A: SPARC plugs
[[ This was added a little later: --wnl ]]
In order for your '.logout' to be executed upon logout from the shell that
is exec'd from the scripts listed in our previous posting, you will need
an alias that will source ~/.logout and then exit.
As we said before, very kludgy.
- Dave Ball (ball%community-chest@gateway.mitre.org)
- Chris Walters (walters%community-chest@gateway.mitre.org)
------------------------------
Date: Mon, 8 Aug 88 11:58:00 +0200
From: mcvax!lasso!ralph@uunet.uu.net
Subject: Re: Another security hole in "lockscreen" (2)
Maybe the man pages of lockscreen are somewhat misleading, but I see "no"
security hole, at least not bigger than leaving one's files world
readable/ writable!
If lockscreen is called from a suntools menu, then the suntools desktop will
be exited, as advertised.
If it is manually called from a shelltool window, then "that" window will
be exited, leaving you in suntools.
As wnl cited, if you exec suntools, since there's no higher up shell, you
will exit Un*x. A question for the wizards, how do I still get my .logout
executed?
[[ Can't do it by merely "exec-ing" suntools, because the cshell needs to
stick around. You could have a shell file that does "suntools;
source ~/.logout; logout". But one of the advantages of "exec suntools"
is that the memory used for the login cshell is freed up. --wnl ]]
Ralph P. Sobek | UUCP: uunet!mcvax!inria!lasso!ralph, or
| ralph@lasso.uucp
LAAS-CNRS | Internet: ralph@lasso.laas.fr, or
7, avenue du Colonel-Roche | ralph%lasso.laas.fr@uunet.UU.NET
F-31077 Toulouse Cedex, FRANCE | ARPA: sobek@eclair.Berkeley.EDU (forwarded\
+(33) 61-33-62-66 | BITNET/EARN: SOBEK@FRMOP11 \ to UUCP )
------------------------------
Date: Fri, 5 Aug 88 20:56:47 PDT
From: kwz%janus.Berkeley.EDU@berkeley.edu (Kevin Zimmerman)
Subject: Re: ethernet error messages: what do they mean
Reference: v6n168
"ie0: no carrier" indicates that the Sun is not seeing anything that it
thinks is a packet during the timeout period. This would happen if there
is no connection to the transceiver's receiver for some reason, which in
addition to the obvious causes might include a blown up chip or fuse on
the ethernet interface (look for a tiny cylindrical picofuse near the
ethernet connector; it turns dark when it pops - not all units have these,
though)
"ie0: ethernet jammed" is the result of the transceiver signaling a
collision for more that the (brief) normal amount of time. A TREMEMDOUS
series of collisions can do this on a busy net, as can a bad or loose
ethernet coax connector or terminator, or some transceiver somewhere stuck
sending a jam (in turn caused by a bad transceiver, cable or controller.
Don't forget the cables inside the machine, those of you with Multibus
units :-).
In my experience some 3/50s seem to spit out "le0: no carrier" messages
when they are generating a lot of packet traffic if they are hooked up to
a transceiver without heartbeat (even if they have the ethernet level
jumper on the CPU card set correctly). Putting them on a transceiver with
beat (almost always a level 2: J0642 should be OUT) usually cures it.
If you pull the board to check the jumper, it would be wise to use
anti-static precautions such as at least those described in the
installation manual ethernet section.
Kevin Zimmerman
"the errors contained in this message are my own"
------------------------------
Date: Sat, 6 Aug 88 12:52:51 CDT
From: Steve Alexander <laidbak!stevea@sun.com>
Subject: Re: Problems with forwarding mail
Sendmail runs SUID root. Root access over NFS is mapped to nobody. So,
if the directory is protected, no NFS clients can read the .forward file.
Use a central alias database, or forward all mail to one machine and
export /usr/spool/mail from there.
Steve Alexander, TCP/IP Development | stevea%laidbak@sun.com
Lachman Associates, Inc. | ...!{ihnp4,sun}!laidbak!stevea
------------------------------
Date: Sun, 07 Aug 88 09:38:48 GMT
From: "Timothy H Panton." <mcvax!westhawk!thp@uunet.uu.net>
Subject: Re: Problems with SCSI drives in 3/160
I have a Maxtor (a 3170 - 140 Mb) with an embedded scsi on my 3/50 so I'd
guess the scsi on your drive is compatible with Sun's.
Maxtor's have a good selftest facility, they beep once they are up to
speed and otherwise happy (found track zero, power ok etc). Try powering
your drive up without the Sun and wait a few seconds. If you dont get a
beep suspect the drive.
>From there on it's just cables and jumpers, I think my drive arrived
jumpered to scsi device 7, Sun expects sd0 on 0 and sd1 on 1 (as I recall)
so you will have to change that.
You will need to use /stand/diag to label the drive and fill in the head
sector and track info. I used the Emulex (EDSI) selection and diag found
the manufacture's bad block list, which saves lots of typing.
I have also replied directly to (droms@BKNLVMS.BITNET) but I'm not sure my
mailer can cope with BITNET.
Tim Panton.
..!mcvax!ukc!cam-cl!westhawk!thp
------------------------------
Date: Sat, 06 Aug 88 02:25:29 PDT
From: cs%kanawha@sun.com
Subject: Re: Finding out what files your programs are opening
> 5) This patch is running on SunOS3.5. Under 4.X if I understand it correctly,
> the right thing to do would be to change the open function in the C
> shared runtime library instead of patching the kernel.
No. Under 4.0, the right thing to do is use trace(1). For example,
compile the following program, foo.c (use -Bstatic if you don't want to
see the dynamic linking trace)
main()
{
int fd;
fd = open("foo", 0);
exit(0);
}
and use ``trace ./foo'' to get
open ("foo", 0, 010000) = 3
close (0) = 0
close (1) = 0
close (2) = 0
exit (0) = ?
Carl
------------------------------
Date: Sat, 6 Aug 88 10:10:54 EDT
From: scs%lokkur.UUCP@umix.cc.umich.edu (Steve Simmons)
Subject: Re: Networked Pricing Strategy
Neil Hunt of SPAR and various other folks talk about pricing strategies
for software in networked or distributed environments. At Schlumberger
Technologies/CAD-CAM Division, we developed a security service that
provided a reasonable alternative [note 1 -- ST will *not* sell the
server. note 2 -- I did the initial design/development and worked on
later design, and therefore must be very circumspect about what I say.
Please don't write me for details! My purpose in writing this is to say
there is a better way, not to tell you how to implement it.].
The server kept track of product usage across a network. Products were
sold on a "by-seat" basis, with one seat being unlimited usage on a single
workstation or terminal by the same login session [ie, if you had the
product running in six suntool windows, that was one seat. If you had a
terminal on the tty port and tried to use it there as well, that's another
seat.]
Aside from that, there were no restrictions on usage. Any host that could
access the product and the security server could run any product. If the
server noted all seats in use, the product wouldn't run.
This solves most of the problems with pricing as well. You go right along
as you always have, 1-10 copies are $X each, 11-100 are $Y, and so forth.
When the customer finds he needs more simultaneous usage, he calls his
salesman and buys more seats. We send him new keys for the security
service, and off he goes. So no fancy accounting, easy flexible use,
simple comprehensible pricing (salespeople need that, you know?) and the
whole world is relatively happy.
Except of course for the sales folks who tried to give away "temporary"
copies, or customers to tried to steal the software for their other sites,
or all those other bad things wherein people take your software but don't
pay you!
------------------------------
Date: Sat, 6 Aug 88 00:08:54 PDT
From: Mark D. Baushke <mdb@silvlis.com>
Subject: Re: mail question: Sun mail aliases
Robert Wenig <acad!robert@uunet.uu.net> writes:
> I notice that when I get a mail reply from somebody inside of sun, very
> often the return path is sun!personame, and all of the internal machine
> name business is stripped out. I would like to know how to set this up on
> my own machine.
This is a feature of 4.0 sendmail. You get this version of sendmail with
SunOS 4.0. It is also the version of sendmail distributed with the
"nameserver kit".
To make it work, you will need to generate a map containing the inverse of
mail.aliases (called mail.byaddr in SunOS 4.0). Unfortunately, the
program ``mkalias'' which is only available on SunOS 4.0.
So, assuming you can get a mail.byaddr generated (maybe by having a
machine on the network which happens to be running SunOS 4.0 create it for
you), you can make this behavior work on a mail machine running on either
a SunOS 3.x or a SunOS 4.0 system.
The way to use the mail.byaddr is demonstrated in this fragment of
sendmail.main.cf file.
Muucp, P=/usr/bin/uux, F=msDFMhuU, S=13, R=23,
A=uux - -r $h!rmail ($u)
# map containing the inverse of mail.aliases
DZmail.byaddr
# Convert uucp sender (From) field
S13
R$-<@$-> $:$>3${Z$1@$2$} invert alias map
R$+<@$-.uucp> $:$>3${Z$2!$1$} invert alias map
R$+ $:$>5$1 convert to old style
R$=w!$+ $2 strip local name
R$+ $:$w!$1 stick on real host name
# Convert uucp recipient (To, Cc) fields
S23
R$-<@$-> $:$>3${Z$1@$2$} invert alias map
R$*<@$%y> $2!$1<@$w.uucp> tack on extra $w!
R$+ $:$>5$1 convert to old style
After 4.0 sendmail is in place and the appropriate sendmail.main.cf is
written, all that is left is to put lines like this
mdb: mdb@amadeus
into your ``aliases'' file which is also used to generate the mail.byaddr
file. The end result is that whenever the right-hand-side string of an
alias ("mdb@amadeus") shows up on your mailhost in a From: line it will be
replaced with the left-hand-size ("mdb") which will yield the final result
of machine!personname ("silvlis!mdb") instead of
machine!homemachine!personname ("silvlis!amadeus!mdb").
Enjoy!
Mark D. Baushke Internet: mdb%silvlis.com@sun.com
Silvar-Lisco, Inc. Nameservers: mdb@silvlis.com
1080 Marsh Road Usenet: {pyramid,sun}!silvlis!mdb
Menlo Park, CA 94025-1053 Telephone: +1 415 853-6411 / +1 415 969-8328
------------------------------
End of SUN-Spots Digest
***********************