security: do not keep sensitive information too long in memory

Submitted by Stepan Salenikovich (ssalenik)

Shouldn't we first then address the issue of password storage on disk in clear text? An attacker doesn't even have to analyze the client's memory or anything that complex. TURN and SIP passwords are stored in clear text in dring.yml which is readable... they're also sent over dbus in clear text as well.

I will take a look how to handle the memory issue in GTK, but I think we need to prevent clear text storage.

Heres the initial comment from Mike for reference:

... LibRingClient keeps
plaintext SIP passwords in memory for the lifetime of the program; GNOME
client keeps a copy of the password for every character entered
individually until it happens to be overwritten in memory; and the
daemon also stores a copy of the password in plaintext, though I didn't
yet check the code to see if it's persisted. This is dangerous, as
there are various ways for attackers to read memory, such as by
triggering core dumps or reading process memory as root, and prolonged
lifetime increases the risk of exploitation: an attacker can wait for
the user to leave the computer, or a program exploit might be able to
read memory at some distant point in the future. It'd be worth checking
how all sensitive data are stored in memory, keeping it in memory in
plaintext for only as long as it is needed, making sure the member is
not permitted to swap to disk, and overwriting the memory with other
data or randomness when the sensitive data are no longer needed.

Submitted by Stepan Salenikovich (ssalenik)

Evaluation of password storage:

Daemon:
- SIP/TLS/TURN passwords stored in plain text in dring.yml
- TLS/TURN passwords stored as std::string in SipAccountBase->turnServerPwd\_, tlsPassword\_
- SIP password(s) stored in SipAccount in Credentials struct as std::string
- all passwords (SIP/TLS/TURN/archiver) are sent in plain text over DBus to and from the clients, thus they are exponsed to anyone listening on the dbus

LRC:
- SIP/TLS/TURN password retrieved in plain text via daemon API and stored along with other account details in either a QHash (AccountPrivate->m\_hAccountDetails) for the duration of the programs (lifetime of the Account object) or in the account's CredentialModel in a Credential object as a QString (again, this is usually for the lifetime of the program). I think technically everything was supposed to be migrated into the CredentialModel, but this has not yet happened.
- Certificate Private Key Password stored as plain text QString in CertificatePrivate->m\_PrivateKeyPassword

GNOME client:
- SIP/TLS/TURN password retreived from LRC or user input and placed in a GtkEtnry (in password mode, ie: \*\*\*\*). The lifetime of this object is duration that the account is selected in the account settings view (this view is not destoryed when the settings view is closed), so if the same account is selected the entire time, it could be the lifetime of the program.

Submitted by Stepan Salenikovich (ssalenik)

Possible solutions to prevent plain text password storage/passing are keyring libs/API such as:

However, these are platform specific, so we would not be able to integrate them into the daemon. We would then need the password storage to happen in the client. Altought another possibility is to continue to store the passwords in plain text as a fallback, but store them in an encrypted manner if possible via the client or a plugin...

Submitted by Guillaume Roguez (guillaume)

Another solution is having a daemon secret-wallet class, holding all secrets encrypted using a password given by user at application startup.
When needed, the secret is given from this wallet. The application must use it and forget asap.
existing solution?

closed

security: do not keep sensitive information too long in memory

Designs

Child items ...

Activity