OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NTSecAdvice Archives: Re: Fwd: RFP9906 - RFPoison (fwd)

Re: Fwd: RFP9906 - RFPoison (fwd)

Steve Manzuik (smanzuikTELUSPLANET.NET)
Mon, 1 Nov 1999 17:32:14 -0700

Forwarded from another list.......

-----Original Message-----

rfp, thank you very much for reporting this. i was hoping that someone
else would spot this sooner or later and be the first to mention it on
ntbugtraq.

> > Interesting on how things go around/come around.

isn't it just? :-)

> >Recently Luke
> >Kenneth Casson Leighton posted a message on NTBugtraq in response to SP6
> >not fixing the LSA denial of service. He states that this problem is
> >essentially "due to marshalling/unmarshalling MSRPC code being unable to
> >cope with a NULL policy handle." He also states that they reported this
> >problem to Microsoft around February 1999.
> >
> > Well, no, I did not 'rediscover' the LSA denial of service (ala
> >the AEDebug advisory earlier this month). I did, however, discover a
> >different denial of service based out of services.exe. When sent a
> >specific packet, it's possible to get srvsvc.dll to choke, and cause
> >services.exe to reference a bad memory location. For those geeks in the
> >crowd, essentially srvsvc_netrshareenum in srvsvc.dll uses
> >rpcrt4_ndrcomplexstructunmarshall to tweak a string, but returns a NULL.
> >srvsvc_netrshareenum doesn't check for return value, adds four to the
> >pointer, and passes it up a function stack until finally that memory is
> >read (address 00000004). Blam...Dr. Watson.
> >
> > So we have another problem due to marshalling/unmarshalling
MSRPC
> >code. This was found independantly of Luke's info and the LSA
> >vulnerability.

> >It's hoped that between the services.exe and the lsass.exe denial of
> >services, both based on bad RPC code, Microsoft will find this problem
> >worthy of fixing.

ok, seeing as you found and reported this independently, i'm going to take
that as a green light for me to be able to report what i haven't been able
to say to anyone outside of microsoft before now.

issues
------

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
:-)

consequences
------------

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. i do not know 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.

decision
--------

so, it's up to you, the users of windows nt, to determine whether you
think this is important enough or not. do you want NT4 fixed now, with
the consequences that NT5, which has a _far_ superior MSRPC code-base, may
be delayed, or do you want to upgrade all your NT4 systems to NT5 when
it's available?

luke (samba team)

<a href="mailto:lkclsamba.org" > Luke Kenneth Casson Leighton </a>
<a href="http://www.cb1.com/~lkcl"> Samba and Network Development </a>
<a href="http://samba.org" > Samba Web site </a>

This archive was generated by hypermail 2.0b3 on Mon Nov 01 1999 - 18:41:56 CST