Linux XServer Security

In linux when you download a file it come without he executable flag not is ?
So the same will apply to a driveby right?

 

Yes, but javascript, flash etc run on browsers and can execute the same attacks without anything being downloaded.

 

And do what in Linux?

 

1. Snoop through folders and send data.
2. Log keystrokes, this compromises root passwords for people who use sudo and enter passwords in a user x-session Also compromises bank passwords and logins..
3. Install malware (the scripts could change the execute flag and then inivoke malware to run; or if an xterm window is open, use that to send commands to, to install malware). In addition, if the root password is observed, then malware can be installed as root.

 

I'm back with some new findings.
First Apparmor:
I've used Ubuntu 10.04 i686 in a live session and focused on the default firefox profile. Both POC from above refused to load because the profile didn't allow access to libX11.so.6. Adding that to the profile resulted in a working keylogger.
As far as I understand this particular Xorg design is based on what is called IPC or inter process communication and as of yet Apparmor does not confine this. Its path based security however still is able to block most if any common POC (let alone malware) out there as demonstrated.

Now to SELinux. A (really short) bit of personal history:
When I first learned about it I thought it could be exactly what I had been locking for. I played with it for an hour or so and when I learned that I had to write policies in a special programing language and then compile them I just gave up. Nothing for a non-programmer I thought. Maybe one day it'll become more enduser friendly.

Because of this thread I looked into SELinux again and I have to say this is the most exciting open source project. It's still not "easy" to use but they've added several tools that make it a lot easier than before. The great thing about SELinux is that it's so powerful that's it's basically able to offer a solution for even theoretical security issues.
It's really no surprise that the SELinux people also thought about Desktop and of course Xserver security. They've come up with several approaches. The easiest way is to run a confined app in its own xserver. On Fedora sandbox -X does exactly that (using Xephyr see: http://danwalsh.livejournal.com/31146.html). The xguest kiosk user in Fedora also seems to be running on a separate X Server (tty7 while the other users are on tty1).
The proper SELinux way of doing things (i.e. complicated) is XACE, this paper gets into some details: http://www.nsa.gov/research/_files/selinux/papers/xorg07.pdf
Also see this blog post for some further reading and a more high level overview
http://securityblog.org/brindle/200...x-or-how-we-are-going-to-take-over-the-world/ it's from 2006 but the lable "future of selinux" still holds true.

Bottom line: xguest, sandbox -X and even the normal sandbox which runs apps on the same X server all stop this keylogger POCs, I don't know enough SELinux to test wether the default setup of Firefox and other "risky" apps (evince, acroread...) prevents them from running.

edit: It's Ubuntu 10.0_4_ of course

 

Mucho gracias Katio!!!

How do you add libX11.so.6 to a profile?
How do you find out a profile doesnt allow access to libX11.so.6?
How do you load the POC?
When I try to open the executable (simply with firefox->open), I get a"save" option and a "cancel" option for the file.

Guess I will be learning to program SElinux!!

 

Maybe a bit of cheating but I don't know of a simpler way to test Apparmor:
I put the keylogger into .mozilla/firefox/user/extensions which is the only place firefox has both write and execute access, otherwise no dropper/binary exploit works anyway.
Then
sudo cp /etc/apparmor.d/usr.bin.firefox /etc/apparmor.d/keys
edit the keys profile and replace /usr/lib/firefox-3.6.8/firefox-*bin with the path to the keylogger
sudo aa-enforce /etc/apparmor.d/keys
run keylogger
you'll get an error about libX11.so.6 which is located at /usr/lib/libX11.so.6 so I added that path to the profile *
run aa-enforce /etc/apparmor.d/keys again to reload
run keylogger again: it works!

* maybe it works for you right away, I didn't really use the default profile I think but a more slimmed down version. I just saw in the default there's already this line:
/usr/lib/** rm,
You might need to add ix (so it says rmix,)

 

How are you running the keylogger from firefox? I have it copied into the extensions folder. I dont have apparmor (I use debian), so I have to look into that part.
Anyone have any javascript code to invoke the keylogger program from firefox?

 

Oh right, the important part of the trick was missing!
I simply run it in the terminal but because I use the same profile as firefox it runs with the same restrictions as it would if it was triggered through a browser exploit.

 

Er, how do you use a firefox profile to run the keylogger program in a terminal?
How do you use a profile at all in a terminal?

 

By using the /etc/apparmor.d/keys which is a copy of the firefox profile (see above) I confine the keylogger binary itself.
I could also create a confined user or a confined shell (that's what I usually do to test AA) and then launch the keylogger which inherits the restrictions through ix.

This is how you can make a confined shell:
symlink /bin/bash to /bin/bashconfined or something like that and write a policy for that new binary. Now open a terminal, type bashconfined and launch any apps.
If your profile contains a ix rule for the path of that app it will inherit the bashconfined proflie.

Hope it's somewhat clear. AA is really lacking consistent and high quality documentation.

 

Got it, the firefox profile was with respect to AppArmor --- I did not realise that!
Debian does not have AppArmor; so I will have to learn SELinux.
But first, I'd like to learn some javascript to demo this attack in a browser

 

A great read. Thanks, katio.

I really need to find the time to pick up AppArmor someday.

 

Will AppArmor protect against this type of exploit?

 

Against what kind of exploit? Where do you see an exploit?
Why the sudden rush of fear and paranoia?
Mrk

 

Because a failed Windows fanboi hacker spread the FUD, probably paid by Redmond to do so

 

Update about Apparmor:

I first used a live CD as described above. The keylogger wouldn't run because of that libX11.so.6 error. But as I now found out that's because the profile doesn't work on the live cd. Since it's a read only media the OS has to work around this limitation by using rofs. This changes the filesystem hierarchy, /usr/lib/ is mounted as /rofs/usr/lib in the live session. The AA profiles are written for the normal installed system. Most apps need access to a few *.so in /usr/lib/. There is even an allow-rule in the "base" abstraction for that. What this means is that ALL confined apps by default have access to said file (rm to be specific) therefore AA does not block the function of these keyloggers once they have been executed. The only protection AA offers is to block the execution in the first place.

If you know SRP or Applocker from Windows you'll be familiar with this concept:
Do not allow execute and write permissions to the same directory. This simply stops all such malware from even running on your system.
In the case of firefox you only have to remove ix in
owner @{HOME}/.mozilla/**/extensions/** mixr,
However this might break some functionality.

The only problem with that is that it does not stop interpreted code from running. Most such code is written in C or similar but can be ported with more or less effort to perl or python. But Apparmor has a solution for that too, don't allow access to those interpreter /usr/bin/perl and /usr/bin/python), defaul profiles do that except when it would brake the app from running.

What I learned from this is that Apparmor is not really a solution for privilege separation, trying to do that quickly becomes an ugly hack and patches only symptoms not the underlaying cause.

Where's the FUD? Just because one says there is a possibility to exploit a design flaw in xorg doesn't mean "Linux is doomed, Windows is your saviour".
So there is no exploit because everything works as intended. Does that mean this shouldn't be fixed? For a lot of devs security is yet another burden just like writing documentation, it then gets bolted on instead of being an integral part of the design phase. Are suggesting you support this kind of mindset that got MS into that corner they are still trying to get away from?

 

I thought Linux was supposed to be secure by design. So now it's only secure because there are currently no known exploits?

Given that people conduct the discussion with an understanding of the scope and possible repercussions of this design flaw in mind, I wouldn't be so hasty to quash a very useful and informative discourse by accusing its participants of paranoia.

 

AFAIK, Windows suffers from the same issue.

 

Windows has UIPI since Vista.

 

How does that prevent keylogging?

 

UIPI wasn't intended as keylogger protection but addressed the underlaying problem.
Keylogging is just an example for the consequences of this design in XServer: applications aren't isolated against each other, all windows on the same X Server have ways to access and control each other. AFAIK Windows didn't have a problem with keyloggers but instead with applications sending input (like keystrokes) to other applications. If you recall the latter is also a concern with the Xorg issue at hand.
Windows has a completely different architecture but before UIPI graphical applications weren't securely isolated against each other. With UIPI processes running under different integrity levels are restricted what they can do to each other, e.g. a browser running in LOW can't access Windows Explorer running in MEDIUM which in return can't access your Admin console running in HIGH.

There are some limitations in its implementation, as of now this means only IE is really protected. Guess why.

 

Thanks for the explanation...There seem to be quite a few restrictions. AND it doesnt work in XP.
So, the general advice in windows is to always do CTRL+ALT+DEL before entering the system password?
And for online passwords, use an anti-keylogger?

 

And many others

 

Suppose I am running two users concurrently. Either via the same xserver, or via two simulaneously running xservers.
Can then a malicious process in one account access the events in the other account?