Re: Notepad popups in Internet Explorer and Outlook

From: Russ (Russ.Cooper_at_RC.ON.CA)
Date: 08/06/03

  • Next message: Jeffrey Thomas: "reports of DCOM worm on the loose...still waiting on MS for DOS patch for W2K w/ MS03-026 applied" 
    Date:         Wed, 6 Aug 2003 11:29:40 -0400
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

    This topic of EditFlags and its implications was covered extensively in the middle of 1999 on NTBugtraq;

    http://www.ntbugtraq.com/archives

    On July 29th, 1999, Juan Cuartango discovered an ODBC vulnerability and announced it to NTBugtraq. It automatically invoked a malicious Excel spread***.

    On July 30th, 1999, Jeff Johnson provided the technical details about the EditFlags registry value (citing Woody's Office Watch) and how it could be set to prompt for saving instead of automatic execution.

    On August 2nd, Jimmy Guse released a tool (including source) which allows anyone to determine the EditFlags existing in your registry, their value, and the ability to modify the value from the command line. It is available at;

    http://www.ntbugtraq.com/office97fix.asp

    On August 6th, 1999, Microsoft released the Document Open Confirmation Tool, a GUI that does some of what Jimmy's tool did;

    http://support.microsoft.com/default.aspx?scid=kb;en-us;238918

    MS99-030 was created to resolve the original ODBC issue but does nothing to address the EditFlags issue.

    All that said, in early 2001 I tried to develop a tool which would handle the MIME mismatch vulnerability addressed by MS01-020 (probably the most widely exploited vulnerability found.) The premise was simple, if we could modify the EditFlags value for all unsafe MIME types, we could prevent exploitation of the mismatch. So we tried, and asked Microsoft for details, and tried again. Originally, they felt our approach was realistic, it should've worked according to the documentation.

    Problem is, many Microsoft products totally ignore the EditFlags values for some file types. This includes Outlook, IE, Word, and others. We looked at the OutlookEditFlags registry value, but were then told it was depreciated and no longer used. We looked at the FTA_AlwaysUnsafe bit, coincidentally part of the EditFlags value of some CLSIDs. This led us to understand that EditFlags can be a DWORD or a BINARY, which totally altered the idea that EditFlags was a single source answer to the problem.

    See;

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fileassoc.asp

    for full details of EditFlags as a BINARY.

    We tried to find out what used it as a DWORD and what as a BINARY. No such luck. We tried to find out what even looked at or for the value. In our testing we discovered numerous examples of programs that never bothered to even look at, or for, EditFlags. If that wasn't depressing enough, we realized that 3rd parties may or may not have implemented checks of that key (in either form) also.

    In the end we tossed the whole idea because it was impossible for it to be a reliable mechanism for ensuring anything.

    A better approach, which we never pursued, was to create a single application which could be invoked by any Asynchronous Pluggable Protocol Handler in-stream. It could deal with the MIME blob as a stream and take whatever action it wanted to (including modifying the MIME type, dropping the data, or whatever else was desired.)

    Conceptually, Microsoft has at various times during development hit upon reasonable ideas. EditFlags (in either form) serves numerous purposes. In both implementations it proposes to be able to deal with the implications of data streamed to the system as a MIME type. Unfortunately the two types do this in different ways. Further, they do this with the data, regardless of where the data is originating. IOWs, this isn't intended to implement security, but to extend similar data handling functionality across mediums. Whether I get the data from a disk, removable media, email, or web site, the same application will handle it.

    If EditFlags had been implemented as a Trust Zone component, for example, it might have been possible for you to make a setting which forced the handling of MIME types according to the medium they're being presented it. But that wouldn't have permitted you to make individual MIME type decisions within a zone. I might want to automatically launch Adobe Reader for PDFs but not invoke Word for .docs. You can imagine the array you begin to create when you go down this path.

    As it is now, too much code has too many decisions hard-coded. We're stuck with having to get a patch when things go awry rather than simply modifying a registry key (not that modifying a registry key was ever that easy when it comes to MIME types.) Certainly we can disassociate audio types from any application, but doing this stops the file type from ever working. I don't want audio in my email, but I may want to play MIDIs from my disk. I might not want them via the Internet, but I may want them from my Intranet.

    Maybe if we had a full MIME-map for each Trust Zone we'd have something to start with...unfortunately, we don't. I'm not sure what you've written up Thor, but it will be interesting to see if you've solved any of the problems we uncovered previously.

    Cheers,
    Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor

    oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
    Are You "Certifiable"? Summer's Hottest Certification Just Got HOTTER!

    With a growth rate exceeding 110%, the TICSA security practitioner
    certification is one of the hottest IT credentials available. And now, for
    a limited time, you can save 33% off of the TICSA certification exam! To
    learn more about the TICSA certification, and to register as a TICSA
    candidate online, just go to

    http://www.trusecure.com/offer/s0100/

    oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

  • Next message: Jeffrey Thomas: "reports of DCOM worm on the loose...still waiting on MS for DOS patch for W2K w/ MS03-026 applied"
    • Quantcast