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

[Foteos Macrides]

Rob McMillan, "CERT(R) Coordination Center" <address@hidden> wrote:
>Hi Fote,
>[...]
>> I have made patches which plug the vulnerability available in:
>> 
>>      http://www.slcc.edu/lynx/fote/patches/
>> 
>> Once the lynx-dev group has a chance to check them out, one of
>> the active developers should contact you about an offical patch
>> for the current formally released version of Lynx, which is
>> v2.7.1, and access to it should be made available via links
>> in the http://lynx.browser.org/ home page.
>
>
>Great, many thanks for getting back in touch with us.  We're glad to see
>that the folks on this list are working on developing patches.
>
>A victim site got back to us with the following information:
>
>> With a little experimentation the bug,
>> goto:  LYNXDOWNLOAD://Method=-1/File=;/bin/sh;/SugFile=/dev/stdin,
>> still was able to produce a root shell when lynx was started as
>> 
>> lynx -anonymous -cfg /usr/local/lib/lynx.cfg \
>>  -restrictions=dired_support,disk_save,download,editor,mail,exec,shell,
>> 
>> but the command
>> 
>> lynx -anonymous -cfg /usr/local/lib/lynx.cfg -restrictions=all
>> 
>> seems to prevent the expliotation.
>
>> BTY,  The bug gave root access despite having the permissions on a program
>> that launches lynx setuid to a different user.
>
>This message has two points of interest.  With regard to the use of the
>"-restrictions" flag, we notice that in the instance that did not work, the
>site had restricted downloads.  Yet by restricting all services, they were
>able to workaround this problem.  The man page seems to indicate that the
>first instance should have worked.  Is this a bug, or are we
>misunderstanding something?

        Setting the restrictions to "all" causes the 'g'oto command
to be blocked, and thus the ability to keyboard in any spoofing URLs,
but a clever villain might come up with a way to put the LYNXDOWLOAD
URL in a file that could be accessed from the anonymous account (e.g.,
via a search service, accessed from the online 'h'elp).  So you still
need the patches to block such URLs unless they are ones Lynx generated,
or are identical to those.  The current patches also block activation
of LYNXDOWNLOAD URLs unless one is in the Lynx download options menu.

        The download restriction simply blocks the inclusion of the
configured (lynx.cfg) options in the download menu, so that the same
image and lynx.cfg can be used for shell versus restricted accounts,
but invoked with different restrictions.  It does not block
LYNXDOWNLOAD URLs, per se.


>The second point of concern is the footnote regarding the gaining of root
>access even though lynx was launched setuid to a different user.  We aren't
>sure how the service is launched at the site, but given other comments, we
>thought you'd be interested to see the experiences of some other folks.

        How bad it is seems to be Unix flavor dependent, but in general
cp appears to be the culprit, with poor error recovery.


>Finally, once patches have been developed, you may want to consider
>announcing them via a bulletin that we can "wrap" as a CERT
>vendor-initiated bulletin. These bulletins are distributed the same way as
>CERT advisories--we send them to the CERT mailing list (currently thousands
>addresses, some of which are mail exploders) and post them to the
>comp.security.announce newsgroup as our schedule allows.
>
>If you are interested in writing a bulletin, these are the
>key points to include:
>
>  a. brief description of the problem.
>  b. the impact of the vulnerability -- what can happen if people
>     don't fix the problem
>  c. how to fix the problem (patches, MD5 checksums, workarounds).
>  d. how to get in touch you, if there are questions.
>
>We've included a sample template at the end of this message in case you'd
>like to use it; but you can use any format you like.
>
>If you'd like to see examples of bulletins others have written, see
>   ftp://info.cert.org/pub/cert_bulletins/
>
>Let us know if you want to do this.  (If you don't want to do a bulletin,
>let us know that, too.)

        I've retired from coordinating Lynx development, but the current
active developers I presume will address the issue.  I'm CCing this to
address@hidden, and appending your guidelines on writing a bulletin.
Though you CCed to lynx-dev yourself, due to some spam that was sent to
it, it ceased to be an open list, and your message didn't get through
to the current active developers.  I've expressed in no uncertain terms
my opinion that closing the list was a terrible idea, but I'm not the
coordinator any more, so...


>One more thing we wanted to check with you on...
>
>We had a look at the LYDownload.c file at
>
>       http://www.slcc.edu/lynx/fote/patches/lynx2-7-1/src/LYDownload.c
>
>We noticed one line in there:
>
>       retry:  
>               if (sug_file)
>                   strcpy(buffer, sug_file);
>               else
>                   *buffer = '\0';
>
>Where buffer is a 256 byte buffer, and sug_file is a pointer into the
>LYNXDOWNLOAD argument.  We haven't had a look at all the code, and so we
>aren't sure whether the buffer that sug_file points into is bounded to 256
>bytes or less.  Given that we don't know (since we don't know the code and
>haven't looked deeply), do you know whether there is there potential for a
>buffer overflow here?
>
>As always, any feedback would be appreciated.

        There was in the original code.   I further modified my patches
to include more explicit protections, since the limitations on size
aren't obvious in the LYDownload.c code, and might be changed
inadvertantly during future development.  There was also a hole in
that the SugFile value might be set via a Content-Disposition header,
which is not likely to be large if the HTTP specs are followed, but
a villian might have a server available for an attack.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

- ---------------------------------- Cut Here ----------------------------------

For our introduction, please include


Topic:  Short name for the problem
Source: Full company name 
- --------------------------------

<<INCLUDE WHATEVER HEADERS YOU NORMALLY PUT ON YOUR ANNOUNCEMENTS OR
ADVISORIES>>


Problem: Vulnerability in <<name and versions of product>>

I. Description

<<Put words here to describe the problem in a way that is appropriate for
public distribution. System administrators need enough
information to understand what the problem is, but too much detail will enable
intruders to exploit the vulnerability. Include names and version numbers of
products that are vulnerable and, if possible indicate what is NOT vulnerable
as well.>>

II. Impact

<<State what intruders are able to do by exploiting the vulnerability.
Indicate whether they need access to an account on the system or whether the
vulnerability can be exploited remotely.>>

III. Solution

<<Tell people what patches or upgrades are available, if any, and where to get
them.  We strongly urge you to include checksums. If there is a workaround,
explain that.>>

<<Tell readers how to reach you if they have questions or need further
information.>>

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