Jump to content

Recommended Posts

Posted
Well disabling Active Scripting is a pain. Chances are Microsoft will release a patch early anyway. In the meantime I would recommend you apply the latest IE patch, that also fixes something like 27 bugs (apparently).
Posted

We're looking at disabling oledb32 temporarily via group policy or maybe zapping the registry key they mention in the advisory (to clobber "XML Island functionality"). Not sure what the impact will be yet... virtual machines are go!

 

Anyone tried SIMS/FMS/MSAccess after any of these workarounds?

Posted

Tony: things should be being caught as of last week.

Not sure (as we only have PoC) how many "wild" exploits it will catch, but I would be happier with the rule than without.

 

Those of you with "recommended security" rules on will be running it already.

  • Thanks 4
Posted (edited)

Well they aren't making a fix, they're doing a day-to-day update to their product's most fundamental function. By their own admission the fix is far from watertight so I'd be very wary of relying on it. I would be much happier with a client-side fix for this than hoping the smoothwall rules are accurate enough and stay accurate as variants emerge. (This is not a dig at smoothwall who are obviously doing what they can)

 

From some experimentation with this demo of "XML island" functionality (which has nothing to do with the exploit code) it seems that putting a deny entry on the following registry key breaks the link between IE6 and MSXML3.dll:

 

HKEY_CLASSES_ROOT\CLSID\{379E501F-B231-11D1-ADC1-00805FC752D8}

 

I can't see why the Microsoft Advisory is suggesting people empty the contents of that key and subkeys instead of just setting an ACL entry. I suspect it's going to be a fair bit easier to remove that deny entry via GPO than to reconstruct a bunch of registry keys reliably.

 

@Tom: There are some screenshots of a malicious version on the websense blog which it would be interesting to compare with your filter to see if it would pick it up:

 

http://securitylabs.websense.com/content/Blogs/3263.aspx

Edited by sahmeepee
stupid timeouts
  • Thanks 1
Posted

I've had a good look at the Advisory and I think unregistering and then registering OLEDB32.DLL (when Microsoft release a patch), is the easiest option.

 

Unregister:

Regsvr32.exe /u "%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll"

 

Register:

Regsvr32.exe "%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll"

 

I'm not going to implement the fix on admin workstations or servers, as I am pretty positive this will stop SQL related services such as SIMS, CMIS or of course WSUS from running (not good).

 

If only the end of term was tomorrow then I could forget about it and just turn all machines off over the Christmas period!

Posted

Well we tried disabling that on a virtual PC, but unfortunately it reliably kills mail merges (between word and excel) and probably anything else of that nature. SIMS itself ran fine although we didn't test any report generation etc.

 

The XML data island fix is much less likely to break stuff so I'm going with that on our admin and classroom PCs until this out-of-band patch comes out tomorrow and we get it deployed everywhere:

 

Microsoft Security Bulletin Advance Notification for December 2008

 

Using web browsers on servers is even more wrong than normal at the moment!

Posted

I just conducted a quick experiment on one of my SQL Servers. Using the above method of unregistering OLEDB32.DLL, I then attempted to run Sims.NET and FMS in turn and both work fine :) I could logon, which would indicate database functionality is normal.

 

And speaking of databases, SQL 2005 SP3 has been released. Something for the new year I think!

Posted

As a quick update, I disabled the XML island stuff overnight and now Outlook Web Access is pretty much borked! It seems it's needed for replies and setting high importance and possibly for sending mails at all. Not good. Luckily reverting the setting is quite easy.

 

So thus far I've not found a suitable fix. Let's hope the patch comes quickly!

Posted

For reference, Symantec, Avast! and Sophos all detect the malicious code and succesfully block attempts on it running.

 

IE7 Zero Day Technical Analysis - Security Labs Blog - Type the XML / SPAN lines into a webpage, whack it on your local webserver, visit it from one of your machines then check the AV logs and see if it's caught and killed the page - they should all pick it up via heuristic detection.

 

Yes, the hole is there in IE, but yes, most decent AV systems are already catching and halting it.

Posted

I have been thankful that we broke up last Friday and I've only had the office staff to contend with. I disabled the internet for others just in case they came in (unlikely) and put the fear of [insert deity of choice] up the office staff. Fortunately, they're very well-behaved normally. We seem to have mutual respect based on unreasonable requests... I listen to their rants behind a closed door and they listen to mine :) Hopefully, all will be well. I'll be in first thing tomorrow to apply the patch!

 

Until then, fingers remain crossed

Posted

Will the patch be available as an admin installion patch ie something to download and for me to run round school tomorrow and install it manually on staff laptops?

 

Whats everyone done so far?

Posted

The patch is spurting forth from my WSUS server right now. Not sure when it was issued, but sync your server and it should appear.

 

Separate patches for IE6 and IE7. Not sure if they've released a patch for IE5.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...