http://invisible-island.net/lynx/
Copyright © 2001-2013,2014 by Thomas E. Dickey
lynx is designed to be run either as a
single-user application, or as a server, e.g., as a web portal
accessed via telnet.
To allow it to be used as a server, it has configurable
restrictions on the types of operations which can be performed by
a user. In theory, lynx is secure.
In practice, lynx suffers from its age: it was
implemented largely in the mid 90's, by programmers who were not
acquainted with modular/portable design. Repairing this is an
interesting problem in maintainability (interesting to me at any
rate). Since lynx does build and run on a wide
variety of platforms, it cannot simply use two of the panaceas
advocated by people who are familiar with the jargon of secure
programming: mkstemp and snprintf:
mkstemp) is a BSD extension which
is not for example present on Solaris. In some configurations,
it is known to be insecure. The problem it solves (securely
creating temporary files) is addressed a different way in
lynx, i.e., creating temporary files within a
secured directory.snprintf) falls into a similar
category: it is used to avoid buffer overflows arising from
printf-like formatting. Lynx has its own
snprintf-like code (actually two flavors: one
appends to a buffer, which is not addressed by
snprintf or the related asprintf). Like
mkstemp, some implementations of
snprintf and asprintf are known to be corrupt, so
we do not use them.Not all buffer manipulations fall readily into these categories; we review use of fixed-size buffers to ensure that they are being handled properly.
One problem with work in this area is that few people know much, but there is a lot of second-hand information. Second-hand information is frequently inaccurate.
Many of the posters of exploits to BugTraq, for instance, are
more concerned with being first to post than with the accuracy of
their postings. Much of the traffic relating to
lynx, in particular is ultimately due to a system
administrator (in this case, read "computer operator") who
apparently favors FreeBSD over Linux, and has made numerous (a
few are accurate) disparaging remarks relating to security on
Linux. We have addressed the items that are based on facts, but
it appears that the main reason there are no current reports is
that this loose cannon has evolved into a "security
consultant".
When preparing for lynx 2.8.3 (April 2000), I
noted (after inspecting the related source code) that
lynx's competitors (w3m and
links) suffered from the same sort of issues. See
for example
w3m. For some reason, links appears to be
ignored by BugTraq, though it is not unusual for that application
to dump core.
In late 2001, I noted that while there there had been no security reports more recent than before lynx 2.8.3, common gossip continued that lynx is subject to multiple buffer overflows. (From 2009, that comment still holds; there are occasional issues to resolve, but "multiple buffer overflows" is nonfactual). It is in fact easier to fix the code than to stop the gossip. Report bugs if you find them. However, asserting in a BugTraq-style posting that one "could" cause a failure in a program is different from actually doing so.
It used to be the case that security teams would notify the developer of flaws and get them involved. Perhaps some still do, but for others, the goal appears to be guided by the intent to publish the flaw first. Since they're generally unfamiliar with internals of larger programs, the published fixes tend to fall short of solving the problem.
This advisory states "several vulnerabilities", though two are reported. Further, the patch (mostly code-cleanup) was one that I wrote, as inprogress development. However two organizations misattributed it to OpenBSD. Rather than checking with me to help with a minimal patch, they simply published it.
In an earlier advisory, I had responded to the report, and constructed a patch. The security team issued a different patch, which did not actually solve the problem, as I noted here.