[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [suse-security] Does Rich Text hold the same risks as html ?
> 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
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
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
* PDF: Did you know that the PDF standard allows for embedded
document providers (marketing) to determine who is reading
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
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 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