Educause Security Discussion mailing list archives
Novell client security defects
From: Gary Flynn <flynngn () JMU EDU>
Date: Fri, 21 Sep 2007 10:36:03 -0400
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
Current thread:
- Novell client security defects Gary Flynn (Sep 21)