Software Deployment

Yes but the hacker has to come in on an attack vector that will exploit the hole. The GDI exploit is a good one. If you use the MS patch you will be ok with the MS applications you patched but if you have an application that uses an isolated version of the GDI.DLL then if that application opens an infected file you will be compromised.

Correct. I worked with this a lot back when MS04-028 was release. This critical patch was for the GDIplus.dll (deals with image handling) and allowed for remote execution of code. MS released a patch for each of the applications, which was nearly all of them, that use this DLL and stated that other vendors use this file and they "should be releasing updates in the near future." A noteworth example of one of these other vendors is Adobe.

Adobe never released a patch to fix this file, so the vulnerability still existed on every machine in the company.


Kind of puts thing in perspective, don't you think?




EDIT: heh, guess kkaminsk beat me to it.

This is why tools like software/file inventory in SMS are good. You know exactly what files are located on which computers in your enterprise.

Yeah, I may want to rethink my isolation strategy. From the security patch aspect, it seems that isolation is no longer a really good thing. I may end up needing to produce a patch for many, many applications. Maybe instead of focusing on isolating applications, I should be more concerned with replacing back level components with current versions and keep them in System32 to make them updatable by whatever patch may come along!

Uff da! Talk about having your packaging strategy blindsided!

We have CA's AMO/SDO for inventory/deployment. It helps, but ultimately all it really does is let you know exactly how screwed you are. [:(]

I wouldn't lose too much sleep over it. Your time would be much better spent locking down your environment rather than tracking every DLL that Microsoft ever patched. Lock down local permissions, remove add access to sectors of the registry, etc etc.

That was the ultimate conclusion that we came to back in the days of GDIplus. The majority of the risk is to machines where users are Local Admins, and we had 98% of the users running as standard users.

Normally I'd agree, but we are in the Health industry and have federal regulations to worry about. If someone should abscond with anyone's personal health information, a traceable audit trail of patching every security hole is the company's only defense against buku big fines. You should see what we go through just to prohibit the use of rogue USB memory sticks & drives while still permitting authorized USB devices.

Yup, I gotta patch EVERYTHING... even if it's just a dog & pony show for an auditor.

[:)] Who want's to be me?!?! [:)]

How do you do your deployments? And why are you not using SMS? It would seem like the tool of choice in the event that you need to print out a 300 page report to satisfy your typical harda$$ auditor.

Isn't gdiplus.dll an OS file? Does it come with XP?

If is does then you wouldn't be delivering that file isolated would you?

We don't deliver any files to System32 at all except the OS and Office versions. So we patch both of those.

Hello Group,

Please give me your comments on the following

I need to know what are the disadvantages of Isolation.

Is it really worth isolating every product that you package. how much of a trade off it is between compromising security and value it brings to the organization

According to MSIMAKER they do isolatate all the products they package excluding Microsoft OS and Office Dll's.

How about MDAC and .Net dll's ?

Correct me if I am wrong...most of the time the the common dll's belong to either OS, Office, MDAc or .Net (mainly microsoft components) which are subject to patches by microsoft.

Thanks

I should clarify this I suppose.

With MS vendor applications we do not change them. We create mst's for them These would include dotnet framework, Office, Project etc.

With any other vendor msi's that attempt to update SYSTEM files in system32, we would repackage the app or isolate the dll's being installed.

This is not something that most businesses would attempt but because of our environment we MUST be sure of what version the system32 files are at all times. We have many legacy apps that have dependencies on certain versions and also some custom versions supplied by MS for us.

Some vendor msi's are not well written and will throw new dll's in willy nilly, so we take no chances as it might cause a problem for our 30,000 users. When you get to this size of enterprise there is no second chances and mistakes have to be kept to a minimum.