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
Does anyone know any more about these security defects in the Netware
client related to nwspool.dll?
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
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.
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:
"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:
RPC was changed in XPsp2 so that connecting to either the portmapper
or individual RPC endpoints requires authentication by default:
On the other hand, the documents leave a lot of room for
1 ) "RPC clients that use the named pipe protocol sequence
(ncacn_np) are exempt from all restrictions discussed in
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.
James Madison University
- Novell client security defects Gary Flynn (Sep 21)