COMMAND

    DocumentDirect

SYSTEMS AFFECTED

    Mobius DocumentDirect for the Internet 1.2

PROBLEM

    Following is  based on  a @stake  Security Advisory  by David  and
    Mark  Litchfield  (Contributors:  Frank  Swiderski and Chris Eng).
    Mobius'  DocumentDirect  for   the  Internet  is   a  custom   CGI
    application for Windows NT 4.0 that enables Internet-based viewing
    of documents.  Clients access the document management system using
    a   standard   web   browser.    DocumentDirect's   interface   is
    customizable for each enterprise's environment.  Authorization  is
    supported via a sign-on ID and password, and fine-grained  control
    can  be  exercised  over  the  content  made  available  to   each
    individual user.  It  supports multiple document types,  including
    PostScript,  PDF,  and  various  word  processing  and  image file
    formats.

    There  are  several  different  buffer  overflow conditions in the
    DocumentDirect for the Internet web application that could  result
    in the execution of arbitrary code, or at the very least, a denial
    of service against the DocumentDirect Process Manager.

    There are a several methods  that can be used to  overflow various
    static  buffers  in  the  DocumentDirect  web  application.    The
    simplest is to issue  the following HTTP command,  which overflows
    a buffer in DDICGI.EXE:

        GET /ddrint/bin/ddicgi.exe?AAAAAAAAAA...AAAAA=X HTTP/1.0

    In this instance, if the field  ID consists of at least 1553  A's,
    the  flow  of  execution  returns  immediately  to  0x41414141.  A
    properly crafted string  could easily result  in the execution  of
    malicious code.

    A second overflow  occurs when an  overly long username  is passed
    to DocumentDirect's  web authorization  form.    A minimum  of 208
    characters  are  required  in  the  username  field  in  order  to
    overwrite the saved  return address.   There is a  continuation of
    execution issue,  as the  code must  be permitted  to return  from
    several nested functions before exploit  code is run.  However,  a
    carefully selected exploit string could be written to evade  these
    limitations.   This  overflow  occurs  in  DDIPROC.EXE rather than
    DDICGI.EXE,  so  an  improperly  written  exploit  will  kill  the
    DocumentDirect Process Manager, resulting  in a denial of  service
    for  any  DocumentDirect  applications  that  are dependent on the
    Process  Manager.   It  is  not  clear  whether or not the Process
    Manager would  be adversely  affected if  code was  executed as  a
    result of the overflow.

    A third overflow occurs  when the "User-Agent" parameter  contains
    an  excessivly  long  string.   The  overflow  causes  an   access
    violation in DDICGI.EXE.  An example is:

        GET /ddrint/bin/ddicgi.exe HTTP/1.0\r\nUser-Agent: AAA...AAA\r\n\r\n

    It  should  be  noted  that  any  arbitrary  code that is run as a
    result of these  buffer overflows will  execute in the  context of
    the  application  containing   the  overflow.   While   DDICGI.EXE
    executes as a cgi-bin  type application and typically  executes as
    the equivalent to "nobody", other applications such as the Process
    Manager may be executing with elevated privileges.

    A  cursory  examination  of  the  DocumentDirect  for the Internet
    executable reveals liberal usage of static character buffers.   As
    such, there are  probably numerous additional  overflow conditions
    that @stake did not uncover in this initial audit.

SOLUTION

    The vendor, Mobius,  has assured us  that they have  contacted all
    their customers and given them a fixed version of the software.

    If a  web access  control product  is currently  in use,  restrict
    access to  DocumentDirect to  only those  IP addresses  associated
    with known DocumentDirect users.   If DocumentDirect is hosted  on
    a dedicated webserver, create a  firewall rule or a router  ACL to
    restrict inbound access to that machine until a fix is released.

    Another  temporary  workaround  would  be  to implement HTTP basic
    authentication on the /ddrint/bin directory.  By doing this, users
    would need to authenticate  before accessing the CGI  application.
    This  way,  if  someone  did   attempt  to  exploit  one  of   the
    vulnerabilities, it  could be  traced back  to an  individual user
    via the webserver logs.

    As  these  problems  exist  in  a  compiled  binary, the temporary
    solutions  are  awkward  without  vendor  involvement.  Some other
    examples of  temporary solutions  would include  binary editing of
    the application at hand  or creating wrapper programs  to sanitize
    the string lengths being handed to said application.