Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: [Muscle] Why can't a session opened by one thread be closed by another?
From: Damien Sauveron (sauveronlabri.fr)
Date: Mon Apr 03 2006 - 10:09:16 CDT
Shawn Willden a écrit :
> On Friday 17 February 2006 07:55, Damien Sauveron wrote:
>>Shawn Willden a écrit :
>>>If you call SCardEstablishContext from one application thread and then
>>>pass the handle off to another thread which will later call
>>>SCardReleaseContext on it, the release will fail. The implementation
>>>explicitly checks to see that the releasing thread is the same as the
>>I had mainly added this check for security reason (against a malicious
>>program that wanted perturb the behaviour of a client -- perhaps it is
>>not a very important problem)
> Hmm. I'm also not sure how much of a problem this is, but I don't think the
> thread ID check solves it, because the check is performed on the client
> side, i.e. on the side controlled by the attacker. If I wanted to mess with
> a client's connections to the server, I could simply compile my own
> libpcsclite that omits the client-side thread ID check.
> However, unless I'm missing something, I think the server actually prevents
> such rogue clients. Since each ContextThread listens on a single socket and
> is associated with a single psContext array entry, I don't see how a rogue
> app could release another app's context -- not without somehow managing first
> to break in on the legit app's socket connection. Is it possible to hijack
> another process's file descriptor? It better not be. Even if it were
> possible, the rogue would also have to know the correct hContext value. The
> space of hContexts is small enough that it could be searched pretty easily,
> so if I'm missing something and this attack could be performed on the code
> as-is, another simple solution would be to enlarge the space of hContexts, a
> least to the full range of an unsigned long and perhaps even to a larger
> In sum, it appears to me that the thread ID check is a non-solution to a
> problem that is probably already solved.
> Am I missing something?
You are right! I have not checked in the code but if I remember you are
Sorry for the delay of my answer but I have a lot of work.
Thanks for your contributions to pcsc-lite.
Muscle mailing list