Not signed in (Sign In)
    • CommentTimeAug 24th 2010 edited
    True so far as that goes, but that only addresses the delivery vector, not the actual architectural issue in question. The actual exploit to take advantage of the vulnerability is fairly difficult to pull off*, so there's a higher barrier to overcome, but the payoff is total system compromise.

    This can be usefully contrasted with the Stuxnet/SCADA vulnerability that recently resulted in an emergency Microsoft patch (Aug 2nd, kb2286198) - the vulnerability in that case was easily exploited by merely viewing an infected PDF or website hosting the malicious code and required no action on the user's part at all, and also led to total system compromise. However, the weakness there was just a classic buffer overflow in a particular system library, and thus easily patched.

    What is alarming about this exploit is that all of the solutions so far are either a) work-arounds that merely avoid the vulnerability, or b) require developers to totally rewrite their code to avoid it. The vulnerability itself has been known of for a while, and Microsoft had been quietly encouraging application developers to adopt more secure coding practices, but it simply hasn't happened fast enough, and may in fact not be able to be totally eliminated without significant system rearchitecture. So rather than being widespread and easily exploited from a distance, this is narrow but deep - think of the flaw in the Death Star as the best nerdy analogy.

    SANS hasn't raised their threat level, so there's no immediate widespread thread of this exploding the entire Internet, but it is a serious long-term problem potentially requiring an effort on the level of Y2K to fix. They continue to update their diary here.

    * Actually, I overstated that a bit per the latest SANS update:
    We received some e-mails about active exploitation of this vulnerability in the wild. While there are potentially hundreds, if not thousands of applications that are vulnerable, it appears that the attackers so far are exploiting uTorrent, Microsoft Office and Windows Mail, which are, coincidentally or not, applications for which Proof of Concept exploits have been published. Remember, it is extremely easy to exploit this and it doesn't require any advanced knowledge so be sure to check Microsoft's recommendation above or be very careful about files you open from network shares.
    • CommentAuthorFan
    • CommentTimeAug 24th 2010
    > it is a serious long-term problem potentially requiring an effort on the level of Y2K to fix

    I don't think so.

    It's easy for a programming tool to find the lines of code which may need fixing (if developers want to fix their code, which MS developers at least probably do).

    The fix is easy (e.g. to specify a fully-qualified path when you invoke the LoadLibrary function).

    Perhaps the O/S could fix it too (e.g. say that network shares are, by default, for sharing data files not for sharing executables; or by creating a safer version of LoadLibrary, which doesn't add the current directory to the PATH).

    It can't happen unless users are wanton (attach to untrusted drives) or security is already breached (trojans placed on trusted drives); at home I never attach to anything (except to my office via remote access), and at work I only attach to in-office drives (which are within the office firewall, and for which the office sysadmins are responsible).

    I agree that it's game over if untrusted code is ever run: and that attaching to a network drive is dangerous, if that drive contains viruses. But apart from migrating all applications to .NET (which supports the notion of fine-grained permissions, and of "trust" based on where the code is loaded from), which would be a big effort and which won't sfaik happen anytime soon, the current O/S and applications are secure enough, for most people.
    • CommentTimeAug 26th 2010 edited
    Fan -

    The discussion amongst system admins and security types is a bit more pessimisstic. From a programmer's point of view it is an easy fix. From a sysadmin's point of view, see below for a sample:

    Waiting for a list of programs which are or are not vulnerable is
    not a good way to approach this problem. The assumption should be
    that any given executable is vulnerable. Don't even bother trying to
    identify executables which call SetDllDirectory; there's still the
    question of whether it is called correctly or consistently.

    The default behavior of the system is broken. We cannot expect any
    programmers to actually implement the obscure feature which changes
    the default behavior. Expecting vendors to do so is not realistic. A
    huge number of Microsoft's own executables do not implement the
    setting and attempt to load optional DLLs. If Microsoft can't get
    their own code to do it, expecting others to do so is unrealistic.
    Assume everything is vulnerable.

    My suggestion would be: Deploy the update in MSKB 2264107.
    Configure CWDIllegalInDllSearch to remove the current directory from
    the search path by default system-wide. Identify any programs which
    stop working and make executable-specific exceptions to
    CWDIllegalInDllSearch for them. Contact vendors of those applications
    for updates (good luck with that!).

    Ideally, use Software Restriction Policies/AppLocker to limit
    loading of DLLs from trusted locations only.

    I manage about 250 customers with 1500 seats. We have hundreds of applications to try to help our clients attempt to patch and secure. While a programmer may just have to change a couple lines of code, what happens after that is significant. Y2K was a matter of a couple of bits, after all.