Re: [suse-security] Does Rich Text hold the same risks as html ?

[Crispin Cowan <crispin@xxxxxxxxxx>]

jfweber@xxxxxxxxxxxxx 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


-- 
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here