concerned about keyloggers and user account security

[Lars Noodén]

I'm not sure about that. Vulnerabilities in commonly used software show up all the time. All it takes is a 0-day exploit in your browser/flash player/etc. or a user running out-of-date software.

Less than that is needed. Every flash video is basically a potential trojan wrapped around an otherwise harmless video codec. Similar for the flash animation. Videos could more safely and more portably be distributed as a bare bones MPEG, Quicktime, WebM or Theora and skip the flash menace.

[bodhi.zazen]

This is simply not true, as has been shown in this thread. In a default Ubuntu (and most other distributions I think) install you can run a keylogger without root access.



I'm not sure about that. Vulnerabilities in commonly used software show up all the time. All it takes is a 0-day exploit in your browser/flash player/etc. or a user running out-of-date software.



That has been my experience so far as well, however saying that keyloggers are nothing to worry about in Linux (with XWindows) is dishonest at best. And I think that as the platform gets more popular we may see such attacks in the wild, unless something gets done about the XWindows/XInput problem before that.

You are jumbling several issues together and as such spreading misinformation and FUD.

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.

[secret resistor]

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:

You can not use a software key logger to monitor someone else's account without root access.

This is not strictly true. If your account has access to the X session, it can monitor keystrokes from every other application using that X session, even if it is run as another user. For example if you run firefox as another user and it gets compromised in some way it can monitor keystrokes from every other application sharing the X session, even those run by other users.

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.

[bodhi.zazen]

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).

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)

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.

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.

[Larkspur]

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.

[bodhi.zazen]

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:

http://www.ubuntu.com/usn

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.

[secret resistor]

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.

Ok, what is the apparmor rule to prevent malicious library calls to XInput, without breaking the application? (keep in mind that the xinput binary is only used as a proof of concept, any application can make the library calls). I was trying to figure it out from the apparmor documentation but I didn't see anything that can do that. If you have such a rule can you post it so that I (and everybody else who is interested) can use it? Thanks.

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.

I haven't tested whether it can log key presses of other users, but xinput test does work for the current user.

It can if (and only if) the user is allowed access to the X session by adding a xhost rule. This is not the case by default, which is what bodhi.zazen was getting at but if you want that user to be able to run any X application without starting a whole new X server then you need to add the xhost rule and if you do that they can query xinput for the keystrokes of any other application using the X session. So, in short if an application can use X it can snoop the keystrokes of every other application using the same X session.

[bodhi.zazen]

Ok, what is the apparmor rule to prevent malicious library calls to XInput, without breaking the application? (keep in mind that the xinput binary is only used as a proof of concept, any application can make the library calls). I was trying to figure it out from the apparmor documentation but I didn't see anything that can do that. If you have such a rule can you post it so that I (and everybody else who is interested) can use it? Thanks.

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.



It can if (and only if) the user is allowed access to the X session by adding a xhost rule. This is not the case by default, which is what bodhi.zazen was getting at but if you want that user to be able to run any X application without starting a whole new X server then you need to add the xhost rule and if you do that they can query xinput for the keystrokes of any other application using the X session. So, in short if an application can use X it can snoop the keystrokes of every other application using the same X session.

If you want to understand apparmor , read the apparmor sticky. I have an apparmor profile for all applications that are networks aware.

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

/bin/foo rwix,

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

[secret resistor]

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.

[bodhi.zazen]

So, in short if an application can use X it can snoop the keystrokes of every other application using the same X session.

But that is like saying ecryptfs is a security risk because if someone knows your password they can decrypt your home directory.

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.