request.headers['User-agent'] is incorrect, it should be
request.headers['User-Agent'].
Downloaded following version from oldapps.com to confirm
the exploit code is wrong.
Supported Systems Windows 98, 2000 (Maxthon 2.5.15 Build
1000), XP, Vista, 7, 8
MD5 Checksum F3791637C886A46940876211209F82F4
SHA1 Checksum 039BB218245E5DC1BAB0F57298C68AC487F86323
Release Date 20 October, 2011 (2 years ago )
[] is character class, and will match on 1, 6, 7, and |.
Where as (16|17) will match on either 16, or 17.
irb(main):053:0> y = /Firefox\/3\.6\.[16|17]/
=> /Firefox\/3\.6\.[16|17]/
irb(main):054:0> x = "Firefox/3.6.13"
=> "Firefox/3.6.13"
irb(main):055:0> x =~ y
=> 0
irb(main):056:0> y = /Firefox\/3\.6\.(16|17)/
=> /Firefox\/3\.6\.(16|17)/
irb(main):057:0> x =~ y
=> nil
resource_uri will randomize the returned uri unless
datastore['URIPATH"] is set.
get_resource will return the currently used reosurce_uri
Since the incorrect type is used, this exploit is completely broken.
Tested fix with both URIPATH set to / and unset, and it works after
redirect.
This module exploits a vulnerability found in Synactis' PDF In-The-Box ActiveX
component, specifically PDF_IN_1.ocx. When a long string of data is given
to the ConnectToSynactis function, which is meant to be used for the ldCmdLine
argument of a WinExec call, a strcpy routine can end up overwriting a TRegistry
class pointer saved on the stack, and results in arbitrary code execution under the
context of the user.
While updating ie_cgenericelement_uaf earlier today, I noticed the
changes made it a tiny bit less stable. Juan's test log in #1809
also kinda shows that (with the first attempt failing), so I decided
to go back and move the string crafting part, that way between
CollectGarbage() and the overwrite, there is less noise, and hopefully
more stable. I did a few tests, seems better.
sinn3r