Ubuntu Guest Account Security

Posted: November 22, 2011 in Random pontifications
Tags: , , , , ,

Lately there has been a lot of hullabaloo about the Ubuntu Guest Account seen in Oneiric, though it’s been around for a while the feature has become much more visible. As such it has a lot of people having bad flashbacks from the Windows NT series Guest account. An interesting article written by Dan Dieterle at Cyber Arms addresses some of those concerns, and makes a valid point regarding a Social Engineering attack or some form of remote browser exploit.

The article warns users that a guest user could become the victim of a social engineering attack that leads to remote compromise, also scary is the fact that Firefox 7.0.1 POC exploit code has recently been released into the public that allows for remote compromise of the browser. What we’re going to explore here is, in the event this happens. What protections do this account offer, and is it in fact a security liability. The Guest Session account in case you do not know, does not require a password to access. For this discussion we will be using the Social Engineering Toolkit Java Applet vector that was discussed in Dan’s article, though it’s important to know a remote shell is a remote shell. For the “victim” machine we will have a fully patched Ubuntu 11.10 install , with a default configuration of UFW enabled. I’m not going to bother with AV for two reasons. One AV on Linux sucks (particularly the free products) and two our shell will never hit the hard drive so there is really nothing for AV to find here

Our Shell

As I pointed out in the discussion on Dan’s blog, the shell we get here would be extremely neutered, and as we can see it is. Guest really doesn’t have a whole lot of permissions to do much of anything. However Dan’s counter argument was that the shell could be used to profile the system, an argument that in this case is quite valid.

If you click this you're pretty much dumb...Let's click it ๐Ÿ˜›

oh look another shell ๐Ÿ™‚

Well that's fancy lol.

We were able to gather the usernames for the system. This could be valuable to a remote attacker in the event that you are one of those Ubuntu fans who like to run SSH on their home system to administer it from work. However, what if they aren’t running any services and this is just a typical desktop installation?

So the question is can we break out of this shell and do something more malicious? Sadly not really, As I stated in my discussion over on Cyber Arms there are a variety of security features locking this account down.

What Security Features?

Don’t let the lack of a password on this account fool you. It’s locked down pretty tight. The Guest Session is confined with mandatory access controls in the form of Apparmor. There are two things someone who is trying to compromise a system running no services doesn’t want you to have, NoScript and Mandatory Access Controls. In this case we don’t have No Script installed, and if the user was silly enough to click our Java Applet warning despite the gigantic Security advisory posted all over it Apparmor will confine the disaster to being almost fruitless.

If we examine the apparmor profile (which can be found in /etc/apparmor.d/lightdm-guest-session). We will see the following.

# vim:syntax=apparmor
# Profile for restricting lightdm guest session
# Author: Martin Pitt


/usr/lib/lightdm/lightdm-guest-session-wrapper {
/etc/compizconfig/config rw, # bug in compiz https://launchpad.net/bugs/697678

/ r,
/bin/ rmix,
/bin/fusermount Px,
/bin/** rmix,
/cdrom/ rmix,
/cdrom/** rmix,
/dev/ r,
/dev/** rmw, # audio devices etc.
owner /dev/shm/** rmw,
/etc/ r,
/etc/** rmk,
/etc/gdm/Xsession ix,
/lib/ r,
/lib/** rmixk,
/lib32/ r,
/lib32/** rmixk,
/lib64/ r,
/lib64/** rmixk,
/media/ r,
/media/** rmwlixk, # we want access to USB sticks and the like
/opt/ r,
/opt/** rmixk,
@{PROC}/ r,
@{PROC}/* rm,
@{PROC}/asound rm,
@{PROC}/asound/** rm,
@{PROC}/ati rm,
@{PROC}/ati/** rm,
owner @{PROC}/** rm,
# needed for gnome-keyring-daemon
@{PROC}/*/status r,
/sbin/ r,
/sbin/** rmixk,
/sys/ r,
/sys/** rm,
/tmp/ rw,
owner /tmp/** rwlkmix,
/usr/ r,
/usr/** rmixk,
/var/ r,
/var/** rmixk,
/var/guest-data/** rw, # allow to store files permanently
/var/tmp/ rw,
owner /var/tmp/** rwlkm,
/{,var/}run/ r,
# necessary for writing to sockets, etc.
/{,var/}run/** rmkix,
/{,var/}run/shm/** wl,

capability ipc_lock,

# silence warnings for stuff that we really don’t want to grant
deny capability dac_override,
deny capability dac_read_search,
#deny /etc/** w, # re-enable once LP#697678 is fixed
deny /usr/** w,
deny /var/crash/ w,

Now, if you don’t understand Apparmor profiles, I’ll basically sum this up — This profile does not allow you access to much of anything that allows an attacker to escalate out of the guest session. There are a few caveats to that which I will discuss in a moment.

In addition to the mandatory access controls in place via Apparmor we have a well tuned discretionary access control system (permissions) in place that keeps us out of most places we should not be.

As a matter of fact, I could not find a single flaw in the implementation of the guest session save for one.

Why In Heaven’s Name Would Guest Need GCC?

This was the one issue that I saw for some reason unknown to me, the Guest Session is given access to a compiler. This is generally bad stuff. If one can compile source code, and execute it. There is a chance that escalation can take place. This would require a vulnerability in another application and or the Kernel itself. If this were present it could be exploited to allow root access bypassing even Apparmor. That being said, we can use Apparmor to nip that in the bud really quickly.

Simply add the following lines to your apparmor profile

deny /usr/bin/gcc rw,
deny /usr/bin/gcc-4.6 rw,

Since the author of that profile was so kind as to comment on this blog post I figured I would add this bit in. As Martin pointed out this does NOT prevent someone from downloading GCC to the guest session and running it from a different path. Nor does it prevent an attacker from utilizing Perl,Python, or whatever else might be installed. (remember how we got here was Java).

As I reflected on Martin’s comment I feel this is probably an irrellevant measure (this is what I get for writing this stuff at 1 AM).


Honestly, I would say the Guest session is rather well secured, however you can always edit the MAC in place to lock it down further. Or as Dan Dieterle mentioned in his article disable the account functionality alltogether. If you’d like to know how to do that read his article he explains it, it is linked at the top of this one.


Also for those of you who use SET frequently, and or are experimenting with the Java Applet Attack Vector under Linux, you might consider upgrading the shell you are provided by default to meterpreter instead of the linux default reverse shell. If you wish to do this simply run the following (this is under Back Track 5 R1, your path may vary.)

sed -i 's:linux/x86/shell/reverse_tcp:linux/x86/meterpreter/reverse_tcp:' /pentest/exploits/set/src/core/payloadgen/create_payloads.py

This will give you a meterpreter shell by default instead of linux/x86/shell/reverse_tcp. You can substituate linux/x86/meterpreter/reverse_tcp for any other payload you’d like as well, including a custom payload.

Special Thanks also go to Martin Pitt for his comment that shed some light on the MAC in place for the lightdm-guest-session.

  1. dangertux says:

    Gah…Sorry to anyone who read that when I first posted it. Apparently WP decided it was going to destroy all forms of formatting tonight. ๐Ÿ˜ฆ

  2. Martin Pitt says:

    Thanks for the test! Two comments:

    * I’m aware that leaving /etc/passwd readable is a bit of a wart. But generally denying read access to it breaks a lot of things. But in general, if there are files in /etc/ which DAC does not already block, but should be hidden from guest, I’d appreciate a bug report/mail/etc. to get this fixed.

    * Denying access to /usr/bin/gcc and the like doesn’t buy you anything. You can download any compiler you want from the net and run it locally. Also, you can access pretty much anything with Python, Perl, or other installed interpreters. What a MAC profile needs to do is not limit access to tool chains, but limit access to the actual objects on your hard drive/system that you want to protect. The binary code of gcc is not at all a secret ๐Ÿ™‚

    Given that using the guest session implies physical access to the machine, all of this discussion is a bit academic anyway. As long as the attacker is being watched, running above Java etc. exploits will raise some eyebrows, and as soon as an attacker gets your machine under no supervision, he can just reboot and acquire full root privileges that way.

    • dangertux says:

      Martin —

      Thanks for the fabulous feedback. I appreciate you taking the time. Your points are also very accurate. Something to keep in mind though, I tried to keep this in the context of a remote attacker, hence the silly little SET demo. When you get down to local access you are correct there is absolutely nothing that keeps someone from dropping to a recovery shell and doing whatever they want.

      On /etc/passwd, yeah it breaks everything and it’s not the end of the world. In the case I used with SSH that really doesn’t even fall into security of the Guest Session so much the SSH service itself. If that is secured properly having the username shouldn’t be that big of an issue anyway.

      I agree with you to an extent on MAC and the compiler issue. When I was playing with this I did exactly what you said and ended up “upgrading” my shell slightly by injecting a new one written in perl.

      Ultimately my point was in context of the original article I quoted, basically trying to say that the guest session is really no less secure than an average user. Obviously as you pointed out the intended use case would be for a local user utilizing a computer that doesn’t belong to them.

      Again the Guest Session can’t secure everything by itself, a lot is dependent on the relative security of the system itself. In the case of the SSH service I briefly discussed if the service is secure, having access to /etc/passwd isn’t a big deal. In the case of local escalation, if the sysadmin or owner is keeping up on their updates they shouldn’t be finding an overtly vulnerable kernel that could be leveraged easily.

      Of course if you couple that with the fact that the guest session is likely not going to be used as heavily as the default user an attacker gaining a shell of this nature wouldn’t necessarily have time to go hunting for ways to escalate either.

      So TLDR ; I agree with you — I’ll post if I see anything with wrong with DAC but so far looks like a great job ๐Ÿ™‚

      Thanks again for the feedback I appreciate it.


  3. Boo Hoo says:

    The guest can use
    dd if=/dev/zero of=/var/tmp/.foo
    after a while syslog cannot write another log message for lack of disk space.

    Then you can
    dd if=/dev/zero of=/run/shm/.foo
    and no more free /run/shm (aka /dev/shm) space

    Then you can
    dd if=/dev/zero of=/run/lock/.foo

    • dangertux says:

      This is true but you can do this as any user. dd does not require sudo to use and those directories are all world writeable.

      It is not necessarily a “compromise” as it would only lead to a spin lock and eventually a reboot.

      Thanks for the reply

  4. dangertux says:

    Alternatively you could experiment with trying to lock down the dd command , but that would be silly since you could just

    python -c ‘print “A” * 120391209381293810293812903812’ > /dev/shm/.foo


    OR you could attempt to grant only r access to those directories which might work, but could break some applications (most web browsers come to mind).

    So it’s the lesser of all evils I suppose.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s