Threat Level: green Handler on Duty: Manuel Humberto Santander Pelaez

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

MSIE DirectAnimation ActiveX 0-day update

Published: 2006-09-15
Last Updated: 2006-09-20 17:44:59 UTC
by Swa Frantzen (Version: 4)
0 comment(s)
Microsoft released a security advisory regarding the 0-day we reported on earlier.

Timeline:
Workarounds:
Please note that windowsupdate needs an ActiveX enabled browser, but you can do that with settings to the security zones and trusting Microsoft.

Please not that the outlook family is affected as well but that the default settings will typically mitigate much of the risk. That is as long as nobody or nothing has modified the settings ...

With thanks to the readers writing in to remind us and keep the details right.

Update #1

Snort VRT Rule #8053 catches this vulnerability.  The rules are available at
http://www.snort.org/rules.  Sourcefire released rules for this vulnerability on September 1st.

--
Swa Frantzen -- Section 66
0 comment(s)

Killbit apps for current IE exploit

Published: 2006-09-18
Last Updated: 2006-09-18 14:19:45 UTC
by Tom Liston (Version: 2)
0 comment(s)
Update: I posted this late on Friday (9/15) evening, so I wanted to pull it back onto the front page again.  This looks to me like a perfect avenue for malware drive-bys, and with the likelihood being that this won't be addressed until the next MS monthly patch cycle (gee... who would EVER have thought that the bad guys would start timing THEIR releases to maximize exposure until the next patch-day?!?) we're probably going to be seeing a whole lot of this stuff:

To make life a little easier, I put together two small apps to set and unset the appropriate "kill bit" to block the actions of the current "daxctle.ocx" IE exploit.  They can be found here:

http://handlers.sans.org/tliston/DAXCTLE.OCX_KillBit.exe  - Standard Windows executable
(MD5: 599a2e48602f63a5330eea8259216584)

http://handlers.sans.org/tliston/DAXCTLE.OCX_KillBit_cmd.exe - Command line version
(MD5: 571a19cf51f713b81545ebd6a007d792)

The command line version, when run without any parameters, will set the "kill bit".  When run with any parameter (i.e. something like "/r"), will remove the "kill bit."

The standard Windows executable, when run, will tell you the current status of the kill bit and offer you the option of changing it.

Hope these help...

--------------------------------------------------------------------------
Tom Liston
ISC Handler
Senior Security Analyst - Intelguardians (http://www.intelguardians.com)

Keywords:
0 comment(s)

Snort rule update

Published: 2006-09-15
Last Updated: 2006-09-16 03:07:38 UTC
by Joel Esler (Version: 1)
0 comment(s)
Sourcefire's VRT has published rules to catch attacks targeting the following vulnerabilities:

Microsoft Security Bulletin MS06-054 Microsoft Publisher
Microsoft Security Bulletin MS06-053 Microsoft Indexing Service
Microsoft Security Bulletin MS06-008 Microsoft Web Client Service (Webdav)
Microsoft Security Bulletin MS06-007 The Microsoft Windows Operating system suffers from a Denial of Service (DoS) condition that is present when handling malformed IGMPv3 data

Also Snort 2.6.0.2 was published today that includes a new DNS preprocessor that will catch:
Microsoft Security Bulletin MS06-041 The Microsoft Windows DNS Client

Get your fresh Snort rule updates here.  For complete information about the rule pack, please go here.  Finally, to download Snort 2.6.0.2, go here.

Update #1
-------------------------------------------------------------------------------------------
Joel Esler, from 35,000ft in the air, has added a note to this story, and that is...

The above listed rules, available from Sourcefire, are subscription only at this time.  After a period of time they will be available to the public, for free.

For Joel Esler,

Tony Carothers
Handler on Duty

Keywords:
0 comment(s)

PHP - shared hosters, take note.

Published: 2006-09-15
Last Updated: 2006-09-15 16:32:04 UTC
by Swa Frantzen (Version: 4)
0 comment(s)
PHP is a popular server side scripting language.

PHP's (security) settings are typically controlled from a php.ini file. This allows the system administrator to control settings such as such as safe_mode and open_basedir.

People managing shared hosting machines often control the settings on a more granular level in the apache configuration (httpd.conf) as they can set it there per directory and allow for the different hosted sites to have different settings.

This latter method of limiting scripts can be overcome from inside the scripts themselves. Details are trivially available.

So that leaves:
  • Control PHP settings from the php.ini file if possible;
  • If you are a shared hosting provider: check the CVS repository, reportedly the needed fixes have been checked in (unconfirmed);
  • Cross your fingers and wait for the next release of PHP (the current releases are reportedly affected).
CVE-2006-4625

update:

Stefan Esser from the hardened php project wrote in with a quick workaround: add "ini_restore" to the list of disabled functions in php.ini:                                                                              
disable_functions=...,ini_restore 
This is much easier than trying to find the fix in the source code till the next release of PHP.

While at it: those hardening scripts available at the hardened-php site should really be applied in a hosting situation. They protect against this vulnerability already. And perhaps a close look for the beta "suhosin" would not be a bad idea either.

If you are interested in securing PHP, you might also be interested in the PHP 6 comments and the Tip of the Day on php from Johannes.

update:

Steve wrote in to suggest that -in addition to disabling ini_restore- you might want to look at disabling ini_set as well.

--
Swa Frantzen -- Section 66 
0 comment(s)

Get your fresh Firefox updates

Published: 2006-09-15
Last Updated: 2006-09-15 12:59:19 UTC
by Joel Esler (Version: 2)
0 comment(s)
My Firefox just jumped up at me and said "You have some updates".

Version 1.5.0.7 to be exact.  So what's new?  Well, Mozilla tells us over here.

MFSA 2006-64 (which, by the way, stands for Mozilla Foundation Security Advisory) -- "Crashes with evidence of memory corruption"
Looks like a memory corruption bug.
Mozilla says, "...we presume that at least some of these [bugs] could be exploited to run arbitrary code with enough effort."  So, get your patches!

MFSA 2006-62 -- Popup-blocker cross-site scripting (XSS)
More XSS stuff, except this time against the Popup-blocker feature.  Mozilla doesn't really view this as a big threat: "The malicious page would first have to get itself framed by the target page, attempt to open a popup, and then convince the user that the popup contents were so important or interesting that it must be opened manually."

MFSA 2006-61 -- Frame spoofing using document.open()
This vulnerability is kind of a reshash of this one.  "The victim site must first be opened in a new window (or tab) by the malicious site for this flaw to work."  Basically, be wary of any sites or windows, not opened by you.

MFSA 2006-60 -- RSA Signature Forgery
Looks like Philip Mackenzie and Marius Schilder over at Google found this one. 
"Because the set of root Certificate Authorities that ship with Mozilla clients contain some with an exponent of 3 it was possible to make up certificates, such as SSL/TLS and email certificates, that were not detected as invalid. This raised the possibility of the sort of Man-in-the-Middle attacks SSL/TLS was invented to prevent."
Good, I read about this one not too long ago on a couple mailing lists that I lurk on.

MFSA 2006-59 -- Concurrency-related vulnerability
Mozilla has this to say: "We have seen no demonstration that these crashes could be reliably exploited, but they do show evidence of memory corruption so we presume they could be."

MFSA 2006-58 -- Auto-Update compromise through DNS and SSL spoofing
DNS and SSL spoofing vulnerability.  Mozilla does offer some good advice on this one:
"Do not accept unverifiable (often self-signed) certificates as valid. If you must, accept them for the session only, never permanently."  Rule of thumb.

MFSA 2006-57 -- JavaScript Regular Expression Heap Corruption
"...a regular expression that ends with a backslash inside an unterminated character set (e.g. "[\\") will cause the regular epression engine to read beyond the end of the buffer, possibly leading to a crash." 

... and since Thunderbird uses the same browser engine as Firefox, you need to update it too!

Thunderbird update can be found here.
Firefoxes update can be found here.

OR!!!  (and better IMO), you can click on Help (in the title bar), and click on "Check for Updates...", and the program will update itself.  (At least that's where it is on my Mac)

Happy updating!

(ISC would like to thank Jack, Robert, Juha-Matti, and Brian for emailing us to let us know..  and in case you were wondering, Brian emailed us first.  He wins!)

I'd like to thank Sergio for pointing out that I missed #61.  Thanks Sergio.

Keywords:
0 comment(s)

Adaware corrects their false positives

Published: 2006-09-15
Last Updated: 2006-09-15 01:05:09 UTC
by Joel Esler (Version: 1)
0 comment(s)
Robert writes in to tell us that Lavasoft has corrected the problem they had with Adaware dishing out a few false positives.

Seems like if you update to the newest detection file, you should be fine.  Check out the thread here.

A reader named Jim did write in and tell us about the error, thanks Jim.  He told us.. "Following the registry to the executable file reference, I find a MSINET.OCX in the windows system32 directory which was digitally signed by Microsoft in 2000."

As a quick reminder, anyone who wishes to contact the ISC may do so by clicking "Contact" at the bottom right of the page, or clicking on the "Handler of the Day"'s name at the top of the screen.
Keywords:
0 comment(s)
Diary Archives