lynx-2.8.x.txt

`// This message hasn't been sent to lynx-dev list, as it requires  
// subscription for sending bugreports. Sorry for that.  
  
Since 2.7 releases (?), lynx has mechanisms to avoid spoofed 'special  
URLs'. It's designed to protect lusers from malicious, internal  
pseudo-protocols like LYNXDIRED://, LYNXDOWNLOAD://, LYNXPRINT:// etc,  
inserted by those little, evil, hacking boys and girls, into external html  
documents. These protocols should be allowed only within internal lynx  
pages, like 'Download Options', 'File Management Options' and so on -  
these pages are rendered in /tmp (unless $LYNX_TEMP_SPACE is set) and  
displayed just like normal html (this solution not for the first time  
brings several security problems, but probably is quite convenient).  
  
Unfortunately, mechanism offered to classify html as 'external' (where  
special URLs are not allowed) or 'internal' (where special URLs *are*  
allowed) is rather... funny ;) Take a look at this code in LYMainLoop.c:  
  
[...]  
  
(!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) &&  
  
[...]  
  
Hmm?! Classification is done by... veryfying title of web page! Aghrr...  
Somewhat better checks are done for LYNXDIRED://, good luck (location of  
displayed file is verified as well - secure as long as $LYNX_SAVE_SPACE  
isn't set). Fortunately, most of LYNX*:// requests require user  
interaction/confirmation, but it's pretty dangerous, anyway, as we can  
access internal mechanisms, not designed to be called from nowhere except  
internal pages (hmm, what about overflows and lacks of security checks? at  
least NULL-pointer SEGVs are possible).  
  
  
Another issue is LYNXOPTIONS:// protocol. In sources, we can read about  
'paranoid security' when veryfying form submitted to LYNXOPTIONS://  
location. This form contains complete lynx runtime setup, usually  
configured within 'Lynx Options' page - you can invoke it with "O" key.  
'Paranoid security' is done by inserting hidden value called "secure" into  
this form. Value is calculated in very-special-and-secure-way - by calling  
time(NULL) (*SIGH!*).  
  
Attack is quite easy with local access (another lusers and root are  
possible victims). All you have to do is create evil webpage (in our  
example, A.html). In it, ask websurfer to check something in his config  
(eg. by putting text like 'Please make sure you have TagSoup html parser  
set in your config (press "O") before continuing'). Victim pressed 'O',  
and temporary file of size approx 8-9 kB (rendered html config interface)  
has been created in /tmp. It's name should be in format:  
/tmp/Lxxxxx-yTMP.html, where xxxxx is pid of browser and y is unique,  
small integer (starting from 1) - for example, /tmp/L1829-1TMP.html. All  
you have to do is to utime(...) on this file to determine 'secure' value.  
If you can't see what I'm talking about, stop now and read manpages for  
time(...) and utime(...).  
  
Then, you have to create next webpage, B.html (referenced with 'CLICK HERE  
WHEN DONE' from A.html ;), putting form with hidden fields containing your  
favourite configuration for victim's browser, and, of course, 'secure'  
field. For configuration form fields, take a look on /tmp file created by  
your browser. Another 'CLICK HERE' and form will be submitted to  
LYNXOPTIONS://. silently modyfying client's configuration. Just a  
suggestion: change 'editor' to your favourite shell-combo ('rm -rf /' for  
kiddies, 'cat /tmp/mykey >>~/.ssh/authorized_keys #' for script adults),  
set 'Save options to disk', then put mailto: in subsequent webpages -  
editor will be spawned automatically when new mail is edited within lynx.  
  
As you can see, direct implications of these lacks of security checks  
aren't deadly, but just a little bit of inadvertence combined with trivial  
psychological tricks might turn it into something quite harmful.  
  
_______________________________________________________________________  
Michal Zalewski [[email protected]] [link / marchew] [dione.ids.pl SYSADM]  
[Marchew Industries] ! [http://lcamtuf.na.export.pl] bash$ :(){ :|:&};:  
[voice phone: +48 22 813 25 86] <=-=> [cellular phone: +48 501 4000 69]  
Iterowac jest rzecza ludzka, wykonywac rekursywnie - boska [P. Deutsc  
  
  
Another detail on LYNXOPTIONS:// and bypassing evil configuration options  
to victim's browser - attack scheme could be even easier and can be done  
remotely. First of all, ask user to check his/her configuration, as stated  
in previous post (let's call this webpage A.html). Then, supply link to  
another webpage, containing evil form with configuration (B.html, see  
previous post for details). Value of "secure" field can be guessed easily  
- it's increased every second (huh, that's the way clock works ;).  
Victim's system time can be precisely estimated with help of it's MTA  
subsystem, so you can synchronize your clock with a little bit of  
shrewdness. Wait for GET request on A.html from victim, assume eg. +4  
seconds to read and understand text (and to press "O", this time is my  
blind assumption, probably some real-life test are helpful... but IMHO  
this time will be constant for maybe 95% requests, if webpage is designed  
properly and user won't need too much time to understand what user should  
do). Now, time difference (in seconds) between your and their system clock  
+ time(0) return value at the time of GET request + your estimation (4  
secs mentioned above) is "secure" value. Rebuild B.html by inserting  
proper "secure" field. Form fields should be hidden, some bogus text with  
big, good-looking 'submit' button will help.  
  
Now, the most interesting thing - by putting funny 'preffered charset',  
'preffered language' and 'user agent' fields into form (I've tried with  
>64kB of 'A's, but probably it could be much smaller), you'll cause  
beautifully exploitable stack overflow while viewing next webpage after  
pressing Big Button on B.html. After submitting configuration, last  
webpage is automatically reloaded, that's enough. No need to modify  
'editor' or anything else and wait.  
  
Program received signal SIGSEGV, Segmentation fault.  
0x4009ab97 in strcpy ()  
(gdb) info stack  
#0 0x4009ab97 in strcpy ()  
#1 0x80b802b in _start ()  
#2 0x41414141 in ?? ()  
Cannot access memory at address 0x41414141.  
  
Yes, it's much more social (reverse ;) engineering than hacking, all of  
these processes have to be automated and still you don't have 100%  
certainty, but those hacks where user reactions have critical meaning are  
the most interesting :)  
  
_______________________________________________________________________  
Michal Zalewski [[email protected]] [link / marchew] [dione.ids.pl SYSADM]  
[Marchew Industries] ! [http://lcamtuf.na.export.pl] bash$ :(){ :|:&};:  
[voice phone: +48 22 813 25 86] <=-=> [cellular phone: +48 501 4000 69]  
Iterowac jest rzecza ludzka, wykonywac rekursywnie - boska [P. Deutsch]  
  
  
`