jfweber@bellsouth.net wrote:
And hence should be banned or tightly controlled locations where it can be read? OR is it a completely other kind of animal, as "safe".. at least as safe as anything coming thru the system sent by people you may, or not, know.
Is Rich Text "safe"? They're all just ones and zeros :) What makes something "unsafe" is the software you use to interpret those ones and zeros. Roughly speaking, the more interpretation you do to the data, the less safe it is, to wit: * Printed papers: mostly safe, unless it is a scam and you can get a human to do something dangerous. * Plain ASCII: pretty safe. It is hard to make plain ASCII do something dangerous all by itself, if all you do is render it to an xterm or such. o Danger: what if there is an arcane exploitable buffer overflow in your xterm-alike of choice? o Danger: embedded backspace characters can make the text say things it doesn't seem to say. If you digitally sign it, you may be agreeing to something you didn't mean to. * 8-bit ASCII: enables some international alphabets, and pretty ASCII art animation if you cat the file to a vt100-compatible terminal. o Danger: international alphabets have enabled people register domains that seem to say "microsoft.com" except that some of the letters are Cryllic, so it isn't really the Microsoft you think it is, even though it has a valid SSL certificate. * Rich Text: While I use it every day (I really like HTML in my e-mail in Thunderbird, it enables a lot of expression) I am not technically familiar with the difference between this and HTML. Presumably some kind of restricted subset. o Danger: HTML rendering is complex, leading to a spotted history of buffer overflows & such in the rendering engines. Thus making it more likely possible to create malware e-mail that 0wns the mail client. o Danger: someone else has mentioned scripting issues. I'm not clear on what good Rich Text is if it doesn't strip away scripts. o Web Bugs: the message can include images, either overt pretty images, or hidden images that are 1x1 pixels and transparent. If these images are href's to a remote server, then the server operator can tell every time you view the message. Older Rich Text mail clients just displayed these images all the time :( but modern Thunderbird has a security setting for whether to display embedded images always, only if the images are attached to the mail, or never. * HTML: similar risks to Rich Text, but without whatever benefits the Rich Text restrictions confer. o Danger: XSS (Cross Site Scripting). For web sites that allow users to upload content, attackers can upload content that is not what it appears to be, and when you trust the hosting site and click on it, bad things happen. o Danger: more scripting stuff. o Danger: more complex rendering due to additional enabled features vs. Rich Text, so more opportunity for remotely exploitable flaws. * PDF: Did you know that the PDF standard allows for embedded Javascript? And that the Adobe Acrobat viewer executes this Javascript? Much much scarier than web bugs. o Danger: This Javascript is *explicitly* used by various document providers (marketing) to determine who is reading their documents. o Danger: Javascript is a programming language, and they can embed as much malicious code as they want to, running with the privilege as the user displaying the document. Do not *ever* view a PDF as root. * Postscript: This *is* a programming language. You can write malware in Postscript. o Danger: There has been an incident where there was a vulnerability in an HP printer, and suitable malware could 0wn the printer and from there use it to attack the rest of your network. o Danger: DoS. I have seen a postscript file that renders a lovely raytrace of a scene with a mirrored ball on a tilted checkerboard. It is only a few KB long, prints only a single page, and can run inside your printer for hours ... * Instant Messages: There is a *long* history of remotely exploitable vulnerabilities in multiple IM clients. o Danger: nasty message senders can 0wn your IM client, and from there 0wn either your user account or your machine. * ActiveX: a Windows issue, this is *supposed* to be safe-to-run code, but in practice ActiveX + XSS leads to wholesale vulnerability, which is much of the core of the spyware problem that Windows users have. * MS Office .doc files: MS Office documents (.doc files, .ppt files, .xls files) all embed VBScript code in the format. The MS document handlers auto-execute the code when you open the documents, allowing the transmission of malware. o Danger: this mis-feature of MS architecture is a principle cause of the virus problem. Linux is relatively safe so long as VBScript doesn't auto-run when opened in OpenOffice or similar Linux applications. * Actual Code: If someone sends a .exe file to a Windows user, or a binary executable to a Linux user, and they actually run it, then arbitrarily bad things can happen. * Caveat: this is not a complete list ... So as you can see, the safety issue is not the ones and zeros themselves, but rather how you interpret them. All the above formats are perfectly safe if you just pop them open in a byte viewer and look at them. Unless the text says "There is no Santa Clause" or other such seditious ideas, in which case, say, showing it to your 5-year old could pose a threat. But that is a matter of interpretation :) Broken record solution: security confinement of the interpreting engine. On my machine, there is an AppArmor profile around my Thunderbird mail client, my Gaim IM client, and my OpenOffice suite. This means that AppArmor policy strictly bounds just how dangerous each of these formats is to interpret. This message was composed in HTML, and then rendered down into 7-bit ASCII before sending, for your safety :) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Olympic Games: The Bi-Annual Festival of Corruption