Microsoft: July 2005 Archives
Techweb has an article (which they repeat on their SecurityPipeline website) regarding Trojan.Jevproxy. They say that this is a trojan horse exploiting a still unpatched vulnerability in Microsoft Windows.
However MS05-036, Microsoft's security bulletin for this vulnerability says in the executive summary, "this is the fix."
Who is right?
SANS @RISK is a bulletin summarizing recent vulnerabilities and recommendations/actions taken by unnamed member companies. Their text related to the javaprxy.dll exploit follows. It sounds like one company has a default stance to disallow activeX from running in IE and others are just waiting on the real patch which will hopefully come out on Tuesday.
__
Description: An exploit for the Internet Explorer flaw discussed in last
week's issue of @RISK, has been publicly posted. The flaw was rated
"LOW" last week because the discoverer reported that Microsoft team
could not reproduce the flaw at that time. Microsoft has now issued an
advisory for this vulnerability. The advisory also lists workarounds on
how to disable the javaprxy.dll COM object and how to prevent this
object from running in Internet Explorer. Note that even if javaprxy.dll
is not installed on a user's machine, an attacker can force its download
via the "codebase" attribute while instantiating this object.
Council Site Actions: Several of the council sites are still reviewing
the workarounds from Microsoft and waiting to see if a specific patch
for this problem is released next Tuesday. One site commented that
their default configuration for IE included the recommended patches and
workarounds. Another site has a large number of vulnerable systems,
about 12,000. In some cases, the end users are manually visiting the
Microsoft Download Center to obtain the registry update that disables
javaprxy.dll. They have not yet made an attempt to roll out this
registry update on a widespread basis, and have not yet sent a general
announcement to Windows users about the vulnerability. At a minimum, the
great majority of their systems will obtain an update through the public
Windows Update site, or through their local SUS server, whenever
Microsoft happens to release a patch for this.
Symantec finally got detected the exploit file I created over the weekend for javaprxy.dll. They are calling it bloodhound.exploit.40. http://www.symantec.com/avcenter/venc/data/bloodhound.exploit.40.html They don’t think its in the wild either. Note that although the 7/7 rev 17 defs will detect this, it will not necessarily keep the exploit from occuring. It does help keep any webserver clean that is running antivirus.
Of course with attackers shifting towards more targeted models, they wont be noticed as quickly. A while back my webhosting provider got hacked and 10,000 sites had a iframe added that loaded malicious code. The vulnerability was 9 months old so I was well patched. Imagine if they were able to hack my web provider again and use this newer exploit to install spyware or bots. While it wouldn't make the news since its doesn't effect Microsoft, Yahoo or Ebay, it would still infect an impressive number of computers.
You dont just need to worry about malicious websites. Sites that you trust can be made to serve up viruses if the server is compromised. You wont necessarily hear about it in the news or from the ISC if it only effects a small group of people. Take the mitigating steps that Microsoft recommends. Hopefully the real patch will be available on Tuesday, but why wait until then to have a measure of protection.
Microsoft put out a bulletin last week warning of a denial of service in javaprxy.dll (part of the Microsoft JVM). Exploit code has been posted to the Internet which show that this vulnerability is more than a denial of service, it can allow an attack to run code in the context of the logged on user.
Microsoft has posted several mitigating steps at http://www.microsoft.com/technet/security/advisory/903144.mspx. The easiest such step is to set the activeX kill bit. With this method you dont have to worry about loss of functionality in other applications which use the MS JVM. The downside is that from my testing the denial of service exploit still occurs (memory usage) although it does not allow the malicious code to run.
Check out the MS article for other mitigation techniques.
