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 > > establishing thread.
> 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
value.
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?
Shawn.
pgpzi6Z88p4fX.pgp
Description: PGP signature
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
