Lynx Internal URL "secure" Parameter/Internal Link Verification Vulnerability
BID:804
Info
Lynx Internal URL "secure" Parameter/Internal Link Verification Vulnerability
| Bugtraq ID: | 804 |
| Class: | Design Error |
| CVE: |
CVE-1999-1549 |
| Remote: | Yes |
| Local: | Yes |
| Published: | Nov 17 1999 12:00AM |
| Updated: | Jul 11 2009 12:56AM |
| Credit: | First posted to BugTraq by Michal Zalewski <[email protected]> on Nov 17, 1999. Additional details posted to BugTraq by Michal on Nov 18, 1999. |
| Vulnerable: |
University of Kansas Lynx 2.8 University of Kansas Lynx 2.7 |
| Not Vulnerable: | |
Discussion
Lynx Internal URL "secure" Parameter/Internal Link Verification Vulnerability
Lynx generally classifies webpages as either internal or external. Internal webpages are those which are used for such things as configuration, handling downloaded files, etc. External are webpages that are normally visited from a web client and are on a webserver somewhere "external" from the client. To prevent authors of malicious webpages from compromising the internals of the client, the creators of lynx put a number of restrictions on what can manipulate the internal URLS. The first is a hidden form value passed to internally rendered pages, called "secure". Unfortunately, this value doesn't live up to its name, since it is based on time(). The next method is verifying whether the pages which contain internal URLS are allowed to or not. This is done by comparing the titles of the pages being verified to what they should be (if they were legal). The section of code which does this naive check is below:
[...]
(!strncmp(links[curdoc.link].lname,
"LYNXDOWNLOAD:", 13) &&
strcmp((curdoc.title ? curdoc.title : ""),
DOWNLOAD_OPTIONS_TITLE)) ||
(!strncmp(links[curdoc.link].lname,
"LYNXHIST:", 9) &&
strcmp((curdoc.title ? curdoc.title : ""),
HISTORY_PAGE_TITLE) &&
[...]
If it is possible for an attacker (locally) to convince a user to enter a configuration page ('O') in lynx, the "secure" value can be obtained by calling utime() on the temporary file created in /tmp (which is where lynx creates temporary html pages). Once the "secure" value is obtained, a malicious page which is titled appropriately can pass configuration values as hidden form variables to LYNXOPTIONS://, which will take them gladly and modify the configuration options of the user (for example, setting editor to whatever the attacker wants) silently. There is a possibility that this can be exploited remotely, if the value of "secure" can be guessed.
More vulnerabilities which are consequently exposed by this problem are exploitable buffer overflows in handling of some of the configuration options. Known to lack bounds checking are operations on the buffers which store (at least temporarily) the values for options: "user agent", "preferred language", and "preferred charset".
Lynx generally classifies webpages as either internal or external. Internal webpages are those which are used for such things as configuration, handling downloaded files, etc. External are webpages that are normally visited from a web client and are on a webserver somewhere "external" from the client. To prevent authors of malicious webpages from compromising the internals of the client, the creators of lynx put a number of restrictions on what can manipulate the internal URLS. The first is a hidden form value passed to internally rendered pages, called "secure". Unfortunately, this value doesn't live up to its name, since it is based on time(). The next method is verifying whether the pages which contain internal URLS are allowed to or not. This is done by comparing the titles of the pages being verified to what they should be (if they were legal). The section of code which does this naive check is below:
[...]
(!strncmp(links[curdoc.link].lname,
"LYNXDOWNLOAD:", 13) &&
strcmp((curdoc.title ? curdoc.title : ""),
DOWNLOAD_OPTIONS_TITLE)) ||
(!strncmp(links[curdoc.link].lname,
"LYNXHIST:", 9) &&
strcmp((curdoc.title ? curdoc.title : ""),
HISTORY_PAGE_TITLE) &&
[...]
If it is possible for an attacker (locally) to convince a user to enter a configuration page ('O') in lynx, the "secure" value can be obtained by calling utime() on the temporary file created in /tmp (which is where lynx creates temporary html pages). Once the "secure" value is obtained, a malicious page which is titled appropriately can pass configuration values as hidden form variables to LYNXOPTIONS://, which will take them gladly and modify the configuration options of the user (for example, setting editor to whatever the attacker wants) silently. There is a possibility that this can be exploited remotely, if the value of "secure" can be guessed.
More vulnerabilities which are consequently exposed by this problem are exploitable buffer overflows in handling of some of the configuration options. Known to lack bounds checking are operations on the buffers which store (at least temporarily) the values for options: "user agent", "preferred language", and "preferred charset".
Exploit / POC
Lynx Internal URL "secure" Parameter/Internal Link Verification Vulnerability
See discussion.
See discussion.
Solution / Fix
Lynx Internal URL "secure" Parameter/Internal Link Verification Vulnerability
Solution:
Currently the SecurityFocus staff are not aware of any vendor supplied patches for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [email protected].
Solution:
Currently the SecurityFocus staff are not aware of any vendor supplied patches for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [email protected].
References
Lynx Internal URL "secure" Parameter/Internal Link Verification Vulnerability
References:
References: