Novell client security defects

[Gary Flynn <flynngn () JMU EDU>]

Hi,

Does anyone know any more about these security defects in the Netware
client related to nwspool.dll?

http://secunia.com/advisories/26374/

and

http://www.zerodayinitiative.com/advisories/ZDI-07-045.html
http://xforce.iss.net/xforce/xfdb/35824

There are plenty of people out there with experience exploiting stack
based buffer overflows on Windows platforms including those in RPC
services. If the service is remotely accessible by anonymous
connections, it would seem to me we could be looking at another
infrastructure exploit ( ala Symantec a few months ago ) fairly
quickly.

On the other hand, it would seem to me that XPsp2 clients would be
protected by default firewall settings and even if they weren't,
they'd be protected by the XPsp2 RPC hardening that requires remote
RPC connections to be authenticated.

Thoughts?





Background info:

All the disclosure documents suggest the defects are remotely
exploitable through RPC calls. I don't understand why a remote
device would be calling functions like RpcAddPrinterDriver and
RpcGetPrinterDriverDirectory unless, perhaps, the client was
sharing a printer but the following document suggests the procedures
are accessible on non-Windows 2003 computers even if they are
not sharing a printer:

http://www.hsc.fr/ressources/articles/win_net_srv/msrpc_spoolss.html

  "Starting with Windows Server 2003, the Spooler service does
   not create the spoolss named pipe endpoint by default if no
   shared printer is configured."

The published disclosure documents don't say anything about risk
mitigation ( e.g. firewall settings ) or whether the defects are
exploitable by anonymous users.

A old defect in the Microsoft spoolss service was exploitable on
XPsp2 only by authenticated users and only if the target
client either shared a printer or accessed a shared printer:

http://www.microsoft.com/technet/security/bulletin/ms05-043.mspx

RPC was changed in XPsp2 so that connecting to either the portmapper
or individual RPC endpoints requires authentication by default:

http://technet.microsoft.com/en-us/library/bb457156.aspx#EGAA
http://support.microsoft.com/kb/838191/en-us

On the other hand, the documents leave a lot of room for
exposure:

1 ) "RPC clients that use the named pipe protocol sequence
    (ncacn_np) are exempt from all restrictions discussed in
    this section".

    The Tippingpoint doc for one of the defects says, "The specific
    flaw exists in nwspool.dll which is responsible for handling RPC
    requests through the spoolss named pipe". But even if the
    named pipe access is allowed anonymously, it would seem to me
    that the ports leading to the service would be blocked by
    default firewall settings.

2) "Exempt your interface from requiring authentication by setting
    the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag during interface
    registration. This configures RPC to allow anonymous connections
    to only your application’s interface."

    I have no way of knowing if Novell did something like this for
    the interfaces in nwspool.dll.






--
Gary Flynn
Security Engineer
James Madison University
www.jmu.edu/computing/security