[Date Prev][Date Next]
(ITS#5298) multi-step SASL binds are unsafe
Full_Name: Howard Chu
Submission from: (NULL) (220.127.116.11)
Submitted by: hyc
While testing the fix for ITS#5259 I realized that the SASL DN is being
allocated on the Operation's slab, but may be referenced by a different
Operation if a Bind requires multiple steps.
For OTP there are 2 operations - the identities are canonicalized and saved in
step 1, when the challenge is generated for the client, and then the OTP is sent
and validated in a subsequent operation.
(DIGEST-MD5 also occurs in 2 steps, but no usernames are provided in step 1, all
canonicalization and validation occurs in step 2 so it's all within a single
To avoid this problem, the DNs probably should be dup'd using the SASL
allocator, so they can be cleaned up automatically when SASL completes.