Last week was shortened by the Thanksgiving holiday, and it seemed the malware guys took it off as well. There was not much going on of recent origin, and the biggest blip on the security radar was the realization by the security community that an Internet Explorer problem first identified six months ago was a lot worse than it appeared.The realization caused Secunia to issue a rare "Extremely Critical" advisory. Once thought just to be a DoS vulnerability, it turns out that it also allows execution of arbitrary code. Benjamin Tobias Franz figured out the original problem in March of this year, which can be summarized thusly: IE fails to correctly initialize the JavaScript "Window()" function, when used in conjunction with a event. This means that Internet Explorer encounters an exception when trying to call a dereferenced 32-bit address located in ECX.If we execute the following code:CALL DWORD [ECX+8] ECX will be populated by the Unicode representation of a text string named "OBJECT", which translates in hex to 0x006F005B. Because offset 0x006F005B points to an invalid (or non-existent) memory location, Internet Explorer fails to execute the next instruction in the stack and the user sees the application crash. This is why the problem was first classified as a Denial of Service. Franz told Microsoft of the problem in March. Microsoft has done nothing to modify IE to reflect this information in the last six months. It may be because the risk of exploit was considered at the time to be "low".And this is where things get more interesting.S. Pearson, of computerterrorism.com, realized that the offset in the vulnerability had some specific properties, namely that the offset range is reserved for the facilitation of all opened Window characteristics on the desktop. These structures vary in both length and content, and usually will take the form of window titles, buttons, as well as the File/Edit/View menus bars that are attached to a specific Windows session.
Mac users miss all the security fund. Click here to read more. Trying out various elements, he realized that a Javascript prompt box was of the right size and form to allow (by calling it a few times) the insertion of custom shellcode aligned to where the exception (when forced as shown in the preceeding paragraph) would end up (at 0x006F005B). That means a remote attacker can execute arbitrary code by using specific Javascript functions that were embedded into an otherwise normal looking Web page.The vulnerability has been confirmed on a fully patched system with Internet Explorer 6.0 and Microsoft Windows XP SP2, and Internet Explorer 6.0 and Microsoft Windows 2000 SP4. IE 5.x is also considered to be vulnerable.A proof of concept page is available at computerterrorism.com to convince yourself that this does, indeed, work.Since MS has not addressed this issue in IE, the only way to mitigate is to disable active scripting for non-trusted sites. Or don't use IE.More turkey, anyone?
