Keylogging on Linux as a limited user

I've heard it said that logging keystrokes as a limited user is not possible, or is at least very difficult, on Linux.

But doesn't xbindkeys basically do this? xbindkeys runs as limited user, intercepts keystrokes, and uses them to launch applications. What would prevent someone from writing a program like xbindkeys that logged each keystroke but let it through? Is there something about the way keyboard input works on Linux that I don't understand?

(And I realize the above would probably be wasted effort - it would be hard to hide as limited user, and with mostly plaintext configuration files, an experienced user could easily notice it. OTOH, a novice using the GUI exclusively might never notice.)

 

I would think that you would have to have root in order to execute anything or even change a programs code.

 

Yes, and it's a big issue with X. Wayland solves this. Until then keylogging seems a bit too easy.

edit: If you have a profile apparmor'd it may not allow keylogging to work though. With X you registers keys through X, apparently with Wayland you have to register them through the OS (which will require root.)

 

Thanks. Would OpenBSD's privilege separation (X being split into root and limited user components) provide any protection against this?

Re Wayland... That sounds nice, but I really do not like the core ideas of Wayland. Wayland runs only on Linux, and as I understand it requires either KMS supporting hardware or a very fast CPU. I know Xorg has a lot of failings, but IMO it would be much better to have a cross-platform solution, and one that didn't necessarily require a modern computer.

@kjdemuth: you can definitely execute arbitrary stuff as non-root on Linux, though some distros let you harden against that (e.g. by mounting user-writable areas as noexec,nosuid). And I'm sure it's possible to inject .so files into running applications, a la DLL injection - IIRC shared libraries create all kinds of vulnerabilities on all kinds of platforms. With loadable shared libraries you don't need to change the code of the actual application.

That's high-end stuff though, I'm thinking more of a drive-by install of a normal CLI application that runs in the background on your next desktop session (and just happens to log your keystrokes and send them back to a blackhat). This would be *very* easy for an experienced user to notice - anyone looking at the output of top would figure it out fast. But a novice wouldn't, and it wouldn't have to be around for long anyway to do its job.

To elaborate, the process would be:
- User visits malicious website
- Website places the malware in their home dir as ~/.keylogger
- Website then puts a FDO desktop file, keylogger.desktop, in ~/.local/share/autostart to start the keylogger automatically on login
- Next time the user logs in, their keystrokes are logged.

This is the most primitive sort of malware, and 90% of Linux users would probably notice it the day they were hit. But there are plenty of ways to nastify it. I'll leave those possibilities to your imagination.

P.S. The above is actually not that different from how a fake antivirus works, at least from what I've personally seen.

 

No idea what OpenBSD would or would not do and the same goes for all of the BSDs. I also really have not looked into X v Wayland, I just picked this bit up somewhere.

Just avoid drive by downloads, it isn't hard. The Chrome sandbox on Linux is as of now unbroken (and it's going to remain that way for a long time) and AppArmor/SELinux are enough to stop most exploits and contain the rest.

 

I'm not particularly worried about this happening to me, mind; I don't think anything like that is even in the wild. Linux is too small a target.

 

This is incorrect. You need root permissions to access /dev/keyboard or whatever node is used to abstractize the keyboard. Small edit: Creating dev nodes too, which is what you want to do if you want to log key strokes. Hence, the problem you mention is non-existenent.

Mrk

 

https://grepular.com/Protecting_Your_GNU_Linux_System_from_Dropbox

 

What has that article to do with anything? Except being quoted as supposedly a proof of a security breach, which I repeat is nonsense. Users can only access their own user space. Access to devices depends on permissions, but hooking the keyboard by default takes root. You can trust me or enjoy paranoia for your own pleasure.

He wants to disallow dropbox from accessing files that are supposed to be shared. Sounds like a paradox.

Now, as a user you can redirect file descriptors to files and all that, all dandy, but from the programming point of view, you need system calls that will do the relevant actions. And then, it's no longer shell, it's system devices and system functions and system calls, and we go back to my initial point.

Mrk

 

You know what, let's do an exercise together.
You claim whatever you want and I will show you why not.

Say there's a process called baddie running in memory. You managed to get it started, it's running and all that.

What next?

Mrk

 

It's not my claim, it's "mike"'s. According to Mike the compromised Dropbox will be able to view keystrokes on all other processes of the same UID.

Is this not correct?

 

How was dropbox installed - with sudo apt-get install dropbox?

sudo ... dropbox ... my point exactly. The program was allowed access to various devices. It places its shared libraries under /usr and /lib and whatever, and these libs now stored there are root owned and can access devices like keyboard and screen and whatnot.

To see keystrokes you need to be able to acces the /dev/keyboard device, this takes root. To read file descriptors (like stdin, stdout, stderr) of processer you own, this can be done in user space via simple shell commands and access to /proc. But you might not necessarily see anything meaningful there, not pure keyboard strokes (device key interrupts), but the representation of those keys if at all. For example, the process can in memory edit keystrokes to be written to file as something else or even not write anything anywhere.

Moreover, how would you intercept key strokes - at what intervals would you poll the user space, look for some process and its file descriptors and try to read from them? Once a second? Once every millisecond? It's not trivial at all.

Now, you could create a device node with the same major and minor as keyboard, which then makes things easier, but again, you need root for that.

Mrk

 

I don't see what your point is. Is Mikes assertion that Dropbox can read and interfere with key commands of other applications correct or incorrect?

edit: And you've edited a lot in...

And according to Mike if you share a UID with another process you can access their keystrokes. So I'm just asking if Mike is wrong.

 

OK, let's not argue semantics.

What exactly does access their keystrokes mean?

Access keyboard?

If so, dropbox was installed with sudo (root). It has its shared libraries placed in the system; these libs can create their own device node with the same major minor as the keyboard or can access /dev/keyboard. If so, then yes.

Access /proc from user space and grab FD content?

In this case, processes live in their own memory space, isolated from one another. Processes cannot directly access memory pages owned by other processes, unless they share libraries, pages are accessible and readable, and such. Let's leave threads aside for now.

A process could try to use user land commands, like cat/grep to try to access content under /proc and get to redirect FD; this might work, if you are owner of relevant processes, which you are, and therefore can do just that. However, it brings the question, what would the output be?

If the process you wish to keylog does not redirect its output in a meaningful manner to stdout, stderr or elsewhere, you get garbage. Firefox was mentioned. My guess is that Firefox does key stroke mainipulation directly in memory, otherwise it would be rather insecure so to speak, hence the standard output and such contains no actual keystrokes, but products of these strokes, like may a log, an HTML page, etc.

Therefore, keylogging from user space, for any posix process, is not possible, not in the sense of you being able to intercept the actual key strokes abstractization, from keyboard interrupt to memory.

So, dropbox can do damage - but it was installed as ROOT - hence all is well then. You might as well take a shared library called hax0r.so, place it under /lib, and then have your userspace program called shell.sh use that lib and it will do the key thingie for you, or anything else. But again, shared library, with system wide access to devices, root.

Mrk

 

I think this is where the disagreement is. From what I've read X 'bridges' that isolation. This is a feature of X, the ability to send/ sniff input in other applications. It's not about hooking the keyboard, it's about using a feature of X to keylog.

Wayland would handle this differently.

http://lists.freedesktop.org/archives/wayland-devel/2011-January/000519.html

I'm getting this from here:
http://www.reddit.com/r/linux/comments/uds8c/wayland_and_security/

edit: And I'm not trying to argue semantics. I'm just asking if what Mike said is true or not

 

Umm, wait a minute. Mrkvonic, you say that Dropbox is installed as root, owned by root, and therefore can create and access device nodes.

But wouldn't that assume Dropbox is running suid root? If it's running as limited user it won't be able to do those things. Firefox on my system is installed as root and owned by root, but when running as my limited user it can't do those things, any more than a bash shell can.

Xorg on the other hand runs as root on most Linux distros, and can access and create device nodes. Doesn't that open up all kinds of vulnerabilities for processes that can communicate with it?

 

I am saying there's a difference between a dropdown script from a website and a deliberate install. It makes no difference that the process actually runs as a different user with euid and whatnot set to something else. It does from the security perspective, afterwards, but it highlights the point of entry. The whole point is that the software functionality is based on the fact you will grant it some elevated privileges during the install, so it can do something.

The fact something runs as root does not open vulnerabilities. They might exist, but that does not mean there's a security problem or anything for you to worry about. If and when these pop up, they are patched, end of story.

So I believe you will not find an example that shows how you can keylog through the X stack, since this would constitute as a vulnerability and would have been patched. There's a difference between if and is. In theory, we could die of a cosmic gamma ray burst, but do you worry about it?

Mrk

 

What do I get if I show you the vulnerability?

I want to know before I post it.

 

What do you want?
Mrk

 

Too much pressure. Anyways, from the link I posted he shows it's possible.

You can open up a terminal and do this yourself to see how it works.

AppArmor would probably interfere with this and it won't work with Chrome (as it runs under a separate UID already.)

I can confirm that it works on my system.

edit: Actually my Apparmor'd pidgin doesn't stop it.

https://www.wilderssecurity.com/attachment.php?attachmentid=233241&stc=1&d=1339267873

 

Oh, hey. Looks like it works for Chrome too.

 

Doesn't count. I want a working example, not you hacking yourself in a terminal.
I want an actual exploit so to speak that can do this - and hasn't been patched.
Mrk

 

wat

That... that's it. That's literally it. I just showed you that a non-root terminal can log keys.

Pick literally any remote code execution exploit for Linux and there you go. Hell there was an Adobe patch recently just google for one of those if you need to see it on your screen lmao

 

So I'm trying really hard to understand your overall point of view on security, MrKvonic. Because frankly I've been totally confounded by some of your statements on wilders and your blog. (BTW, FWIW I'm a fan of your blog. I have linked to it from my own and even given friends links to it for them to enjoy. I'm not personally attacking you, I'm just trying to get you).

Here's how I understand your stance on security for the average desktop user, please correct me where I'm wrong (as I'm sure I am somewhere):

I presume that your stance on security is different when one is discussing an enterprise, or even a personal server. Or at least I hope it is.

 

Yes, you're right.

And we're definitely not discussing servers here.

If you want, we can do that, too.

Hungry, let's do an strace run on those shells to see what system calls are used. It will be an interesting exercise.

Mrk