On Fri, 17 Mar 2000, Servio Medina wrote: > Klaus, > > Thank you for the reply. I am following up on a post from Michael Zalewski > to the Bugtraq mailing list on Nov. 17, 1999 which spawned a thread in the > lynx-dev mailing list. One post (submitted by yourself) states "Yes, there > are two nasties that he found. And he's right about both of them." This > together with the FreeBSD Advisory (previous email to you) both caught my > attention and I started digging for more information. However, I was unable > to ascertain whether this was necessary to fix, and if so, the nature of the > correction(s) : where to obtain, who should obtain, etc. Ok, so there were three concrete issues raised in the messages you refer to (am I overlooking anything?): - relying on title string comparison for determining whether a page is what it appears to be (including, can it be trusted), - a hidden form field in lynx-generated HTML, named "secure", wasn't secure, - buffer overruns. These could be used, possibly in combination, for exploits. To my knowledge, the first two are adequately addressed in the current[*] development code (since 2.8.3dev.17, patch originally by me). As for buffer overruns, all known (exploitable) ones, including some brought up more recently on Bugtraq, are fixed since 2.8.3dev.22 (according to CHANGES file - I haven't looked at the actual code). So, the most recent code from http://lynx.isc.org/current/ does not have known exploitable bugs as far as I know. This isn't true of the previous code. [*] "current" == what lynx-dev and http://lynx.isc.org/ calls "current development" code. I don't know what "current" means for FreeBSD. Their advisory didn't say. In general, we fix them as we find them (or are made aware of them). It is true that parts of the lynx code are written in an insecure style. Other (large) parts aren't. Recent additions to the code have been made with security in mind[**], or are being reviewed as they are added. In general, the most recent "current" code should therefore be regarded as the most secure. [**] Perhaps with the exception of some code added specifically for MS Windows and for improved CJK character set support (also mostly meant for Windows) - things #ifdef'd with WIN_EX, CJK_EX, SH_EX. These arent' relevant under Unix, or nedd to be specially enabled. Klaus
