How do I rate today’s patches?

Initial impressions… “Holy crap!”


That’s a lot of reading.


06-040 – install this sucker unless you block the usual RPC ports internally and externally.


06-041 – install this unless you never use DNS to external servers, or can apply the workarounds.


06-042 – install this on any machine that runs Internet Explorer. Then install it on the ones that don’t yet.


06-043 – if you use OE6, install it. What the heck, it doesn’t cause a restart, so (make sure you’re not running OE6 right now, and then) install it anyway.


06-044 – install on any machine that runs Internet Explorer – see 06-042.


06-045 – install on any machine – don’t be fooled by the “Important” rating, derived from the requirement that a user must click on an email or attachment or web page – users click on anything.


06-046 – install this. HTML Help is everywhere (thanks, Microsoft!)


06-047 – install this if you use Office, or anything that runs VBA.


06-048 – install this if you use Powerpoint.


06-049 – install this if your users are really sneaky and horrible. Do you trust your users?


06-050 – install this – it’s all about protecting against users clicking on hyperlinks. see 06-049.


06-051 – install this.

5 Responses to How do I rate today’s patches?

  • Richard says:

    Worth noting that -044 and -049 and Win2k only. -047 only impacts VBA SDK and Office 2k & XP.

    Still a huge pile this month.

  • Robert says:

    …And when will Microsoft finally figure out how Microsoft patches can be applied without requiring a reboot?

  • alunj says:

    It’s very easy to ask that question, but the answer is more complicated.
    Any time you patch a component – a DLL, or an EXE, or a system configuration file – that is in use, you have to figure out what you’re going to do with the applications still using the component.
    If it’s a DLL, you’ve got the likelihood that it is being shared by several processes, and maybe even that the DLL is using shared memory and variables to communicate between instances.
    If that’s the case, then simply replacing the DLL without rebooting means that you’ll now have two versions of the same DLL competing with one another as to which is the ‘real’ one.
    Let’s choose the clipboard as an example.
    Say you patched the clipboard DLL, and segmented the two versions so that they can’t share memory.
    Now, you copy something in an application that was open when you applied the patch, you go to another application that was open after you applied the patch, and you hit “paste” – nothing happens, or it pastes some content that isn’t the content you copied, because the two versions of the DLL aren’t sharing the same memory.
    Of course, the alternative would be to not segment the memory, so that both old and new versions are running with access to the same data.
    That’s too scary to contemplate – if you think buffer overflow attacks are a bad thing, just think what happens if you have two programs accessing the same memory, but one program thinks its data size is half that of the other. Buffer overflows are just the start – there’s also the possibility of a different initialisation, or different meanings of certain values within variables.
    So, to install a patch, you really have to wait until a moment when nobody is using the file that you’re going to patch.
    Reboot is the safest time to do that.
    Obviously, it can be done better – you could list all the processes that have the files open that you want to patch, and ask the user to close them all (or force them closed for yourself). But then you have the user education issue of “I’ve just been told that MSIMN.EXE has this DLL open – what application do I close?”

  • Richard says:

    > Any time you patch a component – a DLL, or an EXE, or a system configuration file – that is in use

    One additional issue to consider, if the DLL is loaded into a long running process (e.g. a service) and you don’t reboot. Then the vulnerability will continue to exist in memory. While patches, the computer could still fall to the same attack.

  • alunj says:

    Absolutely – my long post above only scratched the surface of the problems that Microsoft (and other patching vendors) face when they try to deploy a patch without rebooting.
    Vista has some improvements in this area – notably, it will prompt to close applications and save files to prevent the requirement of a reboot.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>