Closed Bug 616038 Opened 11 years ago Closed 11 years ago
x-keyexchange-id Not Validated For Initial Put to Channel
QA Contact: other-server → key-exchange-server
(In reply to comment #0) > At this point the client sending the PUT has the x-keyexchange-id and this > value is sent within the PUT message as a header. However, the server does not > validate that this value is correct. The current mechanism is : * when the channel is created, the client id provided is associated to that channel * on every new request on the channel ** if the client id is a new channel id, it's associated to the channel, unless the channel already has two IDs associated. If the later happens, the request is rejected and the channel closed. ** if the client id is already registered to the channel, the request is not rejected. So, the filtering makes sure that one channel does not get more than two different client ids. If it happens, it gets closed. In your test, you can validate this by: - creating a channel with with client id "A" - puting data with client id "B" - any new attempt with client id "C" will fail and the channel will be deleted. > The impact is that an unauthorized user could inject false data into the j-pake > message exchange. This could easily cause the sync to fail. It may be possible > for an attacker to insert malformed or malicious data that results in adverse > effects to either of the legitimate parties in the sync transaction. The very nature of J-Pake will avoid this issue because when client A initiates a channel to transmit data to client B, if a client C is able to take the place of client B on the first exchange, client A will get invalid data, unless client C was also able to guess the initial password. In other words, an attacker needs to: - guess the channel id in the second client A starts it - guess the password client A used the probability of this occurring is over 1/200 billions.
(In reply to comment #1) > In your test, you can validate this by: > > - creating a channel with with client id "A" > - puting data with client id "B" > - any new attempt with client id "C" will fail and the channel will be deleted. Tested. Server properly failed and deleted the channel. > In other words, an attacker needs to: > - guess the channel id in the second client A starts it > - guess the password client A used Agreed. Very low probability. These controls are sufficient and working properly.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Group: client-services-security → mozilla-services-security
Resolution: INVALID → WONTFIX
You need to log in before you can comment on or make changes to this bug.