gwyn@brl-smoke.UUCP (09/13/87)
In article <1178@mtune.ATT.COM> jhc@mtune.UUCP (Jonathan Clark) writes: >In article <15136@hi.UUCP> josh@hi.UUCP (Josh Siegel) writes: >: it watches TCP/IP connections on the ethernet. >You mean that Sun doesn't offer end-to-end encryption? It's not the Sun that has the problem, but the protocols used on the net (which may have other machine types attached to it). It does not seem to generally realized that Internet protocols are subject to spoofing as well as snooping; Bob Morris provides some interesting information in Bell Labs CSTR #117.
ron@topaz.rutgers.edu (Ron Natalie) (09/14/87)
It's not the protocols (TCP/IP) but the class of hardware protocols that allow data from one machine to another to be accessible to a third. This happens in both CSMA and token ring networks. Devious systems can always peek at the data going by. If one host on the net (the destination) can decode it, so can another, short of encryption. The key distribution and access methodology research is still in progress. -Ron
daveb@geac.UUCP (Brown) (09/20/87)
In article <1903@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: ># 3) eye - ># This is the gem of the bunch. Written for a Sun ># computer, it watches TCP/IP connections on the ># ethernet. This lets you see exactly what a user ># is doing... both input and output. ># ... ># current version of eye is nothing but a machine cracker. I don't ># see a reason to pass this around. ># In a few weeks, I plan on posting a new version of eye that is a ># ethernet debugger. I never plan on posting my cracking version. > >Are you sure that your code will be written so that it takes a true guru to >readily modify it to add the "cracking" functions? If not you might want to >think twice about sending it out, or post a uuencoded binary instead. This really raises a question which should be debated in the security newsgroup... since there isn't one, lets restrict it to sources wanted initially. The question is: if XXX is insecure, should I publish information on breaking XXX. My personal opinion is "Only after you publish information on how to make XXX secure". Eg, the clist-watcher can be defeated by setting the perms on /dev/kmem to exclude all but user and group "root", then writing required applications using /dev/kmem as setgid root. Other opinions, please? (light, not heat, requested). --dave -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.