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

Carlos E. R. wrote:

The Wednesday 2006-01-25 at 16:01 -0800, Crispin Cowan wrote:

...

...

* PDF: Did you know that the PDF standard allows for embedded Javascript? And that the Adobe Acrobat viewer executes this ...

I thought this only applied to acrobat version 7. Also, I though that other viewers, like xpdf, were safe in this respect. I first noticed this behavior in Acrobat 7. I do not know for sure whether or not other PDF viewers do or do not implement the Javascript functionality. It would not surprise me to see a Javascript "improvement" appear in them some time.

A trick was published here about how to block acroread from contacting internet outside, using the local machine firewall. I posted a trick of how to prevent it using AppArmor, which is to deny Acrobat read access to the Javascript libraries. If there was a firewall-based trick, I haven't seen it. I have some issue with whether it *could* work; you are going to want to configure your firewall so that HTTP requests can go out port 80, and there is nothing to prevent the Javascript from using exactly that channel to get their message out.

Serious security stud muffins might argue that they would have web access blocked on their super secret machines. But what about DNS? Because web-bug information can be sent out via contrived DNS requests too. DNS makes a great channel for sneaking data around networks, because just about all firewalls pass it, so you can always get it through, so long as you have a DNS server that will collaborate with your signals. Long ago, Marcus Ranum allegedly implemented Telnet running over DNS. More recently, Dan Kaminsky has made a career out of demonstrating stuff as sophisticated as streaming video over DNS. The important take home lesson here is that if malware gets inside your protection, it almost certainly can export data out through any firewall. You have to do something more specific to prevent it from exporting your secret data.

Very interesting writeup, thank you! Thanks!

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

Carlos E. R. said:

The Wednesday 2006-01-25 at 16:01 -0800, Crispin Cowan wrote:

...

* 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.

I thought this only applied to acrobat version 7. Also, I though that other viewers, like xpdf, were safe in this respect.

Javascript is included in the PDF specificaton at least since v1.3 (i.e. Acrobat 4). And PDF supports event-triggered "auto-open" scripts with the same bad security design as MS Office formats (see chapter 8.5.2 in http://partners.adobe.com/public/developer/en/pdf/PDFReference.pdf for details). I'm not sure if xpdf implements the javascript functionality. For Acrobat, javascript/ECMAscript functionality is implemented as a plugin called "Escript.api" (found in the "plug_ins" subdirectory). To disable a plugin, simply remove it from this directory (including any subdirectories). Warning: Many other plugins depend on javascript (including the plugins for forms, spellcheck, weblinks, accessability, digital signatures, multimedia). All these won't work properly without javascript. -- Michel Messerschmidt, lists@michel-messerschmidt.de

Marcus Meissner wrote:

Yes. Adobe is basing functionality heavily on JavaScript.

Is it possible to defeat Adobe's external access and keep its javascript requirements by setting the preferences->proxy settings to something invalid? Like 192.168.235.235:27493? John Perry