Last Updated: 2006-10-01 13:08:42 UTC
by Koon Yaw Tan (Version: 2)
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
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)
Last Updated: 2006-09-30 23:49:31 UTC
by Robert Danford (Version: 6)
Here is some preliminary info from the folks who got the jump on this at Exploit Prevention Labs.
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.
Advisory from Microsoft
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.
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
Last Updated: 2006-10-01 21:57:25 UTC
by Swa Frantzen (Version: 5)
HistoryOn 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 YellowThe 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.
ActionsWe 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 (**):
- 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.
QuoteAlex 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."
- Jesper's blog about setting killbit using group policy (GPO)
- Exploit prevention labs blog entry - iframe
- Exploit Prevention labs blog entry - CWS
- F-Secure blog
- JS/Exploit-BO.gen (McAfee)
- JS_PLOIT.BC (TrendMicro)
- Bloodhound.Exploit.83 (Symantec)
- Exploit.HTML.IESlice.a - Exploit.HTML.IESlice.c (Kaspersky)
- JS.CVE-2006-3730!exploit (CA)
(*): 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
Last Updated: 2006-09-30 15:17:50 UTC
by Tom Liston (Version: 4)
(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
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
UPDATE: Should anyone need to know, the CLSIDs that these apps are setting the killbit on are:
(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