>I read in Cheswick & Bellovin, and also in a red book that's supposed to
>help me configure a certain firewall, that pointers in WWW retrieved
>documents could conceivably contain commands that would subvert the
>client machine. Obviously I can't expect a firewall to protect against
>such attacks any more than viral infected ftp downloads. For performance
>I would prefer to provide a socks server function on the firewall. Has
>anyone heard of real attempts to use embedded pointers maliciously? What
>protection do current web browsers provide? From these texts I infer
>that pointers embedded in html documents are more than simple references
>to protocol/address/document.
>
>Frank Senter
>Senior Information Specialist
>Missouri Highway and Transportation Department
>P.O. Box 270
>Jefferson City MO 65102
There was a simplistic piece of C code in a previous release of NCSA's
Mosaic for X which assumed that most everything past the double-slash
(//) of a telnet URL was the hostname (ie. an Internet FQDN) -- 'cept
if it had a colon and port number I would assume.
The code sprintf()d or concatenated the afore hostname onto a string
in a buffer that looked like "telnet " and then called system() on the
final string.
The browser was susceptible to malicious URLs planted in HTML docs
that looked like:
"telnet://ds.internic.net;/bin/rm -r *"
(I'm not certain whether spaces or %20 placeholders could be used in
the nasty URLs).
Another problem is with unsafe PostScript interpreters, since many
people set up their browser to invoke a PostScript viewer automatically
on downloaded PostScript files ( ie. <A HREF=virus.ps>View Report</A> )
and some PostScript interpreters allow executing postscript programs
to do file I/O, process creation, etc (though most now allow you to disable
unsafe features)..
- Morrow
Follow-Ups:
|
|
