PDA

View Full Version : Are all BUGS really bugs?



theBlackman
10th Oct 2002, 22:46
Another little tidbit from one of my favorite newsletters
9) Word Bug?

I debated whether or not to cover this item, but I've gotten enough mail
to convince myself that I must.

Specifically, it's about a problem with Word that some seem to think is
a huge security hole. For example, a Techweb item began this way: "Are
Your Word Documents Bugged? Every version of Microsoft Word after Word
97 hides a potentially serious security vulnerability that could let
outsiders steal documents from your company. And no anti-virus or Trojan
scanner will pick it up." (See
http://update.techweb.com/cgi-bin4/flo?y=eI8B0BC4pF0CLf0BjLc0Af ) Many
other sites carried stories along the same lines. Some went over the top,
accusing Microsoft of lying about the severity of the problem, or worse.

The specifics of this problem involve "fields" that can be hidden inside
interactive Word documents. These special fields are meant to pick up
routine bits of information to auto-complete portions of documents, but
they can be subverted to pick up other information--- even whole
additional files or documents--- and embed these additional items
invisibly inside a document.

That sounds bad, but consider: A malicious hacker would (1) have to
figure out how to craft this kind of special field, (2) send it to you,
(3) entice you to open the document in Word (thus triggering the
malicious fields), (4) get you to save (not just close--- but actively
save) the document so the data collected by the fields would be stored
inside the document, and then (5) somehow get you to send the saved copy
of the document back to the hacker. How likely is that elaborate chain
of events?

The most successful security exploits are those that happen subtly,
beneath the notice of most users. This one practically jumps up, bites
you on the nose, and says, "Hey, pay attention! Something fishy's going
on here!" How could you not notice?

And talk about leaving a trail! Even if all the above somehow did come
to pass, you'd still have your local copy of the malicious document on
your hard drive, along with the original and return emails. What hacker
in his right mind would use a method that not only requires a high level
of active involvement on the part of the victim, but also leaves behind
a copy of the incriminating evidence and direct pointers back to the
source of the problem?

Routine security--- such as never opening documents from strangers---
short-circuits the entire unlikely chain of events. And basic common
sense--- never open, re-save and re-email a document back to a stranger-
-- also applies. You'd have to be nuts to do that.

OK, what if it's not a stranger? In an office or collaboration setting,
if someone you work with has snooping or larceny on his mind, they'll
find a way to do it: The issue isn't fields inside Word documents, but
the trustworthiness of your colleagues. Plus, this method would still
leave a wide, obvious trail pointing back to the perpetrator. Duh!

Finally, as another way of avoiding this whole kind of issue, I've long
recommended that people use universal, platform- and brand-independent
.RTF ("rich text format") when exchanging documents; it's safer (not
"100% safe"--- nothing is) than the DOC format, and the files are
smaller, too.

Long-time readers of this newsletter know how seriously I take
security. But not all security problems are equal, and some--- like
this one--- are truly minor.
Click to email this item to a friend
http://www.langa.com/sendit2.htm

Vanguard
11th Oct 2002, 04:42
A product that does not behave *as designed* or *as intended* or *as spec'ed* has a bug (although some are more related to usability than for incorrect behavior).

Behavior which does not obey your desire on how the product should operate are not bugs. If you want them changed, you do not issue a Bug Report. Instead you issue a Request for Change (RFC) and describe how you want the behavior changed, or you issue a Request for Enhancement (RFE) to alter the designed behavior of the product or alter its behavior in a future version or to remove it. If the data field in Word can be subverted and you can document it then you issue a bug report. If the data field retrieves the wrong value or behaves incorrectly, you report a bug. But deciding that the feature is now a security risk does not qualify it as a bug; you issue a Request for Change to remove it or a Request for Enhancement to get it more secure (and possibly without reducing its functionality but usually something has to give) or remove it.

The use of the data fields in Word was designed into the product. It was only hidden to those that don't know the complete feature set of the product or how the product is supposed to behave. Can it be subverted? Well, yeah, most features regarding ease of use or convenience can be subverted to act differently than intended. Even the "X" button at the top right of your Windows window could be used to close your window without you wanting it to. Would you instead want to answer a 3-layer deep confirmation procedure that deliberately switches the response to ensure *YOU* really wanted to close the window instead of a script, javascript, or other function ("Do you really want to close?", Yes or No, default = No; "Do you wish to continue the close of the window?", Yes and No, default = Yes; "Click CLOSE to close the window", Close or Cancel, default = Cancel), but that could also be scripted using the default values so perhaps you should make them random, huh? What a pain.

I'm used to testing a product based on its Functional Specification (what features are supposed to be in the product) and by its more detailed Engineering Specification (on how the features actually get implemented). Bugs get reported when behavior doesn't match these documents. Bugs *also* get reported when, for example, a programmer decided to go beyond the specification to add further functionality that is not required, not wanted, not planned, wasted their time, wasted our time, wasted company money, delayed the schedule, and especially if it is new and flaky and doesn't normally get tested because it wasn't in the specs. Granted that end users don't get to see these design documents, but they do get user manuals and I'm pretty sure the use of data or info fields in Word is documented in Word's help (although a lot of advanced features require you to obtain documentation beyond what is included with the product by default).

There are many "features" of Windows and applications that have had to be curtailed or restricted because of misuse. When the ILoveYou virus starting spreading, many companies had their IT departments disable Windows scripting (Wscript.exe and Cscript.exe) on all their hosts. This eliminated some of the problem but it also crippled applications that used these scripts. A script interpreter is not unique to Windows; Unix has them, too, or you can get Perl for free (for both Windows and Unix). Having a script interpreter (rather than having to program in C++ or some other compiled code) is a feature, not a bug, but obviously it can be subverted, especially if it is a potent script interpreter.

More security = less convenience, so you have to decide just how susceptible you want to be or how paranoid. I usually choose to have more convenience, but then I'm also smart enough to have disaster recovery procedures to restore my system and/or data if the security wasn't sufficient to protect me at that time. Security is okay as long as it doesn't waste more of your time and money than it would to recover. I have one spare tire in my car, not one for each wheel on the car. If I wanted better security, I'd get a full rated tire as a spare instead of the cheapy emergency spare, but I'd still only have 1 spare tire. I use a *personal* firewall product on my home computer because the headaches and complexity of supporting a enterprise-wide corporate level firewall would be ridiculously extreme for home use. At work, it makes sense but then it can consume your whole job, too.

Reminds me of an Angora cat my grandma had that would walk down the sidewalk while slinking along slowly to inspect behind every leaf and obstruction along the walkway to ensure nothing would pounce on it - and it would take a long time to walk even 10 feet. Her other cat, a calico, would just bound along and simply handle whatever might happen to "attack". Both cats lived in the same environment under the same freedoms and hazards so one chose to be overly cautious and waste more time and energy while the other chose to live a normal life. One wanted a lot of security, the other was satisfied with a more normalized level.