SunJava 1.5.0_09 Released
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
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)
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
Yellow: WebViewFolderIcon setslice exploit spreading
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}
{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, ...
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.
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
- Jesper's blog about setting killbit using group policy (GPO)
- Exploit prevention labs blog entry - iframe
- Exploit Prevention labs blog entry - CWS
- SunbeltBlog
- F-Secure blog
- Malicious ActiveX Controls (Oreilly)
- Setting killbits (Microsoft - KB240797)
- Snort VRT sigs: SID 7985 and SID 7986, available since September 1st.
- 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)
- Sept. 30th diary
- Sept. 29th diary with tool to set the killbits
- Sept. 28th diary
(*): 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
Setslice Killbit Apps
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
1 comment(s)
(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
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments