SunJava 1.5.0_09 Released

Published: 2006-10-01
Last Updated: 2006-10-01 13:08:42 UTC
by Koon Yaw Tan (Version: 2)
0 comment(s)

One of reader shared with us that SunJava 1.5.0_09 has been released. You can get it from:

Java Runtime Environment (JRE) 5.0 Update 9
Release Notes
Test your installation

Update: As of Sun Oct 1 09:00:00 EDT 2006, neither the locally-installed, nor the on-line Java version tester seems to be aware of the 1.5.0_09 update. In one test, the on-line updated reported that 1.5_0_06 is the latest version. Also, Jim Manico reported that in his test, version 1.5_0_08 was reported as being up-to-date as well.



Perhaps the updater only detects major version changes? In this case, we saw no important security reason to rush with the 1.5_0_09 update. However, we hope that the update mechanism will work as advertised when an important security vulnerability needs to be patched.

(Original diary entry by Koon Tan; update by Lenny Zeltser)
Keywords:
0 comment(s)

*WebViewFolderIcon ActiveX control exploit(s) in the wild

Published: 2006-09-30
Last Updated: 2006-09-30 23:49:31 UTC
by Robert Danford (Version: 6)
0 comment(s)
Rise and shine. This vulnerability is being actively exploited in the wild.

Here is some preliminary info from the folks who got the jump on this at Exploit Prevention Labs.
http://explabs.blogspot.com/2006/09/webviewfoldericon-setslice-exploit-in_30.html

Mitigation:
On the client side "killbits" can be used to unregister the vulnerable control
See http://isc.sans.org/diary.php?storyid=1742 for more details.

On the network side it might be worth considering taking control of hostname lookups on your network through a technique like blackhole-dns: http://www.bleedingsnort.com/blackhole-dns/
The exploit URLs mentioned in the explabs blog have so many IP addresses behind them that blocking by IP or netblock becomes an uphill battle.

Update: I realize this is an incomplete suggestion if the hostname is unknown. However there are legitimate reasons to not release the full URL of easily portable/unpatched exploits. I do think it is still worthwhile for sites to consider reviewing their DNS logs and considering options such as blackhole-dns. In this case you'd just have to blackhole *.biz if the hostname is unknown.

More Info:
Advisory from Microsoft
MoBB #18
OSVDB(27110)
CERT(VU753044)

Updates will be posted here as they become available.
If anyone has information to share please do so via the contact link: http://isc.sans.org/contact.php
and indicate whether the info should be kept private or not.

Update:
The exploit is detected as:
JS/Exploit-BO.gen  by McAfee
JS_PLOIT.BC by TrendMicro
Bloodhound.Exploit.83 by Symantec

Background info on malicious ActiveX controls and killbits

0 comment(s)

Yellow: WebViewFolderIcon setslice exploit spreading

Published: 2006-10-01
Last Updated: 2006-10-01 21:57:25 UTC
by Swa Frantzen (Version: 5)
0 comment(s)

History

On Friday 29th (and for nearly all of our readers past their working day), we saw the WebViewFolderIcon setslice exploit spreading in the wild. We raise our Infocon to Yellow in order to increase the awareness of the problem and call for action. We have decided to stay Yellow till Monday morning for most of our readers. Without further spectacular evolutions we will go back to Green on Monday.

This exploit started in the Month of Browser Bugs on July the 18th as a Denial of Service, however its author released recently a code executing variant of it.

Reason for Yellow

The WebViewFolderIcon setslice exploit is becoming more widespread, so we changed the InfoCon level to yellow to emphasize the need to consider fixes.

If you have not taken measures yet, please consider some emergency fixes to cover the weekend. The exploit is widely known, easy to recreate, and used on more and more websites. The risk of getting hit is increasing significantly and the type of users of the exploit are also not the least dangerous ones. Some of the exploits are believed to be linked to CWS (CoolWebSearch), which is notoriously hard to remove.

Actions

We suggest following actions (do them all: a layered approach will work when one of the measures fails):
  • Update your antivirus software, make sure your vendor has protection for it (*).
  • Install following killbits (**):
{844F4806-E8A8-11d2-9652-00C04FC30871}
{E5DF9D10-3B52-11D1-83E8-00A0C90DC849}

make sure you set both.
You can do this manually as in the Microsoft security advisory, by using Tom Liston's tool, with a GPO, ...
  • Consider asking your users to stop their usage of MSIE, we know it's hard to break an addiction, but you're using the most targeted browser in the world.
We are aware of 3rd party patches, but our recommendation is to use the measures above instead for now.

Quote

Alex Sotirov from Determina on Full Disclosure: "We're also researching additional exploitation vectors. The underlying cause of the setSlice vulnerability is an integer overflow in COMCTL32.DLL, a core Windows component used by a large number of applications. The WebViewFolderIcon ActiveX control is most likely only one of the attack vectors for this vulnerability."

References


(*): It's important to note the difference of your antivirus solutions detecting the exploitation itself (very rare) and detecting the payload of known exploits (common). Only the first will offer real protection against new threats.
(**): There are currently no reports of side effects on other application when stopping this ActiveX control.


--
Swa Frantzen -- Section66
0 comment(s)

Setslice Killbit Apps

Published: 2006-09-30
Last Updated: 2006-09-30 15:17:50 UTC
by Tom Liston (Version: 4)
1 comment(s)
Well... here we are again...  seems like only last week, I was putting up killbit apps for "daxctle.ocx"... 

(and really, it was 10 days ago... sheesh, how time flies!)

Anyway, I've got two more for you, this time, setting the killbits on a couple versions of webvw.dll, and (as far as we can tell) shutting off access to the stuff that makes IE vulnerable to the "setslice" issue.  Note: we've tested these settings against the Metasploit project's test page, and they work.  Because MS hasn't released any information as of yet, we're sort of flying blind here...  However, that being said, the killbit method is great, because it is completely reversable.

There are two versions of the app, one a standard Windows program, the other a command-line version. 

The standard Windows app will tell you the status of the two killbits (ANDed together, for you programmer-types out there...) and give you the option to change them. (From SET to UN-SET, and vice versa...)

Standard Windows app: WEBVW.DLL_KillBit.exe - 2,560 bytes
MD5: f89b8896ed90f5387a57ed818294fe22

The command-line app will SET the killbits when run with no parameters, and UNSET them when run with any parameter (say "/r").  It will return 0 on success and 1 on failure.

Command line app: WEBVW.DLL_KillBit_cmd.exe - 3,548 bytes
MD5: ebc215850cd06b2de2d8e49428134271

UPDATE: Should anyone need to know, the CLSIDs that these apps are setting the killbit on are:

{844F4806-E8A8-11d2-9652-00C04FC30871} and
{E5DF9D10-3B52-11D1-83E8-00A0C90DC849}

(Thanks to Mark for pointing out that I forgot to put that in the diary entry...)

Tom Liston - ISC Handler
Senior Security Consultant - Intelguardians

New diary link: http://isc.sans.org/diary.php?storyid=1747

Keywords: killbit setslice
1 comment(s)

Comments


Diary Archives