bobr@zeus.UUCP (Robert Reed) (11/07/86)
In <157@houligan.UUCP> Dave Cornutt writes:
Any system, no matter how secure it is designed to be, is only as secure
as the people who run it make it. If the searchpath problem was fixed,
Darryl still have gotten in by creating a Trojan-horse program in his
directory and convincing the superuser to run it. (An old student
approach: "I'm getting a wierd error out of this homework program; could
you please run it and tell me what you think is wrong?"). This would
have worked just as well, and there is *no system on the market* that
can stop this type of attack...because the thing being taken advantage
of isn't the system, it's the system administrator.
Maybe yes, maybe no. It is certainly true in either case that the sys-admin
was duped, but in Darryl's trojan horse scheme, he was relying on the
coincidence of two conditions:
1. That the search path tried the current working directory first.
2. That the system administrator would think nothing of using standard
utilities while running as root in that directory.
It is one thing to build a trojan horse behind, say, ls; one that does its
dirty deed and then execs the real ls. It's quite another to convince an
administrator to run a user program WHILE IN A PRIVILEDGED ACCOUNT. It's
certainly possible to do it, especially with a novice admin, just as it is
possible to take advantage of one who leaves terminals logged into root. I
know I would have real qualms about executing someone's xyz program while
running as root. But I might not even think about running ls, cat, more, or
emacs.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEKjsdy@hadron.UUCP (Joseph S. D. Yao) (11/12/86)
Darryl,
I quite agree with you. Any company that claims to have solved
security measures with hardware and software is either being
ignorant, or themselves immoral and fraudulent. (And if they
gave you a card with their netaddr, please forward that comment!)
Any security system must include people training as well as
whatever software and hardware. Besides, their system (as you
described it) did have holes, which you "legitimately" exploited.
The only secure system is one sealed in the center of the earth ...
or the sun.
One Who Knows.
--
Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
jsdy@hadron.COM (not yet domainised)jsdy@hadron.UUCP (Joseph S. D. Yao) (11/24/86)
In article <836@zeus.UUCP> bobr@zeus.UUCP (Robert Reed) writes: >In <157@houligan.UUCP> Dave Cornutt writes: > Any system, no matter how secure it is designed to be, is only as secure > as the people who run it make it. If the searchpath problem was fixed, > Darryl still have gotten in by creating a Trojan-horse program in his > directory and convincing the superuser to run it. ... >... coincidence of two conditions: > 1. That the search path tried the current working directory first. > 2. That the system administrator would think nothing of using standard > utilities while running as root in that directory. >It is one thing to build a trojan horse behind, say, ls; ... [another] >administrator to run a user program WHILE IN A PRIVILEDGED ACCOUNT... >know I would have real qualms about executing someone's xyz program while >running as root. But I might not even think about running ls, cat, more, or >emacs. I think that the point is, yes, those two are the specific hinge for the technique used here; but it's not the only way the system could have been broken. As said above and elsewhere, PEOPLE are what make or break a security system. All the hardware and soft- ware in the world can't make a system secure. E.g., I won't tell you where, but there's a perfectly good locked door I know of ... with the key hanging on the lintel, so that people can get in and out easily. And: anybody remember how the kid in Wargames got the school secretary's password? PEOPLE, folks, are THE most important part of ANY computer system! -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} jsdy@hadron.COM (not yet domainised)