Re: LYNX-DEV Alleged Lynx security emergency

[Jonathan Sergent]

[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.)

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.]

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.


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