VRDP and PAM authentication

[Sasquatch]

If you ask it that way, open rdp is less secure, as they don't need a password to log on in the first place. Isn't there a process that calls the pam files running under a specific user or group? If it's a not often used group, you might want to give it permission on the file. I don't know what will happen if you chown the file, only one way to find out.

[spindizzy]

I've been having the same problem on my Ubuntu Gutsy server.

Until there's a better way of sorting this out, best practice for now is to add the username that you are running virtualbox under to the shadow group by manually editing the "/etc/group-" (note the minus sign at the end). Find the line "shadow:x:42:" and add the username to the end.

This at least reduces the security hole by allowing only one extra user access rather than everyone.

As far as I can make out after lots of reading on the net, it seems that PAM modules are run with the calling process's UID. Therefore when VBoxVRDP calls login (Specifically the pam_unix.so PAM library) with UID "username", the library cannot access the root-only /etc/shadow.

I can't find a better way to fix this at the moment, but would love to hear about one if it exists. Maybe pam_unix.so could be made SUID root, but would this open a bigger security hole than the above? Security experts, please comment!

Nathan

=============================================
OK scratch the above, it stopped working after a reboot...

Had another go and making the VBoxVRDP binary SETGID shadow seems to solve the problem. Again, I'm not sure of the security implications, so I'd like anyone with more experience to comment, but it seems to my mind that having only one process with shadow abilities is even better than one user (Above) and infinitely better than everyone.

I did the following:

Code: Select all   Expand viewCollapse view

cd /usr/lib/virtualbox
sudo chown root:shadow VBoxVRDP
sudo chmod 2755 VBoxVRDP


I think this is the right way to go about it.

This method has worked fine after a reboot.

Nathan

[ouro]

thanks spindizzy,
your solution works for me, but i can't say nothing about security implications.

[Aero9000]

spindizzy said,

Code: Select all   Expand viewCollapse view

cd /usr/lib/virtualbox
sudo chown root:shadow VBoxVRDP
sudo chmod 2755 VBoxVRDP


and,

I can't find a better way to fix this at the moment, but would love to hear about one if it exists. Maybe pam_unix.so could be made SUID root, but would this open a bigger security hole than the above? Security experts, please comment!:D

while hankedr said,

I don't know the proper solution, although I verified that granting read access to shadow will give success

Thank you everyone for your efforts! This appears to be the solution that works on a Ubuntu server.

Now I am by no means a security expert , but I did do some digging around to see which method should be the preferred one and here are my findings.

Before "/etc/shadow" was introduced, all user accounts and passwords were kept in "/etc/passwd", which still exists today. Among other things, "/etc/passwd" does mapping between user accounts and user IDs and must, for this reason, be world-readable. But the problem with this approach was that any user could copy the contents of "/etc/passwd" to another system and then try to "break" the root-password (or any password) doing a dictionary attack and comparing each password after encryption against the contents of "/etc/passwd". This is why "/etc/shadow" was introduced. On a modern system, with shadowing enabled, the encrypted passwords are kept in "/etc/shadow" rather than in "/etc/passwd". So, making "/etc/shadow" world-readable opens your server to a dictionary attack.

The other method, setting the GID by using the long form of "chmod" is considered more secure, although it still leaves the system vulnerable in case the programme has not been carefully designed.

So unless or until a *real* security expert comes along, the solution by spindizzy is most probably the way to go...


Thanks all and best regards.

[fsalvi]

Hi,

I finally managed to authenticate using rdesktop.
On the server (running gutsy), I run VBoxVRDP -startvm 'Windows XP' with the user "myusername". This username only exists in my LDAP directory, but group membership is provided on local /etc/group

On the client, on use rdesktop -u myusername -p - myserver and it works perfectly. It seems you have to connect to the username which runs vrdp...

[thinkdez]

Just a note that this is an insecure fix. I found this on wikipedia:

The file is world-readable (its contents are visible to all users), but only writable by root. This means that an attacker with access to the system at normal privilege level can obtain the hashed form of every user's password. These can then be used to mount a brute force attack offline, using the hashed passwords as a relatively fast way to test guessed passwords without alerting system security modules designed to detect an abnormal number of failed login attempts. Most users select passwords that are vulnerable to such password cracking techniques.[1]

So unless your system isn't internet accessible I would stay away from this workaround.

I haven't had the chance to try it yet but I will try and start the VM as root and see if that rectifies the problem. I thing that because I am running the VM as a local user it cannot read the shadow file. I will post again to see what happens.

[jhowk]

If anyone is still interested I was able to diagnose (and temporarily resolve) the issue. The issue can be found in the VRDPAuth.so library. Per the manual the VRDPAuth.so library:

The "external" method provides external authentication through a special authentication library. VirtualBox comes with two default libraries for external authentication:
On Linux hosts, VRDPAuth.so authenticates users against the host's PAM system.
On Windows hosts, VRDPAuth.dll authenticates users against the host's WinLogon system.

I assumed the the source for the VRDPAuth library that's distributed is identical to the sample that can be found in

Code: Select all   Expand viewCollapse view

/usr/share/virtualbox/sdk/samples/vrdpauth/VRDPAuthPAM.c


Looking at the source, the issue stems from the PAM api call pam_acct_mgmt. According to the PAM developers guide,

The pam_acct_mgmt function is used to determine if the users account is valid. It checks for authentication token and account expiration and verifies access restrictions. It is typically called after the user has been authenticated.

Which is exactly what is done in the source. As a test I eliminated the pam_acct_mgmt call and recreated the library. Needless to say it worked as expected. Null or bad paswords were rejected and valid passwords were accepted.

I'm still trying to find out what exactly pam_acct_mgmt is _really_ doing. By default the VRDPAuth library defaults to the "login" service, so it's there somewhere.

--J.

[jhowk]

I finally found a workable solution that will work for everyone (at least for the PAM challenged folks.) It's more secure that setting group suid bits on VirtualBox and you're not hacking the user to be a member of the shadow group. I'm running on Ubuntu 7.10 so your setup may vary slightly...

[EDIT: This is still valid through version 1.6.6]


You have two options depending on your comfort level (both tested and verified).

1.) Modify your existing /etc/pam.d/login file(s)
2.) Create a custom PAM service in /etc/pam.d


FIRST OPTION

The VirtualBox provided VRDPAuth.so library defaults to using the /etc/pam.d/login service so changes have to be made there. In Ubuntu, the existing /etc/pam.d/login file includes pointers to other /etc/pam.d files, namely common-account that actual do the work (referenced by an @ in the file), so we need to modify /etc/pam.d/common-account.

My default /etc/pam.d/common-account look like:

Code: Select all   Expand viewCollapse view

#
# /etc/pam.d/common-account - authorization settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authorization modules that define
# the central access policy for use on the system.  The default is to
# only deny service to users whose accounts are expired in /etc/shadow.
#
account required        pam_unix.so


To fix, append "broken_shadow" to the account line. E.g.

Code: Select all   Expand viewCollapse view

account required        pam_unix.so broken_shadow


This fixes the issue with minimal changes to your system. The impact of this change is that the change is valid for ALL services that use common-account.

SECOND OPTION

If your concerned about modifying a default PAM service, we can create our own. To resolve this issue using a custom PAM service:

1.) Create a new file named /etc/pam.d/vrdpauth (or whatever your want)
2.) Add this to the following file.

Code: Select all   Expand viewCollapse view

auth       required     pam_unix.so
account    required     pam_unix.so broken_shadow


3.) In order to use a custom service you must either set the VRDP_AUTH_PAM_SERVICE environment variable (or recompile the library). So...

Code: Select all   Expand viewCollapse view

jhowk@host:~$ export VRDP_AUTH_PAM_SERVICE=vrdpauth


That's all that's needed. Easy fixes. If anyone has any questions just let me know.

--J.

[Murz]

Host system is Debian Lenny AMD64, virtual box is Windows XP SP2.
I try to go with SECOND OPTION method.
In VirtualBox I set the VRDP Authentication Method to External.
At this state I can succesfully connect via RDP to virtual host with user that run virtual machine and with any password (correct, wrong and empty). With other usernames I can't connect.
I create /etc/pam.d/vrdpauth file and set the variable "export VRDP_AUTH_PAM_SERVICE=vrdpauth".
After that I also can connect with any password and owner user.
What I do wrong?

In debug file I see:

Code: Select all   Expand viewCollapse view

u[qseo], d[], p[10]
init ok
Using PAM service: vrdpauth
start ok
auth ok
access granted
vrdpauth_pam_close completed


[jhowk]

In debug file I see:

Code: Select all   Expand viewCollapse view

u[qseo], d[], p[10]
init ok
Using PAM service: vrdpauth
start ok
auth ok
access granted
vrdpauth_pam_close completed


What does your vrdpauth look like and what version of vbox are you using?

[Murz]

The problem was solved when I update the VRDPAuth.so from this ticket: http://www.virtualbox.org/ticket/1953

[jhowk]

Glad you got it worked out.