To: GG who wrote (38691 ) 1/6/2004 5:04:28 PM From: Volsi Mimir Respond to of 110626 Threatfocus and Word for Windowsthreatfocus.com Tenacious W32/Sober.c-mm Attacks (PC MAGAZINE article read which points to Threatfocus site==http://www.pcmag.com/article2/0,4149,1426164,00.asp) Microsoft Security Updates Microsoft has not issued a security update since November, though several apparently unfixed vulnerabilities have been reported to security sites. The first is a Word for Windows document protection vulnerability that could let an unauthorized user unlock documents without a password. The vulnerability reported by ThreatFocus describes how a user can resave a protected file as an HTML document, find the password, and then unlock the original document. Another vulnerability is a showHelp() input validation flaw that may allow a remote user to execute arbitrary files on a victim's system. The showHelp() system was patched in a Security Update late last year, but this appears to still be a problem. The full description is on the SecurityTracker.com site. The next is an Internet Explorer exploit that involves the default Trusted Domain security zone settings. According to a report on SecurityTracker.comthis vulnerability allows a malicious remote user to silently download and install an executable file on a victim's system. This cross-site scripting vulnerability lets a web site fool IE into thinking it is a trusted site, allowing it to download files without IE's normal "Do you want to download this file?" message. Like the showHelp vulnerability, Microsoft has issued several cross-site scripting patches, but this appears to still be a problem. A posting on Gadgetopia.com alerts users to a possible privacy hole in Outlook Web Mail. This privacy problem is not unique to Outlook Web Mail, as it uses a header variable called HTTP_Referer [sic]. The HTTP_Referer information is passed when you click on a link on an HTML page, and can tell the target site where you came from. In the Gadgetopia article, the author explains that someone could use readily-available tools to ferret out the name, address and phone number of the person. While the author also said he didn't know of a way to protect against it, we have found that using a product like Anonymizer or an anonymous proxy can block the HTTP_Referer information. ====================================== from Threatfocus from the above link Overview: --------- Word provides an option to protect "forms" by password. This is used to ensure that unauthorized users can not manipulate the contents of documents except within specially designed "form" areas. This feature is also often used to protect documents which do not even have form areas (quotations/offers etc.). (Word users will find this option on the "Tools" menu, entry "Protection", select "Forms" there and provide a password) If a Word document is "protected" by this mechanism, users cannot select parts of the text or place the cursor within the text --- thus they cannot make any changes to the document. Description: ------------ When saving protected Word-documents as html-files, Word adds a "checksum" of the password (enclosed in a proprietary tag) to the code. The checksum format looks somewhat like CRC32 but currently there are no further details available. The same checksum can be found within the original Word document (hexadecimal view). If this "checksum" is replaced by 0x00000000 the password equals an empty string. Example: -------- 1.) Open a protected document in MS Word 2.) Save as "Web Page (*.htm; *.html)", close Word 3.) Open html-document in any Text-Editor 4.) Search "<w:UnprotectPassword>" tag, the line reads something like that: <w:UnprotectPassword>ABCDEF01</w:UnprotectPassword> 5.) keep the "password" in mind 6.) Open original document (.doc) with any hex-editor 7.) search for hex-values of the password (reverse order!) 8.) Overwrite all 4 double-bytes with 0x00, Save, Close 9.) Open document with MS Word, Select "Tools / Unprotect Document" (password is blank) Variation: ---------- If the 8 checksum bytes are replaced with the checksum of a known password it should be fairly easy to unprotect the document, make any necessary changes, save, close and reset the password to the original (unknown!) password by simply restoring the original values. Document changed without even knowing the password. Nasty. (Note: Take care to get file properties (author, organisation, date/time etc.) right.) ====================== Also points to a Microsoft Knowledge articlesupport.microsoft.com