Re: LYNX-DEV Alleged Lynx security emergency

[Foteos Macrides]

Jonathan Sergent <address@hidden> wrote:
>[Ignore this post if you already understand why the bug works
> the way it does.]
>
> ] >   In other words a user who was supposed to be "restricted"
> ] >   to lynx only access might trick lynx into running a shell
> ] 
> ] This was not my exact interpretation of the so-called bug so I'd
> ] like some clarification from others on the list.
> ] 
> ] I assumed that the bug if there is one is in the cp program.
> ] All Lynx was doing was letting people exploit the bug in cp,
> ] i.e., when cp crashed, the user was left with a shell (sh).
>
>"Oh, so we should disable cp, then, right?" :-)
>
>No.  cp exited with an error because it was passed invalid arguments.
>The command line included a semicolon so the sh was run after the
>cp was.
>
>To save the file to the spot you tell it to from the file in /tmp,
>lynx uses cp.  In particular, it does "sh -c cp foo bar" since it's
>called with system(), so the arguments to the cp command are subject
>to shell expansion.  If you give it the right kind of bogus filename, 
>it will copy then run a shell, because the shell will see the command as
>"cp foo bar ; /bin/sh" [a bit more complicated I think] which it will 
>most certainly do if you tell it to.   You would conceivably tell it
>to save a normal file as "bar ; /bin/sh" and it would substitute 
>away.
>
>The problem is that lynx -tried- to fix this by putting quotation
>marks around the filename.
>
>cp foo "bar ; /bin/sh" will make a funny-looking file instead of
>causing problems.  So the solution was to use LYNXDOWNLOAD://
>directly to make it do
>cp foo; "/bin/sh"
>
>(i.e. it thinks the temp file is called "foo;" and you want to save 
>it to /bin/sh.)

        No.  The vanilla code assumes that the value of File= will
be that of its temporary file, and doesn't do anything with it.  It
cleans up the value of SugFile= as accepted or modified by the user
at the prompt for an output filename.  Wayne's posted patch quotes
the value of File= (the entire value, not what you describe) but the
fotemods and recent development code change was to reject any value
not included by the function for generating the 'd'ownload menu.
The fotemods also have code for avoiding a buffer overrun which is
more clear within the LYDownload.c module, but that won't happen
now that the value must be that from the code for generating the
'd'ownload menu.  The LYMainLoop.c for fotemods also blocks the
LYNXDOWNLOAD scheme from 'g'oto commands, and won't act on any
LYNXDOWNLOAD URL from a file unless it's the temporary file for
the 'd'ownload menu, but those things are just "extra insurance".


>This isn't DOS, so "cp foo" doesn't do anything other than exit
>with an error, and the /bin/sh gets happily parsed by the shell.
>
>Turning foo; into "foo;" wouldn't help as the user could just
>specify ";" in which case cp ; /bin/sh would work.
>
>In other words, cp is totally irrelevant, sh is being fooled.
>Lynx uses sh to run cp is all.
>
>If you read the system() manpage, you'll see this warning:
>BUGS
>       Do not use system() from a program with suid or sgid priv-
>       ileges,  because strange values for some environment vari-
>       ables might be used to subvert system integrity.  Use  the
>       exec(2)  family of functions instead, but not execlp(2) or
>       execvp(2).
>
>Lynx is obviously not setuid or setgid anything, but the account
>it's running as may need to be protected too if it's running
>in a public situation.
>
>Getting rid of system() is problematic as some people have their
>own downloader / printer definitions which rely on shell control
>structures to get the work done (see the default config file).
>
>[Please, please correct me if I tripped up anywhere up there.]

        There seems to be more to it than what you and Wayne are claiming
about it being equivalent to a script entered on the command line.  For
example, the LYK_SHELL command on Unix uses  system("exec $SHELL");  and
that works cleanly.  The posted spoofing LYNXDOWNLOAD URL ends up with
 system("/bin/cp /dev/null;/bin/sh; /dev/null");  and it causes /dev/null
to be replaced with a real, empty file (no longer symbolic) even though
the account running Lynx doesn't have privileges to do that.  Also, the
invoked shell has strange terminal characteristics, which you can almost
but not quite clean up with ^Jstty sane^J^J.  When I tried a spoofing URL
which yields  system("/bin/cp foo bar;exec $SHELL; bar");  where foo
exists so there is no cp error, it still gave me a shell with strange
terminal characteristics.

        You're also confusing the File= value with the command for the
download option based on the Method= value.  In the case of -1, its
COPY_PATH, defined in userdefs.h as /bin/cp (for the vanilla and
fotemods code).  In the case of 0 to n, its the command or script
defined for DOWNLOADER: in lynx.cfg.  The File= and "cleaned-up"
SugFile= values follow those, to act as arguments for the command.

>IMHO it would be a good move to prepare a lynx2-7-1+security_patch
>distribution and announce it through the standard channels, noting
>that it affects security on installations in restricted accounts.  
>This might get some of them to upgrade, too, many of the freenets 
>are using old versions. (they obviously need to, unless they want
>to give all of their users shell access)
>
>Did someone say they had a patch to fix this against the base 2-7-1
>distribution?  Whoever that is should apply it and get it put up on
>sol with the appropriate notice (including one not to panic if you
>don't have restricted accounts running lynx).  I see no problem in
>announcing it to people who get CERT announcements (i.e. a vendor
>bulletin, if anyone is brave enough to call themselves a vendor) as 
>it is certainly quite problematic for people running lynx in restricted 
>or public account situations.

        I don't have a strong opinion on how to handle that.  If the
chartrans stuff I added to fotemods is OK, its been several months
since the v2.7-1 release, and Tom D. is going to be working all the
remaining fotemods into the development code, so the fotemods could
be released as a v2.7-2 or v2.8.  Remember there's also the problem
of spoofing with symbolic links for the vanilla v2.7-1 and earlier
releases.  The chartrans mods were massive, though, so it's likely
there still are some glitches.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;