If you want on or off the Mac Ping List, Freepmail me.
Posted on 06/20/2006 7:47:56 PM PDT by Swordmaker
Attack code for a new security hole in Excel has surfaced on the Internet, just as Microsoft is scrambling to respond to a separate bug in the spreadsheet program.
The latest vulnerability could cause Excel to crash after a malicious file is opened, according to an alert Symantec sent to customers on Monday. The security company also said there was a risk that an intruder could commandeer a PC. "Attackers may also be able to execute arbitrary code…but this has not been confirmed," it said.
The security hole exists because Excel fails to properly check user-supplied input before copying it to an insufficiently sized memory buffer, Symantec said. Excel 2003 and Excel XP are vulnerable, and other versions may also be affected, Symantec said.
Security monitoring company Secunia deems the issue "highly critical," one notch below its most severe ranking, according to an alert it published on Tuesday.
Sample computer code that exploits the flaw is publicly available on the Net. However, Secunia said it is not aware of any current attacks using the security hole.
Microsoft is looking into the issue, a company representative said in a statement Tuesday. "Based on our investigation, the issue is a new vulnerability in Microsoft Windows that may be exploited when clicking on a hyperlink with Office documents," the representative said. Microsoft is not aware of any attacks that exploit this flaw, he added.
The latest Excel vulnerability comes just as Microsoft is grappling with another yet-to-be-patched bug in the spreadsheet application. That flaw, disclosed late last week, could give an attacker full control over a vulnerable PC and has been exploited in at least one targeted cyberattack, Microsoft has said.
To exploit either one of the new flaws, an attacker would craft a malicious Excel file and host that file on a Web site, send it via e-mail, or otherwise provide it to the intended victim. The attempt can be successful only if the file is opened on a vulnerable PC.
Both vulnerabilities come on the heels of Microsoft's "Patch Tuesday" batch of security updates. Last week, Microsoft released 12 patches that addressed 21 vulnerabilities in various products, including Office applications. The company has said it is working on a patch for the first new Excel flaw.
Some experts believe the timing of the new exploits is no coincidence, as miscreants will have a month until patches are available. Microsoft typically does not release fixes outside of its monthly patching cycle for such flaws, these experts said.
On Monday, Microsoft posted tips for users to respond to the first Excel flaw, which affects all versions of the software, including those for Apple Computer's Mac OS. Microsoft suggests caution when opening Excel files. It also recommends blocking such files when they arrive as e-mail attachments or changing PC settings so spreadsheets can't be opened from the Outlook e-mail client or the Web.
For Excel 2003, Microsoft recommends that people prevent the application from running in "repair mode" by modifying some settings in the Windows Registry. The flaw is exploited in that special mode, Microsoft said in a security advisory on the issue.
• This vulnerability could not be exploited automatically through a Web-based attack scenario. An attacker would have to host a Web site that contains an Office file that is used to attempt to exploit this vulnerability. An attacker would have no way to force users to visit a malicious Web site. Instead, an attacker would have to persuade them to visit the Web site, typically by getting them to click a link that takes them to the attacker's site.
MIcrosoft FAQ on the Excel security flaw.
A trojan, in the wild, that attacks a Microsoft product causing it to crash is deemed a "flaw".
An unreleased example of a trojan on a Mac that still requires the user to give the trojan an admin username and password in order to do its dirty work is reason to panic.
The vulnerability is caused due to a boundary error in hlink.dll within the handling of Hyperlinks in e.g. Excel documents. This can be exploited to cause a stack-based buffer overflow by tricking a user into clicking a specially crafted Hyperlink in a malicious Excel document.
Secunia Excel Security Report
This is not as serious a flaw for Mac OS X users. Unlike Windows, OS X does not permit execution of any executable from the buffer... so the most it can do is to crash Excel on a Mac.
Oops, make that "Execution of any executable from the stack."
If you want on or off the Mac Ping List, Freepmail me.
All work and no play makes Mac a dull boy.
All work and no play makes Mac a dull boy.
All work and no play makes Mac a dull boy.
All work and no play makes Mac a dull boy.
All work and no play makes Mac a dull boy.
All work and no play makes Mac a dull boy.
All work and no play makes Mac a dull boy.
All work and no play makes Mac a dull boy.
All work and no play makes Mac a dull boy.
Is anyone else as peeved by this kind of stuff as I am? I've had serious issues trying to get data to people because of this idea of just blanket blocking of file types. It really pisses me off sometimes. A couple of times, the only way I could get data to a vendor that I needed to have them look at was to ftp it to them.
Microsoft malware is a plague.
If Bill Gates devotes all his money to a cure for HIV, it would be the first virus that Microsoft ever stopped.
Best laugh of the day. True...but funny.
I'm sorry, but that's not even remotely true - you can smash the stack on OS X with a buffer overflow, just as you can on just about any other OS. Here's one example of same:
http://www.idefense.com/intelligence/vulnerabilities/display.php?id=239
Any OS written in any language that doesn't automate bounds checking at compile time or runtime, such as C/C++, is potentially vulnerable to this sort of thing. And that includes OS X - the only thing you can do is patch 'em as you find 'em, or rewrite the thing from the ground up in a language that is a bit more sensible about such things.
Should be "bounds checking at compile time or toss an exception at runtime"...
That is true, you can smash the stack... but can the overflow contain code that will execute from the stack?
According to the Apple Developer Connection:
Code on the Stack: Disabling Execution
Intel (Core) processors include a bit that prevents code from being executed on the stack. On Intel-based Macintosh computers, this bit is always set to On.
And from another source:
A note on the NX bit:
This is actually a property of the page table, a bit that can be set on any page table entry to permit or deny code execution on that page. Mac OS X is setting this bit for all stack pages.The Mach VM system allows the system to assign default and maximum protection levels to each range of memory addresses in use. Programs may alter the default access (read, write, and execute) but may not exceed the maximum rights associated with an address range. Stack address ranges are set to deny execute permission as part of the maximum allowed rights, and this cannot be altered by programs.
The point is that on OS X, it is not as easy to get arbitrary code to execute merely by overflowing a buffer into the stack. If execute rights are denied at the system level for the memory locations of the stack, how can it execute?
In any case, NX is a hardware function, not a feature of the operating system. Windows systems on processors that support NX enjoy exactly the same protection. In addition, it's hardly a universal fix for buffer overflows. All NX does is prevent stack pages from being executed - it does not prevent the stack-smasher from pointing to another location in memory and executing code located there. And it can't.
I didn't say it "Can't be done" I said it is much more difficult to do. Yes, it is a hardware feature... but Windows sometimes uses programs that seem to require executing things in the stack, so it the protection is not enabled by default. In OS X it is enabled by default.
In additin, any malicious code would have to be OS dependent... and the likelyhood of it being Mac code is small. As I said, on a Mac the app, in this case Excel, would just crash when the stack was smashed.
If the code cannot be executed, how can it point to anything? It won't execute. Here is some salient comments from 6/7/2004 from Techrepublic.com on the benefits of NX implementation in Windows XP SP2 of the NX capability on certain CPUs:
NX support is added to Windows XP. NX (no execute) will allow NX-enabled CPUs to mark certain areas of memory as non-executable; that is, any code pushed into those areas (perhaps by malware such as Blaster or other viruses) will just sit there, unable to run and therefore will be rendered harmless. This will harden the OS against the notorious buffer overrun threats. NX is currently only supported for AMD’s K8 and Intel’s Itanium processors, but 32- and 64-bit support for this important security feature is expected in most future processor releases... The NX protection mentioned above is an excellent example of something that is definitely a powerful improvement from the security standpoint. However, NX has already been reported to have caused considerable problems (at least in the 64-bit version).
In any case, the NX bit is not set to ON by default in Windows because only a few CPUs are NX capable... and some programs break on encountering non-executable stacks.
I may be wrong, but it is my understanding that OS X sets the NX bit for data pages as well and prevents code execution there as well. This particular Excel vulnerability is apparently an overflow in the data stack... not the program stack.
...it does not prevent the stack-smasher from pointing to another location in memory and executing code located there.
While a return address might redirect the instructions to a malicious app in another non-protected memory area, on a Mac how does the malicious code get loaded there??? Are we talking about a much more sophisticated attack, or a buffer overflow? To accomplish installing malicious code in an executable area raises the bar considerably on a Mac. It would also seem to be overkill to use a buffer overflow to redirect to a surrupticiously installed program... if you have already done that, it should be trivial to get it to run.
Of course, the real solution for either Windows or Mac users to any trojan Excel file is not to download it in the first place...
However, in the more invidious application, the data filling and overflowing the buffer is carefully constructed to be a series of opcodes that will land on the stack, and the return address will be overwritten to point to this malicious set of opcodes, and then you're in a world of hurt. NX-protection prevents this by making the stack pages non-executable - you can overwrite the return address, but you can't pass execution on to your malicious payload.
HOWEVER, NX-protection cannot prevent the return address from pointing to some other location in memory, and passing execution off to that location - in particular, you can pass execution off to some location containing convenient OS opcodes, which you can then use to further your nefarious scheme. This is the whole rationale behind the Metasploit project, to document the locations of Windows opcodes in memory, so that they can be exploited in this manner. But it's not unique to Windows - if you know the location of vulnerable opcodes in OS X, you can call them from a stack exploit just as easily as in Windows, and NX can't prevent it, because it's passing execution off the stack.
Absolutely true. But you have to have either pre-installed an executable or modified the opcode to make it malicious (although an existing code that erases the HD would do... ;^)>) That gets back to making this a more sophisticated attack than just a buffer overflow with self contained malicious code that would execute from the stack.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.