---------------------- 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 - - thegnomeat_private - we would hack - - thegnomeat_private - the mind of god -
This archive was generated by hypermail 2b30 : Thu Oct 18 2001 - 15:14:14 PDT