Welcome, Guest

• Forgot your password?
• Apply for membership

1. •  
     CommentAuthorFinagle
   • CommentTimeAug 24th 2010 edited

    (8209.21)
   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.

2. • CommentAuthorFan
   • CommentTimeAug 24th 2010

    (8209.22)
   > 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.
3. •  
     CommentAuthorFinagle
   • CommentTimeAug 26th 2010 edited

    (8209.23)
   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.