Bugtraq mailing list archives

GroupWise Padlock Speculative Info


From: Simple Nomad <thegnome () nmrc org>
Date: Thu, 18 Oct 2001 13:23:35 -0400 (EDT)

----------------------
GroupWise Padlock Info
----------------------

History
-------

Novell was notified by someone around the 6th of August about a security
flaw in GroupWise that apparently allowed basically anyone with access to
the GroupWise server to do "bad stuff". August 14th brought the
announcement of Padlock, the patch to fix GroupWise (see
http://support.novell.com/padlock/ for details).


Rantish Comments
----------------

Novell has not released any details, nor are they probably going to, at
least any details that explain the exploit. In the name of those who might
like to develop workarounds because they cannot apply the patch or those
who would like to develop network IDS signatures, I'd like to officially
say "bad dog, no biscuit".

I completed this initial analysis on August 27th, and only looked at the
problem for a few hours total. I don't have access to GroupWise to really
perform the additional tasks needed.

But bearing in mind the current state of fear, uncertainty, and doubt, I
decided that I should at least release what I have. In a not-so-distant
future any research like this could be a terrorist act, and if it were
Microsoft I might not be "thanked" for "helping to protect their
customers". So I am releasing some fodder for someone else to run with if
they wish, or if they have the time and software to adequately explore it.
Nonetheless, I think I know at least what the extent of the vulnerability
is.

Let's hope Padlock's lockdown abilities are not undone by later
administrative actions, or a combination of other conditions such as other
patches, but of course we won't know until we know the details now will
we?


Fodder for Discussion
---------------------

I did some disassembly work on the GWENN2.NLM that comes with the Padlock
patch. I will be the first to admit that I do not understand assembly to
the level I'd like to, but nonetheless I believe I have a few answers.

Of course due to the huge number of changes that went into the NLM, I will
assume that some of these changes are not security related, but basic bug
fixes. Bearing this in mind, one has to search for the bug that is
security related, when it is not obvious.

First we look through the new routines added to the Padlock version of the
NLM.

GW2_NGWLangIsMultiByteCharset
GW2_waasStreamCipher
GW2_WpadmGetRecordID
GW2_WpeGetReplyDList
GW2__WpioGetNextChar

The least promising seems to be the GW2_NGWLangIsMultiByteCharset, just
based on the name.

Next we look for routines on the old NLM that were replaced with different
routines:

GW2_WpdsABCreateAndOpenPrim replaced by GW2_WpdsABOpenPrim four times
GW2_WpadmGetRecord replaced by GW2_WpadmGetRecordID once.

This shows some promise. The OpenPrim calls are usually used when opening
database files -- the core of GroupWise. Note that four instances of
GW2_WpdsABCreateAndOpenPrim were replaced with GW2_WpdsABOpenPrim. The
names seem to suggest that if the database is not there, a new one is
created, but the new version only opens an existing one. In the older
version of the NLM, the Create and Open action could create a blank
database with a certain set of rights that *could* be used as some type of
mechanism for access.

Also, a new routine called GW2_WpadmGetRecordID has been added (it does
not replace GW2_WpadmGetRecord, but is called instead of it at one point).
This routine, in getting some type of ID, implies additional checking
going on.

Next we compare to see what routines were "called", and note differences
between the NLM versions.

Old NLM version:
fopen
fprintf
GW2_WpcomGet
GW2_wt_MsgGetDestInfo

New NLM version:
AtUnload
DeregisterLibrary
exit
GetDataAreaPtr
GW2_waasStreamCipher
GW2_WpadmGetRecordID
GW2_WpeAdminPartstoParts
GW2__WpioGetNextChar
GW2_WpPabSyncAllPersonalBooks
GW2_WpS6StrRChr
RegisterLibrary
SaveDataAreaPtr

A few of the new routines were called, including GW2_WpadmGetRecordID.


More Fodder
-----------

We apply some logic from what we know about the patch itself. Novell has
stated that the servers should be patched, and the patch basically boils
down to a single NLM. Supposedly the client also needs to be patched, but
the system is secured from exploit via the NLM. This suggests that a
client "feature" is taking advantage of the protocol that exists between
the two. Correcting the NLM closes the hole, and correcting the client
software prevents the client from exploiting the hole.

Checking with the list of vulnerable versions of software, and what
features seem to be in use on these versions, it seems that the problems
with the protocol occur when information is copied down to the client for
caching. The reasoning behind this is fairly straight forward.

What this basically means is that during the conversation between client
and server, it is possible to cache information that might be used during
the conversation down to the client from the server to save time sending
packets across the network. Since Novell mentions a performance hit as a
side effect to the Padlock patch until the client is updated, one can only
assume that Padlock "disables" caching unless the client has been updated.
This implies an update to the protocol, and also gives a better idea to
the scope.


The Bug Itself
--------------

Based upon what minimal amount of info I derived from the disassembly and
what I got from Novell's nothingness of a disclosure, it appears the bug
is that an unauthenticated user can read any file on the file server.
Since this is at the NLM level on the server side, any number of methods
for access to this NLM can more than likely exploit the problem. Regular
GroupWise clients, and even web-based clients can exploit the bug.
Therefore if you have GroupWise and Internet access to the GroupWise
server, remote intruders can more than likely pull any file they wish off
of the server (remember, NLMs run at a level of access even greater than
an administrative account), possibly even NDS files which contain
crackable hashes.

If I am incorrect in this assumption, Novell can tell me.

-         Simple Nomad          -   if we were priests   -
-      thegnome () nmrc org        -      we would hack     -
-  thegnome () razor bindview com  -     the mind of god    -



Current thread: