OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Craig Boston (craigWMHZA.GANK.ORG)
Date: Fri Mar 23 2001 - 09:59:02 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    Hi all,

    This thread has been on vuln-dev for a couple days; Aleph requested that a
    technical summary be posted here.

    First, thanks to -No Strezzz Cazzz for bringing this up and doing the
    preliminary work proving it to be a problem.

    Someone mentioned that this may have been brought up before on NTBugTraq;
    however their archive search seems to be broken so I can't see if it's been
    previously discovered... References to such a post that I can find have
    indicated that it was two years ago and the problem has still not been
    fixed, nor is it widely known.

    --------------- Background ---------------

    Windows NT includes a program called Dr. Watson, which is installed by
    default as the system debugger. When a user-mode program crashes, Dr.
    Watson is responsible for displaying the system error dialog familiar to
    many NT users. It also takes a snapshot of the process space and saves it
    to a file called user.dmp for debugging purposes. user.dmp can be opened by
    the windbg debugger for closer examination to see the memory and machine
    status (registers, call stack, etc.) at the time of the crash. This
    mechanism is very similar to the core files created on *nix systems.

    --------------- Vulnerability ---------------

    The problem arises in that NT's default location for user.dmp is
    world-readable. On NT4 systems, the default location is
    %SystemRoot%\user.dmp, which will usually end up being C:\WINNT\user.dmp.
    Default permissions on NT4 systems give Everyone Full Control on the WINNT
    directory.

    Crash dump files can often contain passwords and other sensitive information
    that was stored in memory and never intended to be written to disk in plain
    text. One example of this is the mail and news reader Outlook Express,
    which stores the user's mail account passwords in plain text (Unicode
    strings) in memory. OE also happens to be crash-prone when it encounters
    ill-formatted messages.

    Description of exploit:

    1. Users Jim and Bob share the same NT workstation; both use OE to check
    mail
    2. OE stores its saved mail and account information in the user's profile
    directory, which by default is set with permissions so that only the user it
    belongs to can access it. Hence, Jim cannot access Bob's mail directly
    because the OS won't let him into Bob's profile directory.
    3. Bob is using OE and it crashes, either accidentally or caused by a
    message sent by someone designed to cause the crash; such as a buffer
    overflow / invalud HTML / scripting / ActiveX attack.
    4. Jim can then open the user.dmp (world-readable) and sift through it to
    get Bob's password. A good utility for this is the Sysinternals
    (www.sysinternals.com) utility strings, which can extract a list of Unicode
    strings out of a binary file.

    Windows 2000 is also vulnerable, but in fewer circumstances. It's default
    location for user.dmp is C:\Documents and Settings\All
    Users\Documents\DrWatson\user.dmp. This location is world-readable by
    default, but not world-writable. Normal users will not have the user.dmp
    file created as they do not have write access, however users that are an
    administrator (possibly power users as well) of the local machine will be
    exposed to this vulnerability.

    --------------- Workaround ---------------

    Run drwtsn32.exe to set crash dump options. There are two ways to get
    around this problem (per-user):

    1) Uncheck the "create crash dump file" checkbox.
    -OR-
    2) Change the crash dump location to a directory that only you have access
    to.

    For a system-wide fix, delete the registry key
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
    NT\CurrentVersion\AeDebug\Debugger. This will cause Dr. Watson to be
    replaced with a simple "Application Error" box.

    If you have installed MSVC it will automatically make itself the system
    debugger, and it does not create crash dump files so you are not vulnerable.

    --------------- Fix ---------------

    MS needs to fix Dr. Watson so that it sets permissions correctly on the
    files it creates. A quick fix for the problem would be to make Dr. Watson's
    default crash dump location be somewhere inside the current user's profile.
    This of course will only work on NTFS file systems, but if you are using FAT
    or FAT32 for your filesystem there are much worse things that unprivileged
    users can do...

    --------------- Summary ---------------

    Systems Vulnerable:
    Windows NT 4.0 (All service packs)
    Windows 2000 (Release and SP1)
    Probably Windows NT 3.5x but untested

    I don't have access to the Whistler beta so I can't verify if it is
    vulnerable or not.

    Workaround: Yes
    Vendor-provided fix: No

    --------------- Credits ---------------

    Thanks again to -No Strezzz Cazzz (Butterphly6CAZZZ.DEMON.NL) for taking
    the time to dissect the file created by OE and write up the original report.
    You can see it in the vuln-dev archives (not there yet but should be
    shortly) for more info on the structure OE saves its passwords in memory.

    Thanks to Aleph1 for giving me the opportunity to post this to bugtraq :)

    And of course the patient folks in NTBugTraq who have probably discussed
    this 20 times by now.

    Regards,

    Craig Boston, CCNA
    Network Admin.
    Owen Oil Tools