[Very sorry if you receive multiple copies of this. I've been fixing my mailer, and some messages have been silently dropped.]
Hi, I am using the MusclePAM code with a few modifications (just for reading raw key files - will post when it's all debugged). Quite separate from them (I'm fairly sure) is a memory leak. This can't be ignored, because it leads to a security hole. After thirty or forty password checks, xscreensaver crashes, unlocking the computer. The problem traces to winscard_clnt.c (SCardEstablishContextTH) the section protected by "isExecuted" is getting executed every time. For some reason, isExecuted (and mapAddr too) have zero values again the second time it is called from the same invocation of xscreensaver. Because of this, SYS_OpenFile is called again, but mapAddr is never closed. I assume this has gone unnoticed because most applications terminate before doing this many password checks against the same token, at which time the pcscd correctly collects all the open channels that are hanging around. My primary question is "Why is isExecuted getting zeroed?" Is it a shared object "thing?" I also wondered if maybe it is being zeroed as part of some security memory-blanking sweep, but can't find anywhere that might be doing that. Secondarily, is there a reason mapAddr isn't being closed in SCardReleaseContext? This might solve the whole problem. (Actually, it doesn't. I've tried closing it and zeroing isExecuted here. It didn't hurt anything, but didn't help the memory leak either.) The connection itself (socket to pcscd) isn't being closed on a ReleaseConnection. Both sides seem to expect the other to do it. winscard.c SCardReleaseContext just prints a debug message, assuming the RPC layer will clean up when it gets a socket close message (which it does when the application on the other end exits, closing all its sockets), and its counterpart in winscard_clnt.c sends the ReleaseContext request, reads the response, then just removes the context from the stack also without closing the connection. Am I missing something? On a completely separate track, how do I get gdb to trace into the shared object pam_musclecard.so for debugging this sort of thing? It keeps stepping over the calls into it, although I'm pretty sure it was all compiled with -g. One very last thing. In looking for this problem, I came accross one bounds problem in winscard_clnt.c:SCardGetStatusChange. I don't have a diff right now, but it's just changing this: } else if (cReaders > PCSCLITE_MAX_CONTEXTS) to this: } else if (cReaders >= PCSCLITE_MAX_CONTEXTS) Not that significant, but thought it was worth mentioning. I am probably working from an outdated source distribution. Is there a CVS tree I should be syncing with? Thanks for reading all the way to the bottom of this note. Cheers, -- Mike. ----------------------------------------------------------------------- Michael Nidd IBM Zurich Research Laboratory Saumerstrasse 4 CH-8803 Rueschlikon/Switzerland [EMAIL PROTECTED] Tel: +41-1-724-89-30 Fax: +41-1-724-89-53 What you want, what you're hanging around in the world waiting for, is for something to occur to you. -- Robert Frost _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
