Re: LYNX-DEV VU#5135 (Lynx vulnerability?) (fwd)

[Robert Bonomi]

+ From address@hidden  Tue Jun 24 13:05:33 1997
+ Received: (from address@hidden) by delta.ece.nwu.edu (8.8.5/8.8.3) id 
NAA25695 for <address@hidden>; Tue, 24 Jun 1997 13:05:33 -0500 (CDT)
+ Received: from quartz.sig.net(199.1.78.227) by delta.ece.nwu.edu via smap 
(V2.0beta)
+       id xma025686; Tue, 24 Jun 97 13:05:26 -0500
+ Received: (from address@hidden) by quartz.netop.sig.net (8.8.5/8.7.3) id 
MAA16557 for lynx-dev-031896; Tue, 24 Jun 1997 12:41:03 -0500 (CDT)
+ Date: Tue, 24 Jun 1997 11:48:48 -0600
+ From: address@hidden (Scott McGee (Personal))
+ Message-Id: <address@hidden>
+ To: address@hidden
+ Subject: Re: LYNX-DEV VU#5135 (Lynx vulnerability?) (fwd)
+ Sender: address@hidden
+ Precedence: bulk
+ Reply-To: address@hidden
+ Status: R
+ 
+ Larry mentioned getting an error when trying the CERT URL's on his system.
+ On my system I tried both. The first one started a /bin/sh that would not 
+ respond to most keys. I assume from an earlier post that there is a way to
+ get it to so respond, and hence gain access on the machine. 

The situation here is that the terminal port is still 'configured' in 'raw
mode'.  simply typing CTL-J then 'stty sane', and another CTL-J (*no* <enter>
key anywhere), tends to give one back the 'expected' keyboard behavior.
I get a 'complaint' from 'cp' just before the shell prompt, and a complaint
about an error executing /dev/null when I exit the shell. 

This is with a relatively recent version of the 2.7.1 _development_ code,
using 'slang' and running on SunOS 4.1.4.

+                                                             The second URL
+ gave an error the first time I tried it, but the second time, I changed the
+ prompted filename from /etc/passwd to just passwd and lynx happily created
+ a copy of the password file for me. Not Good!

Being able to read/copy files is =not= really an issue.  Postulating any
sort of effective _system_ management, LYNX is either running _as_the_user_
who invoked it; or in the case where it's being used as a 'public access' 
browser/viewer it is running as _it's_own_ userid.  In _either_ case, the
*system* access-controls are still in effect, and unless LYNX is running 
with an effective userid of _root_, cannot access any 'sensitive' files.
Note: '/etc/passwd' is *not* a 'sensitive' file, on a properly managed 
system.  Everybody *should* be running 'shadow passwords' at this point,
whereupon the readability of /etc/passwd is not a "significant" issue.

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;