open it
included by default in Windows Vista and XP. Microsoft Producer is an
add-in for PowerPoint to create rich-media presentations.
A vulnerability was found in Windows Movie Maker and Microsoft Producer,
which can be triggered by a remote attacker by sending a specially
crafted file and enticing the user to open it. This vulnerability
results in a write access violation and can lead to remote code execution.
4. *Vulnerable packages*
&&&&& [1] execute calc.exe &&&&&
&&&&& [2] execute bindshell LPORT=7777 &&&&&
&&&&& ################################################################ &&&&&
&&&&& enter 2 &&&&&
&&&&& created !! &&&&&
&&&&& openit with dBpowerAMP &&&&&
&&&&& &&&&&
&&&&& G:\Documents and Settings\SimO>telnet 127.0.0.1 7777 &&&&&
&&&&& Microsoft Windows XP [version 5.1.2600] &&&&&
&&&&& Microso(C) Copyright 1985-2001 Microsoft Corp. &&&&&
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
A remotely exploitable vulnerability has been discovered in Microsoft Office Excel products. Specifically, the vulnerability is due to a design error encountered when parsing Excel files which contain malformed records. Remote attackers can exploit this vulnerability by enticing target users to open a malicious Excel file.
3. Vulnerability Analysis
A remote attacker can exploit the vulnerability by sending a malicious Excel file to the target system and enticing the target user to open it. A successful code execution attempt will result in the execution of arbitrary code within the security privileges of the currently logged in user. An unsuccessful attack attempt will result in abnormal termination of the Microsoft Office Excel application.
4. Vulnerability Detection
TELUS Security Labs has confirmed the vulnerability in:
III. ANALYSIS
Exploitation of this vulnerability allows the attacker to execute
arbitrary code with the privileges of the user opening the file. The
attacker will have to create a malicious PDF file and convince the
victim to open it. This can be accomplished by embedding the PDF file
into an IFRAME inside of a Web page, which will result in automatic
exploitation once the page is viewed. The file could also be e-mailed
as an attachment or placed on a file share. In these cases, a user
would have to manually open the file to trigger exploitation. If
preview is enable in Windows Explorer, this vulnerability can be
On Fri, Jul 8, 2011 at 4:11 PM, Mitja Kolsek
<mitja.kolsek@acrossecurity.com> wrote:
> Ok, Dan, just for you:
>
> Launch Internet Explorer 9 on Windows 7 (probably other IE/Win works too), go to File->Open (or press Ctrl+O), browse to Test.html and open it. No double-clicking and you couldn't launch an executable this way. Better?
>
> Cheers,
> Mitja
>
> On Jul 8, 2011, at 9:10 PM, Dan Kaminsky <dan@doxpara.com> wrote:
Ok, Dan, just for you:
Launch Internet Explorer 9 on Windows 7 (probably other IE/Win works too), go to File->Open (or press Ctrl+O), browse to Test.html and open it. No double-clicking and you couldn't launch an executable this way. Better?
Cheers,
Mitja
On Jul 8, 2011, at 9:10 PM, Dan Kaminsky <dan@doxpara.com> wrote:
> And here's where your exploit stops being one:
should still be fixed though. I'm not sure what the point of making
the files accessible via /proc is... It's good that open files are
*recorded* there, but making the contents accessible from there seems
unnecessary (and bad) to me, at least unless said access first
determines the canonical file system path to the file (i.e. the one
that the process used to open it), and checks the file access as it
would normally, using that path. Still, I doubt I'll ever see this on
any system I manage.
If it were possible for a different user who wasn't already accessing
the file to get access this way, that would be a very different
III. ANALYSIS
Exploitation of this vulnerability allows the attacker to execute
arbitrary code with the privileges of the user opening the file. The
attacker will have to create a malicious PDF file and convince the
victim to open it. This can be accomplished by embedding the PDF file
into an iframe inside of a Web page, which will result in automatic
exploitation once the page is viewed. The file could also be e-mailed
as an attachment or placed on a file share. In these cases, a user
would have to manually open the file to trigger exploitation.
RS> Exploitation method:
RS> Method 1:
RS> -Send POC with payload to user.
RS> -Social engineer victim to open it.
RS> Method 2:
RS> -Attacker creates a directory with long folder or
RS> filename in his FTP server (should be other than IIS
RS> server)
invalid length to the Swap4 function would reverse every DWORD in the
stack, both reversing SEH pointer near the bottom of the stack AND
causing an exception
An attacker can take full control of the machine where Luxology Modo
401 is installed by sending a specially crafted .LXO file and enticing
the user to open it.
4. *Vulnerable packages*
. Luxology Modo 401 - Windows
invalid length to the Swap4 function would reverse every DWORD in the
stack, both reversing SEH pointer near the bottom of the stack AND
causing an exception
An attacker can take full control of the machine where Luxology Modo
401 is installed by sending a specially crafted .LXO file and enticing
the user to open it.
4. *Vulnerable packages*
. Luxology Modo 401 - Windows
III. ANALYSIS
Exploitation of this vulnerability allows an attacker to execute
arbitrary code with the privileges of the user opening the file. The
attacker will have to create a malicious PDF file and convince the
victim to open it. This can be accomplished by embedding the PDF file
into an IFrame inside of a Web page, which will result in automatic
exploitation once the page is viewed. The file could also be e-mailed
as an attachment or placed on a file share. In these cases, a user
would have to manually open the file to trigger exploitation. If
preview is enabled in Windows Explorer, Acrobat will try to generate a
Exploitation method:
Method 1:
-Send POC with payload to user.
-Social engineer victim to open it.
Method 2:
-Attacker creates a directory with long folder or
filename in his FTP server (should be other than IIS
server)
As such (again, notwithstanding the mild interest around it) I'm confused by the "This was the response I expected" comment because if I read it right, it sounds as if you are being condemning for some reason. Are you saying "this is the response I expected" because it is the correct response and you are aware of what would be required to push out supported hotfixes for low impact issues, or are you saying "this is the response I expected" because you somehow think it SHOULD be hotfixed, but is not, and that is "typical" (as in "irresponsible") or something like that?
It actually brings up a question that I find more interesting than the issue itself, which is "how far is too far?" If MSFT designs a system around identifying files sourced from different zones in an attempt to mitigate risk of end-users downloading unknown content and immediately executing it, how far beyond user-acknowledgment and feature disabling (as even your "bypass" example shows) do you think a vendor is supposed to go (Not YOU, but the royal "you")?
I think it is a valid and applicable question. We have Apple seizing every opportunity they can to make user-acknowledgement for mitigation marketed as an actual Bad Thing, yet when a file downloaded from untrusted sources on the internet is marked as Internet Zone, and the user has to explicitly attempt to open it, and doing so generates a warning and they open it anyway, and for even then the "bypass" code doesn't even work, yet MSFT say they'll fix it in a service pack anyway, the entire issue you found gets reduced to "This was the response I expected."
The real issue here is that the more we criticize vendors for not Thinking For The User in Every Possible Circumstance, the more we see countries like AU thinking they will solve security issues by requiring AV and FW on every computer. If I posted that my Fedora box (if I had one) allowed me to do something like this, nix security people would attack me with religious furor. Yet the moment a left-handed, sideways, and round-the-back "issue" arises that really doesn't even work, and the vendor decides to fix it in schedule maintenance, it's still not "good enough."
If you (again, not you, but the industry) want to be able to criticize AU for being idiotic, then don't continually create an environment where the expectation is that the vendor will do every last bit of the thinking for the user, because you send the message that it is OK for .gov's to get in line after .com's draw it.
|
