[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

EXCEL CALL FUNCTION ("NEW YEAR HYPE") SECURITY HOLE ~~~~~~~



This is a sample from Woody's Office Watch, which is a pretty nifty free
newsletter.  Jamie

--------------------
Subject: Woody's Office Watch #4.2
   Date: Tue, 12 Jan 1999 23:1:36
  From: wow-robot@woodyswatch.com (Woody's Office Watch)
  
         --==>> WOW -- WOODY's OFFICE WATCH <<==--
   (your own Microsoft Word & Office guru every week!)
  13 January 1999                           Vol 4 No 2

  [snip]

EXCEL CALL FUNCTION ("NEW YEAR HYPE") SECURITY HOLE ~~~~~~~
There's been a lot of uninformed garbage flying around
about Excel's CALL function security hole, as reported in
WOW last December,
http://chkpt.zdnet.com/chkpt/hud0007500a/www.zdnet.com/zdhelp/office_help/wow98/wow1211/1211_01.html
as well as last week's WOW. I'm told that the Wall Street
Journal, no less, picked up the topic.

Except for last December's article (linked above), I
haven't been able to find a report on the hard, cold facts,
from an unbiased point ofview. Nobody seems to understand
the technical details. Fortunately, Dr. Vesselin Bontchev -
quite likely the world's foremost authority on macro
viruses - wrote to me today, to set the record straight for
you WOWsers. Here's what he says:

"The last issue of WOW mentioned the so-called "Russian New
Year" problem which was hyped recently by an Israeli
security company. The problem is definitely not new. It was
indeed discovered in Russia - but that happened in
mid-November. It was immediately reported to Microsoft.
Three weeks later, Microsoft reacted by trying to play it
down and releasing a patch for Excel 97 SR-2 which solves
the most serious aspect of the problem. There is absolutely
no reason to call it a "New Year" problem - except the
Israeli security company in question learned about it
around New Year's Eve. So, if anything, the latest
announcement should be called "Israeli New Year Hype".

However, the problem is indeed very serious. The
announcement from the Israeli company clearly contains a
lot of hype. Unfortunately, this hype could have a negative
effect on users' awareness, because some might dismiss it
as the usual hype used by security companies to market
their products.

What is the essence of the problem? Essentially, one of the
operators that can be used in Excel cell formulas, CALL, is
a very powerful function. It can call any of the Windows
API in KERNEL32.EXE - or of any other DLL on the user's
system. Furthermore, while Excel 97 has the so-called
built-in macro virus protection which pops up a warning if
the document that is about to be opened contains any
macros, cell formulas are not macros. So no such warning
gets displayed when opening a workbook that contains some
formulas using the CALL function, but no macros.

In practice, this means that you can open an Excel
worksheet, not get any kind of warning whatsoever, and the
contents of the worksheet can automatically create and
execute small programs on your local hard disk. These
programs can do *anything* - steal data, destroy data,
lower your security settings, drop viruses - anything.

As if that weren't bad enough, Internet Explorer and
Outlook automatically launch Excel to view remote XLS files
on a web page or pointed at by URLs in HTML e-mail. The
combination of these problems means that an attacker can
exploit this security hole by posting an URL to a
subversive Excel file on some web site. Or he could
mass-mail it in HTML e-mail to Outlook users. Then, when
the user clicks on the URL in the message, the Excel
document will be automatically downloaded to the user's
machine, Excel will be automatically launched to view it,
and the CALL statements in it will be automatically
executed. And, as we saw above, they could do just about
anything.

Obviously, the problem wouldn't be as bad if the user was
asked whether s/he wants to open and view the remote Excel
file instead of automatically launching Excel to view it.
That is why some people say that Netscape is "immune" to
this problem - because by default it asks the user before
launching Excel to view the file.

In order to make IE/Outlook do the same (they are both
controlled by the same setting), do the following:

Start the Windows Explorer (not IE). Select View/Options
and click on the File Types tab. Select one by one all the
file types related to Microsoft Excel (e.g., XLD, XLA, XLK,
XLC, CSV, DIF, SLK, XLT, XLV, IQY, XLB, XLM, XLS, XLW,
XLL). For each one of them, click on the Edit button. Make
sure that the checkbox labeled "Confirm Open After
Download" (near the bottom of the dialon that appears when
you click on the Edit button) *is* checked. In general, it
is a good idea to have this checkbox checked for all
registered file types. In particular, Word documents and
PowerPoint presentations also can contain malicious macros
- and their respective applications areautomatically
launched by IE and Outlook to view these remote files, too.

Of course, the procedure described above doesn't solve the
problem in Excel - and the problem of those users who
decide to open the file they have downloaded.Microsoft's
solution is far from perfect. In fact, I am tempted to say
"far from acceptable". It is only for Excel 97 SR-2. If you
use Excel 5.0, Excel 95, Excel 97 or Excel 97 SR-1, you are
still vulnerable. (At least those are the versions of Excel
I have confirmed to be vulnerable; it is possible that
earlier versions of Excel and also Excel 2000 are
vulnerable as well.) Also, Microsoft's patch simply
disables the ability of cell formulas to use the CALL
operator - so, if you have spreadsheets which make use of
CALL and need it, you are out of luck. Fortunately, the
patch doesn't disable the use of this operator in Excel 4.0
macros - so, you can solve the problem by rewriting your
spreadsheets to use such macros (or, even better, VBA)
instead.

To summarize - it is a very serious security problem. The
fact that Excel is so widespread and the fact that it can
be exploited even by an e-mail message is what makes it so
serious. The user community has been lucky that the problem
has been discovered before it has been exploited - but
somebody is going to exploit it sooner or later, so better
take whatever precautions you can. However, there is no
reason to panic - or to hype the problem unnecessarily."

Now *that* is the straight story. I'd like to thank Dr.
Bontchev, profusely, for making sense out of this problem.
And I hope the mainstream and trade press make some effort
to set the record straight. (But I won't hold my breath.)