Hi Dave,
----- Original Message -----
> While testing the implementation of delayed initialization of
> NSPR/NSS/SASL within libpcp, I ran across a bug in which the first
> secure connection of a client via pmproxy would succeed, but a second
> secure connection (and all subsequent secure connection attempts) would
> fail. I spent a bit of time trying to figure out how my code was causing
> the apparent regression with no success. I then, in an act of
> desperation, tried the scenario with the previous version of the code
> and experienced the same results.
To quote Bart Simpson - "I can't help but feel partially responsible". :|
So sorry - did I not have a test case for this? (qa/713? hmm, that does
not go far enough does it?)
> I spent some time this week debugging the situation and discovered that,
> within pmproxy, AcceptNewClient() was not initializing the
> status.allowed bit when setting up the table entry for a new client.
> Thus, if a previous client had already used the same table entry, the
> 'allowed' bit was already set.
>
> This bit, when unset, triggers a call to VerifyClient() for the first
> pdu received from that client, which should be the client's credentials
> pdu. When this bit has not been re-initialized and remains set for the
> next client, the call to VerifyClient() is bypassed.
>
> If the connection attempt is for a secure connection, this causes the
> observed connection failure, because the secure connection handshake
> between the client and pmproxy never occurs.
Excellent debugging.
> For an insecure connection, things still succeed, because the
> credentials pdu gets passed on to pmcd, which VerifyClient() would have
> done anyway. My concern is that pmproxy's call to __pmDecodeCreds(),
> which happens in VerifyClient() is skipped. Is there any potential
> security problem exposed by this?
I can't immediately think of one, but I'll ponder further too. IIRC we
were looking inside the Creds PDU in pmproxy so that we could establish
a secure connection "all the way" - so, both between client and proxy,
and between pmproxy and pmcd ... is that still happening with the fix?
(I think so, from my reading of the patch)
> The one line fix has been pushed to brolley/dev in pcpfans.
Nice and simple! Could you make an extension to test qa/713 to expose
the bug and verify the fix also please? (else, toss over the fence to
me & I'll do so) AIUI, a second pminfo connection should trigger it?
Thanks Dave and sorry 'bout that - this gem clearly has my dirty little
fingerprints all over it!
cheers.
--
Nathan
|