COMMAND

    MSRPC

SYSTEMS AFFECTED

    WinNT

PROBLEM

    Luke  Kenneth  Casson   Leighton  found  following.    The   MSRPC
    marshalling code  (DCOM) in  NT 4.0,  all service  packs, is  very
    badly written.   It is susceptible  to all sorts  of out-of-bounds
    issues.  The areas that are particularly bad are:

        - string handling (any MSRPC service where a UNICODE string is
          sent, and that's basically all of them).
        - arrays-of-structures  handling  (for  example,  an array  of
          shares   in   NetrShareEnum;   array   of   transports    in
          NetrServerTransportEnum;  array  of  SIDs  in LsarLookupSids
          (this one may have been fixed in one of the hotfixes, now in
          latest service pack)).
        - dynamic-item-count in structures (for example, the number of
          RIDs in a SID is dynamic).
        - enumeration-containers  (indicating  that  an info level  is
          going to exist,  then passing a  NULL pointer to  the actual
          structure indicated by the info level).
        - policy handle management  (for example, sending NULL  policy
          handles in function  calls instead of  a previously-obtained
          policy handle,  e.g OpenService(NULL,  "service name",  ...)
          instead     of     OpenSCMAN("server",     &pHnd,      ...);
          OpenService(&pHnd, "service name", ...).

    There used to  be some issues  in Service Pack  1 with the  actual
    MSRPC headers  themselves, which  got fixed  (you can  anonymously
    crash NT4  no SP  by sending  garbage MSRPC  headers).  There were
    also some issues to do  with MSRPC authentication that were  fixed
    in  Service  Pack  4  (evidence  of  this shown through samba code
    breaking when SP4 beta RCs were made available.

    All  of  these  things  have  various  dire  consequences,  namely
    termination of services or  even overwriting kernel memory  in the
    case of the registry service,  as that's where the registry  MSRPC
    service  is  implemented,  for  speed  gains.   This  results   in
    unpredictable  behaviour  that  will  eventually  result in a blue
    screen.   Fortunately,  the  registry  is  not accessible remotely
    without an authenticated user connection.

    There may be  other MSRPC-based services  that are implemented  in
    the kernel, for speed gains.  It is not known what they are.

    The poor quality of  the marshalling / unmarshalling  code affects
    _all_ MSRPC  / DCOM  services, including  any services  written by
    third party  developers (as  DCOM is  MSRPC-based, the  code being
    generated by a MIDL compiler).   So, that includes Exchange,  SQL,
    NT printing, NETLOGON, Event Log, srvsvc, wkssvc, winreg,  winsif,
    winsadmin, browsess, svcctl, atsvc, samr, lsa.

SOLUTION

    There is empirical  evidence to show  that Microsoft has  resolved
    these problems at a coding  level, however it requires a  *TOTAL*,
    recompile of *ALL* MSRPC-based  services to use the  much-improved
    MSRPC  marshalling  /  unmarshalling  code.   Plus testing, plus a
    massive hotfix or series of hotfixes or a new service pack.

    Basically, Microsoft is working really hard at fixing /  rewriting
    all of these things,  and they've done a  heck of a lot.   It just
    hasn't seen the light of day, yet, in a released version of NT.