New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Srp user manager sporadically creates users which can not attach [CORE6038] #6288
Comments
Modified by: @AlexPeshkoffassignee: Alexander Peshkov [ alexpeshkoff ] |
Commented by: @artyom-smirnov Looks I've found root of problem: In some cases verifier (SrpManager.cpp: server.computeVerifier(user->userName()->get(), s1, user->password()->get()).getBytes(s);) which is should be 128 bit number generated as 127 bit. When selecting (SrpServer.cpp: "SELECT PLG$VERIFIER, PLG$SALT FROM PLG$SRP WHERE PLG$USER_NAME = ? AND PLG$ACTIVE";) it casted to array of 128 bits (SrpServer.cpp: verifier.assign(reinterpret_cast<const UCHAR*>((const char*)verify), RemotePassword::SRP_VERIFIER_SIZE);) and padded with extra zero bytes at right. So after this casting we will get wrong verifier. For example if we pad verifier from left when selecting it will be casted properly: The question is it always should be 128 bit or not? |
Commented by: @AlexPeshkoff You've meant 128 bytes I suppose. |
Commented by: @artyom-smirnov Yep, bytes of course. Here backup and original security3.fdb database. User/password are test/test https://www.dropbox.com/s/0qc79m69fix0byi/security3.bak?dl=1 |
Commented by: @AlexPeshkoff Slightly offtopic - never used to notice that effect myself, great that you've found relatively stable case. |
Modified by: @AlexPeshkoffstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 3.0.5 [ 10885 ] Fix Version: 4.0 Beta 2 [ 10888 ] |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: No test => Deferred Test Details: Reproduced on old FB, but have question about randomness. |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: Deferred => Cannot be tested Test Details: Reproduced on old FB, but have question about randomness. => Ticket's issue *confirmed* following script:connect 'localhost:e30' user sysdba password 'masterkey';
|
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pavel-zotovstatus: Closed [ 6 ] => Closed [ 6 ] Test Details: Ticket's issue *confirmed* following script:connect 'localhost:e30' user sysdba password 'masterkey';
|
Modified by: @pavel-zotovstatus: Reopened [ 4 ] => Reopened [ 4 ] QA Status: Cannot be tested => Deferred Test Details: Ticket's issue was *confirmed* by executing following script:connect 'localhost:e30' user sysdba password 'masterkey';
|
Modified by: @pavel-zotovstatus: Reopened [ 4 ] => Reopened [ 4 ] QA Status: Deferred => Done successfully Test Details: Ticket was reopened after discuss with alex and dimitr. Sent letter to alex and dimitr, 06.06.2019 08:29. Waiting for reply. => |
Submitted by: @artyom-smirnov
To reproduce this bug enough to create user/try to login/drop user many times.
I digged into Srp manager and found it happen with some "magic" salts. For example: AE7A9732FB795098A4ECE3CE28BD01C4363E870F9AD399AFBEE2CBC6FBB30580
If you try to set this constant salt in SrpManagement.cpp all newly created users will be unable to authenticate (SrpServer.cpp: SrpServer::authenticate "if (clientProof == serverProof)" always false).
Reproducing script:
#!/bin/bash
BIN=/opt/firebird/bin/
DBPATH=/tmp/test
DB=localhost:$DBPATH
cat << EOF > /tmp/prepare
create database '$DB' user sysdba password 'masterkey';
drop user test;
EOF
cat << EOF > /tmp/sql
connect '$DB' user sysdba password 'masterkey';
create user test password 'test';
connect '$DB' user test password 'test';
connect '$DB' user sysdba password 'masterkey';
drop user test;
EOF
rm $DBPATH
$BIN/isql -i /tmp/prepare
set -e
while true; do
$BIN/isql -b -i /tmp/sql
done
Commits: b52874f b30b7e2
The text was updated successfully, but these errors were encountered: