SYNOPSIS

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.

HIGHLIGHTS

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:

The first (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.
The other (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.

DISCUSSION

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.

Though there have been no security reports more recent than before lynx 2.8.3, common gossip continues that lynx is subject to multiple buffer overflows. 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.