0

I have a remote client machine put in a server center owned by an entity who must also have the root of the client machine according to industry regulations. The client machine runs a C++ program that uses libmysqlclient.so and periodically queries a MySQL server located in my office via the internet.

The data is highly sensitive so I need to protect the data from being disclosed in the whole process of data transfer. Nobody is trusted in the server center including its owner who has the root of the client machine.

At first, the json format database config of the C++ program contains explicit IP, port, user, and password. Anyone who has root can read those and use them to connect to our server from the client machine. Since IP and port must be disclosed to the owner of the server center who manages the intranet, gateway, and firewall according to regulations, I replace user and password with encrypted strings in the config and the C++ program will decrypt them at startup to obtain the real user and password to connect to the server.

The root user, however, may replace libmysqlclient.so in the system with a modified version so that the user and password are printed out when a connection is being established. Then I change the C++ program to static linking to libmysqlclient.a at compile time.

However, the data being transferred is still clear-text. So I enable SSL on the MySQL server and alter the user as REQUIRE X509. Then man-in-the-middle attack is supposed to be not easy.

To make the two-way TLS work, I also need to put ca, client-cert, and client-key files to the client machine. I'm wondering if the server center owner can capture the encrypted traffic being transferred and use those files to decrypt the data without any knowledge of the database username and password?

Also is there any obvious vulnerability on the client side after having all these setups? Let's assume that the net structure and the use of MySQL are not to be changed.

0

Assuming you only need to run 'a C++ program' when you are logged in, maybe use a reverse SSH tunnel when you connect -R /tmp/mysql.remote.socket:/var/run/mysql/mysql.sock (as ssh argument). This would be easier to sort out that SSL and not require firewall changes as its piggybacking on your ssh connection in.

There is no absolute way to run a program on an untrusted machine with 0 risk of malicious intent. Mitigations include:

  • staticly compiling the executable
  • on the server sshfs mount a directory on your server with this executable on it (with -o reconnect,idmap=user), make this readonly and make it operate over your reverse ssh tunnel (add another -R remoteport:localserver:localport for the sshfs connection to the ssh server).
  • protect against gdb attacks using mprotect and madvise(DONT_DUMP) so information isn't stolen for some points during all points at which the program is run
  • there is some technology supported by hardware where a guest VM can run in a mode where the host cannot access the guest memory (needs further investigation)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.