1

Does the clipboard under kUbuntu's KDE System Tray > Extra Items "Clipboard" have the same security threats as the system clipboard?

The following articles point out the insecure nature of the clipboard:
Is clipboard secure?

Is a password in the clipboard vulnerable to attacks?

How can I protect myself from this kind of clipboard abuse?

Can a malware steal the content of the clipboard?

The reason I ask is because I just realized that when I use the program xsel to clear my clipboard:

sudo apt-get install xsel
xsel -bc

My system clipboard is clear but all the contents are still available from kUbuntu's
KDE System Tray > Extra Items "Clipboard".

Does it carry the same security concerns as the system clipboard?

Note: I am aware there are many points of vulnerability a system has as it relates to information in RAM and on disk. This question is specifically about contents in the known 'system' clipboard as discussed in the attached links, and unknown clipboards (other places I don't know about that store what I right-click-copy or CTRL + C). Clearing the clipboard is one of many security measures and has it's cases of uselessness in certain types of attacks. Nonetheless I am still curious about these 'other' clipboards and if their vulnerabilities are essentially the same as the system clipboard.

jtlindsey
  • 225
  • 1
  • 10

1 Answers1

1

All processes running as your user can read the contents of your clipboard and modify the contents. The KDE clipboard, called Klipper when I last used KDE, also stores previous clipboard history. It stores it by default in a text file. This means that the contents can be recovered from your hard drive by a forensics examiner or malware. You can disable this functionality however, causing it to only be stored in memory. All processes running as your user can still read and modify the clipboard, of course. If malware runs as your user, it has the same abilities you do. Always remember that.

With your system clipboard, the following is possible:

  • Processes running as your user can read the clipboard contents
  • Processes running as your user can modify the clipboard contents

With the KDE clipboard, the following is possible (by default):

  • Processes running as your user can read the clipboard contents
  • Processes running as your user can modify the clipboard contents
  • Processes running as your user can read your clipboard history
  • Processes running as your user can modify your clipboard history
  • Processes running as root can read very old deleted clipboard history
  • Forensic examiners / people with access to the drive can read very old deleted clipboard history

The last two bullet points can be disabled. When I last used KDE, this was possible by setting a limit to the history size. When the size is set to unlimited, it will save it to a text file on the drive. When the size is a numeric value, the history will be stored in memory only. You might also have to set it to not remember history across reboots. Or something like that.

I would like to note something however. It sounds to me like you are under the impression that individual applications are able to provide you with security against other programs which runs as your own user. If you indeed are still under the impression that you can protect your system from things like keyloggers running as your user, it is time to be disillusioned. Everything you type can be recorded by programs running as your user. Linux provides inter-user isolation, not intra-user isolation. This means that your browser, if it is compromised, can keylog that user. I've talked about this a bit here and here, and there is an old but excellent writeup about the problem of assuming intra-user isolation.

forest
  • 64,616
  • 20
  • 206
  • 257
  • While I was not under the impression that individual applications are able to provide me with security against other programs (that's not what the question was about), your notes about it sparked some thoughts and reading that I've been overlooking. Great points. – jtlindsey May 01 '16 at 13:32