Microsoft Confirms Excel Zero-Day Attack

Guglio writes "Eweek has a story about a new, undocumented Excel flaw that is being used in a targeted attack against an unnamed business. The latest zero-day attack comes just two days after Patch Tuesday (coincidence?) and less than a month after a very similar, 'super, super targeted attack' against business interests overseas. The back-to-back zero-day attacks closely resemble each other and suggest that well-organized criminals are conducting corporate espionage using critical flaws purchased from underground hackers."

Comments

Re:news?

[SheeEttin]

MS makes it so difficult not to run with administrator privileges

Actually, it's not that hard. Log in as a limited user, do whaever you need to do, and if you encounter a program that absolutely needs to run as an admin, just right-click > Run as..., enter admin account name and password, and the program will run under the admin account. I personally haven't made the permanent switch to Linux yet, but I think it's comparable to sudo.

Patches Available

[GogglesPisano]

Patches for this problem available here, here and here.

Re:Why read the article?

[Solder Fumes]

You're waiting for Swordfish (2001)?

Re:Presumably they could but...

[cowbutt]

It's also a much safer route legally speaking because you aren't directly involved in the criminal act, you're just selling the tools.

Be carefull!!! In the US, you can be charge with being an accessory to a crime.

...and shortly in the UK also if the government get their way. Or, for that matter, if you create a security testing tool that some copper takes a dislike to.

Re:It's part of Microsoft's plan - MOD PARENT UP!

[iamcf13]

I heartily agree!

But 'backwards compatibility' made Windows the (in)famous clusterfsck it is.

Imagine how stable and secure Windows would be if Microsoft rewrote and streamlined it (goodbye .dll hell!) and the apps that they put out that use it from the ground up to avoid all the exploits and what not like this programmer (.chm) does... (His Win32 OpenSSL 'repack' was very useful to me on a past project. Here is his 'about me' page. Just on the strength of the blockqoute below, I know this guy knows what he is doing and deserves any work/support you can send his way....)

There is more to life than 'just making a buck', but when this is done at the corporate level, it transforms everybody it touches to seen-it-all, done-it-all cynics who keep their funds close to them, part with them only when necessary (food/clothing/shelter/heat/lights/vehicle fuel and maintennance/public transport fares/occasional recreational spending) and do anything they can to escape its clutches (i.e. use adblock when online, and A/V devices capable of 'adskipping').

(I 'posted' the text below in an earlier comment here but I can't find the link to it right away. Note, I'm not a shill for this guy, just an admirer of simple, elegant, secure C program code that I can learn from and use in future projects.... It would be nice if the following, complete text was on a standard webpage instead of being imbedded in a compiled HTML file (.chm) =/ )

Security. There's a little word with a big meaning. Unlike other web servers, ProtoNova is secure. What exactly does this mean in terms of what a web server should be?

[snip]

Before I conclude, I have one other thing I wish to mention that defines security. This is the fact that ProtoNova is the only web server in existence guaranteed to be free from Buffer Overflow attacks on the stack at the application level. Let's see you try to get a guarantee like that from Apache or Microsoft. While I can't control problems with the underlying OS or libraries, I can control how I write my own code. Here's my secret to how I can make such a guarantee: Dynamically allocate all memory I use on the heap. 90% of all bug fixes for exploits (potential or otherwise) coming out of various organizations (ahem, Microsoft) are for Buffer Overflow attacks on the stack. A buffer overflow on the heap is far less dangerous than a stack-based overflow. If you don't know the difference, let me show you that I really do know what I'm talking about (whereas most journalists generally have no clue) using some C code - that is, the language most web servers are written in:

// Include necessary headers to compile
#include <stdio.h>
#include <stdlib.h>

// Start of the "main" function - used to tell the OS where
// to start processing source code.
int main(int argc, char **argv)
{
// Tells the computer to create 256 places in memory _on the stack_ for storage.
char str[256];

// This just tells the user how to use the program.
// Not really important, but useful.
if (argc < 2)
{
printf("Syntax: BadProgram TypeInAReallyLongString");
exit(1);
}

// This copies the data the _user_ specified into str.
strcpy(str, argv[1]);

// This prints the contents of str.
printf("%s\n", str);

return 0;
}

(For you programmers out there, please ignore the comments. I realize they are "basic/newbie," but I'm attempting to explain source code to newbies).

The example above is ext

Re:HOW!?!!?!

[mortonda]

Do you get executable code in a SPREADSHEET!?!

Buffer overflows

Re:HOW!?!!?!

[dhasenan]

Anything beyond basic usage requires a macro language--especially a spreadsheet program. Now, whether the macro language should be allowed to interface with the filesystem is a different matter entirely. I'd say that a user should be given a standard "Overwrite file $FILENAME? yes/no/cancel" dialog whenever a macro tries to overwrite a file; opening or listing the contents of a directory is a bit of a tricky matter, but I don't think many users would miss that feature.

Now, if the macros were available to an external scripting language like bash or one of the P's, then there would be no reason for the macro language to be able to list or open files, only write to them. Then you'd only have, as the above poster mentioned, buffer overflows and the like.

If we wanted, we could alter our standard libraries so that, for instance, strcpy does bounds checking. Is there a reason not to?

Re:HOW!?!!?!

[darkwind_2427]

HOW!?!!?!...Do you get executable code in a SPREADSHEET!?!

Actually, M$ uses OLE2 as the binary file format for all it's office products. This is actually like it's own file system. If you dig around in the files you'll notice there is a lot of padding where you can place whatever you want and M$ office products will not even notice. I'm not sure exactly how this exploit works, but I did some research into the MS03-050 exploit and discovered that buffer overflow would allow you to execute about as much shellcode as you would want on their computer. That one in particular was a simple matter of malforming the macro header table (changing the input length). No matter how high your security settings are the code will execute without your knowledge (if you open it).

Re:HOW!?!!?!

[Opportunist]

In this case it isn't a macro, they're using a buffer overflow error in the code that loads and interprets MS-Office files.

Basically, what happens is that the Office reading routine creates room on the stack for some variable, to hold X bytes. Right behind those X bytes, there is the return address for the subroutine (so the reader subroutine can actually come back to the original program).

Now, this return address is being overwritten by an address that points into the spreadsheet instead (it's not THAT simple, but that's the general idea behind it). And in that area of the spreadsheet, you don't find spreadsheet data but instead you have executable code. Which is then, of course, executed (because Office thinks it's "his" code).

Quite simple. And easily avoided (the way to do it can be seen below in another subthread, by a rather good example).