The Truth Shall Make Ye Fret.
1. Key loggers -
First, if you have physical access you can use a hardware key logger, period, independent of OS or any other security measures.
Second, if you have access to my account, you can install a software key logger to an account you have access to. If you have my password, and can log into my account, then yes you can install a key logger, and review any private data I have in $HOME that is not separately encrypted.
You can not use a software key logger to monitor someone else's account without root access.
If a cracker has leveraged an exploit such that they can access root, they it is for the most part game over. In that event installing a key logger is secondary, a result of a compromise to the root account and the defense it to prevent or close the exploit that allowed root access in the first place. Here we keep our system up to date, use strong passwords, etc.
So when discussing key loggers you need to be very clear are we discussing a hardware key logger, monitoring an account you have access to, or monitoring someone else.
Each of those 3 scenarios has a very different security implication and solution.
Second you are discussing security vulnerabilities vs exploits. Vulnerabilities, both known and unknown, have not yet been leveraged.
So yes, every application, by definition, has vulnerabilities so in theory anything is possible.
Now lets turn that into practical security (with respect to key loggers).
1. There are no known active exploits that will install a key logger onto a linux system. Your system was patched to the known exploits long ago. Please do not give the impression that key loggers are an active issue on Linux, they are not, they are a theoretical problem (see zero day exploits below).
2. Zero day exploits are when a vulnerability, either known or unknown, it leveraged to crack into a system. By definition they could do most anything, including installing a key logger.
The defense against zero day exploits is either apparmor (in ubuntu) or selinux (in Fedora).
So if you are worried about a key loggers :
1. You must first specify what kind ? hardware, software, etc.
The defense varies:
1. Hardware - inspect your hardware.
2. Monitoring your user - use strong passwords and do not use untrusted accounts. Encrypt your user account.
3. root - physical access == root access. If you can not physically secure your computer and you can not trust your system administrator, they, assume they are using a key logger or other mechanism to monitor your activity. Again encryption would be your only potential defense.
2. Known , active Linux exploits using key loggers - there are none.
3. Zero day exploits - Who knows ? Use apparmor or selinux. Even apparmor or selinux can be cracked, but those are currently the best two tools you have against zero day exploits.
The reason I'm "jumbling several issues together" is because they are all tightly related when it comes to answering the question "are keyloggers a concern?". And I definitely did not mean to be "spreading misinformation and FUD", so I apologise if it came out that way.
All I was trying to say is this:
- a rogue application with access to the X session can monitor the keystrokes of every other application using the same X session.
- a normal application can become rogue if it has a vulnerability that has not been discovered/patched yet. This is also how keyloggers get installed on other Operating Systems.
Now, you seem to say that the above is not a concern because there are no known cases of it happening in the wild. And of course you have a right to that opinion, but I think the users should be at least aware of these issues when they are assessing the security of Ubuntu/Linux.
You imply that software vulnerabilities/exploits are beyond the scope of a discussion about keyloggers, however in other OSes this is the primary method of getting a keylogger onto a system without user interaction and I think it is a valid concern here as well.
And I do need to address one of your bolded statements in particular:
EDIT: Also, an application with access to the X session can easily capture the password used for "sudo" if it is entered in a graphical terminal using that same X session or (apparently) in the graphical sudo prompt.
Last edited by secret resistor; May 28th, 2011 at 07:10 PM.
Again, you are mixing possible with practical.
It is possible for
1. A user to disable a variety of security features, including access to his or her account and access to X, and as a result, a key logger would then work across accounts as you suggest, but it does not work "out of the box" without either user intervention (to disable security) or root access (to over ride security).
oeg is eye of gnome, an X application for viewing pictures, and as you can see, access to X is disabled. Now I can over ride that with xhost or by running as root, but "out of the box" X security does not allow the kind of access you suggest.Code:bodhi@linux:~$ su user2 Password: user2@linux:~ eog (eog:2993): EOG-WARNING **: Service registration failed. ** (eog:2993): WARNING **: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. ** GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: (connection->initialization_error == NULL) Aborted (core dumped)
Second, you are talking in theory. In theory, a cracker can exploit a known or unknown application, and thus gain sufficient access to install a key logger.
It is important to understand that No such exploit is currently known
What do you want me to do about potential threats ? My house might get hit by an airplane. The sun might burst in a ball of flames.
In the event of a zero day exploit against firefox, on my box, firefox is confined by apparmor. So if you gain control of firefox, and run arbitrary code, such a try to install, let alone run a key logger, apparmor will stop you.
Unless of course your theoretical exploit can also defeat apparmor.
Your security advice is long in theory and paranoia, but not very good advice to new users. It basically boils down to :
There is no such thing a compete security
with little or no advice on how to actually secure a linux box.
I think secret resistor's point is that running "xinput test" is, to all intents, a keylogger that can run without sudo. If malware can somehow run the command and get its output (or send it home, etc.) it can get the user's passwords. If that user runs as sudo, that malware gets root. I haven't tested whether it can log key presses of other users, but xinput test does work for the current user. If he's right, that's a potential security hole.
The main stumbling block for such an exploit is getting it to run. With Apparmor running it can't add itself to bashrc or anything like that, but it can get itself elsewhere in ~/. Still, unless it can somehow exploit config files of another program, it can't run unless the user opens it, which brings us back to user education.
It is a straw man argument.
If my system is cracked, the intruder can run abc and do xyz.
In this case we are discussing key logging.
But that is what it means to have your system exploited.
See any of these vulnerabilities:
If a crack exploits one of those vulnerabilities and runs "arbitrary code" you are in deep trouble.
You can make up any number of "problems" or security holes at that point, from replacing .bashrc to adding any number of programs in $HOME.
Those secondary "problems" are not the security hole, the vulnerability that allows running "arbitrary code" is the security flaw that needs to be fixed. The fix depends on the exploit and can vary from limiting physical access to patching code.
In this case, xinput is the "arbitrary code". "arbitrary code" not a security hole and there is not "fix" to "arbitrary code".
Once an intruder can run "arbitrary code" the proverbial cat is out of the bag and again short of apparmor to selinux there is not much you can do to contain an intruder at that point. If they have access to an account that has root access, the intruder has root access via any number of methods.
Last edited by bodhi.zazen; May 28th, 2011 at 10:43 PM.
For running as different user, what I meant is if a graphical application is allowed to run then it can snoop on the keystrokes. If it is not allowed to run (i.e. no xhost rule) or it is not graphical then you are right that there is no problem.
As for the rest, you seem to be operating under assumption that if any of the software you run gets exploited then it is game over. If that is the case then I don't think I can (or want to) argue with you.
If you use firefox as an example, and firefox is exploited, and if firefox is configed by apparmor, then firefox can not access bash, ~/.bashrc, xhost, or xinput unless I allow it in the apparmor profile.
So if firefox tries to run a code, say /bin/foo
Unless there is a rule in the apprmor firefox profle
then apparmor will not allow firefox to run foo (or access ~/.bashrc, or run bash, or xinput, or, well you get the idea).
selinux would be a whole topic on it's own, and if you want to see what selinux will do, try fedora 15
As I said the xinput binary is only used as a proof of concept, so it is not that relevant. What you need to block is the underlying calls or requests to the X server, otherwise you are not preventing the keylogger from obtaining the information. All your examples seem to be about running new processes (correct me if I'm wrong) which is not required for an exploited application to be recording keystrokes. And if the application is already allowed to make arbitrary HTTP requests (as firefox would be) than there is nothing stopping it from reporting the keystrokes to the attacker.
Yes, I realise that this may seem a bit offtopic but I still think it is relevant to the question of how to protect against a keylogger.
There are protocols in place to secure X sessions in a multi-user environment and they have been in place for many years.
If you disable them (as a user) or circumvent them (as root) they yes, like ecryptfs, X is a security risk, but, IMO, your argument is somewhat twisted.