Slashdot Mirror
How Do You Handle New MS Word Vulnerabilities?
chipperdog asks: "With yet another zero-day exploit of MS-Word document files, what are fellow system admins doing to protect themselves against these threats? I have been blocking all .doc and .dot at the mail and proxy servers until malware scanners have signatures to detect and block the malicious files. Of course, this caused a uproar with the users, as there were continuous calls like: 'When can I send and receive Word files again' and 'I can't get anything done if I can't send/receive Word files'. Any suggestion of sending documents in different formats (like rtf, html, txt, or pdf) results in even more creative user 'feedback'. Has anyone done anything creative in their handling of word files — like having qmail-scanner pipe all .doc attachments through something such as wv to convert them to a less exploitable format?"
All attached DOC files are filtered and placed in to a users quarnetine folder (which they have access via a web browser). Simple permissions keep them from accessing the file itself until it can be checked. Once checked, permissions are changed and the user can pull the document.
It's frustrating for the end user as they don't have instant access to their attachment (sometimes there's a 4-hour delay before the file can be manually inspected -- still waiting for some def-files!) and it's taxing my staff time-wise to do this (we've got better things to do than check for any monkey-business in word documents). We've suggested everyone convert to PDFs and send THOSE and it's been working but it's still a disruption.
Actually, a zero-day exploit is an exploit (piece of attack code) that is making use of a previously-undiscovered/undisclosed security vulnerability. Contrast this to freshly discovered security holes that don't have any exploits written for them yet (which is most security announcements), and exploits that have been written to take advantage of previously known security holes.
have one admin with vmware player and a vm that mounts read-only the quarantine folder on the network where any 'suspect' doc is dumped (resumes, attachments from untrusted sources, whatever), in the vm convert the .doc to .pdf and put it in a separate directory that is instead accessible from everybody. Of course the vmware image should be configured NOT to have access to absolutely anything but this one 'quarantine' host.
.docs from untrusted sources. After all if the HR person's desktop gets compromised you'll be in a LOT more pain than if somebody else's was, given the sensitivity of the information that generally is stored in there...
Users then access the pdf files from the 'safe' area normally, if you want to just have the admin move files to separate subdirectories with appropriate user permissions.
If you don't want to have a designated person doing this, you could mandate that your users can use email only from within VMs (that don't have any sort of network access besides receiving email) and must convert to a different format before saving it on a shared folder on their local disk.
I think something along these lines (quarantine + conversion to a different format, whether centrally located on on everybody's box) should be mandatory for offices where they are expecting
-- the cake is a lie
Well I use Linux so I dont have MS Office but I extract the text from MS Word documents using Antiword or Catdoc and then read them in Vim.
.vimrc to make it automagic:
Antiword: http://www.winfield.demon.nl/
Catdoc: http://www.45.free.net/~vitus/software/catdoc/
Add this to your
autocmd BufReadPre *.doc set filetype="msword"
autocmd BufReadPost *.doc silent %!antiword "%"
autocmd Filetype msword call s:MyMSWordSettings()
function! s:MyMSWordSettings()
set readonly
set hlsearch!
endfunction
For RTF documents, check out UnRTF: http://www.gnu.org/software/unrtf/unrtf.html
The latest vulnerability doesn't require macros.
"Data used by Microsoft Word to construct a destination address for a memory copy routine is embedded within a Word document itself. If an attacker constructs a Word document with a specially crafted value used to build this destination address, then that attacker may be able to overwrite arbitrary memory,"
There's no way to protect from these documents via group policy, short of a group policy that disallows word from running.
Thanks for the links. I know this problem isn't proven on OS X, but based on the executive summary I'd suppose it could be an issue, so to Mac OS X people, textutil(1) can read doc and convert to txt, html, rtf, or even webarchive, so you get all the images.
Textutil is in /usr/bin on an install of OS X, and just acts as a wrapper for the OS X text word processing subsystem.
Don't blame me, I voted for Baltar.