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

[Robert Bonomi]

+ Date: Tue, 24 Jun 1997 13:19:33 -0700
+ From: Jason Baker <address@hidden>
+ To: address@hidden
+ Subject: Re: LYNX-DEV VU#5135 (Lynx vulnerability?) (fwd)
+ References: <address@hidden>
+ 
+ --+HP7ph2BbKc20aGI
+ Content-Type: text/plain; charset=us-ascii
+ 
+ Robert Bonomi wrote:
+ > 
+ > 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.
+ 
+ Fair enough, but a bit dangerous, too - DG/UX only just now has FINALLY
+ got shadow passwords, as of 5.4R4.11MU03 (MU = maintenance update, kinda
+ like a patchlevel).
+ 
+ I know for a fact there's tons of systems out there running 5.4R3.10.
+ Since Lynx shouldn't be able to do this, it's a bit unfair to blame the
+ OS for the lack of a feature to counteract what Lynx is letting the
+ users get away with. :)

I'll submit that:
 1) /etc/password *is* "world-readable", by O/S design.  It is a given that
        any app *should* be able to read world-readable files.  The fact that
        LYNX can do so is not surprising.
 2) If there is 'sensitive' information in such a file, it is -not- the 
        responsibility of _each_and_every_application_ to prevent access to
        the 'sensitive' part of that data.
 3) the -proper- place for implementing 'access controls' *IS* _inside_
        the O/S.
 4) Given that LYNX _does_not_allow_ access to files that are =otherwise=
        =unavailable= to the 'unprivilidged' userid that it is executing under,
        the matter should *not* be considered a LYNX 'problem'.
 5) There is no more access provided than via a shell account, or non-
        anonymous FTP.  either of those methods can also access /etc/password.
        OR _any_ other 'world readable' file.
 5) Finally, *if* someone runs LYNX as a 'root' process, I'd suggest that
        they richly *deserve* what they get.

+ Of course, I tend to consider any system with a guest account a system
+ with a big "start hacking here" sign, but sometimes it's needed.

The 'vulnerability', in the case of a _local_ user, is *zero*, It provides
them with *nothing* beyond what they could -already- do from a shell prompt.

In the case of a 'remote' user -- where lynx is being used a a public-
access 'limited function' shell -- is that said user might gain access
to an 'unpriviledged' shell prompt.  postulating a "correct" implementation,
i.e., where this is running in a "chroot-ed" 'jail', the risk here is 
essentially zero, as well.


Now, all that said....  the ability to get a shell, or cause lynx to pass 
arbitrary _user-supplied_input_ to the system() command *is* a 'bad thing',
and should be plugged.  Refusing to process any strings containing any 
shell 'special' characters could be a good stat.
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;