VRDP and PAM authentication

Discussions related to using VirtualBox on Linux hosts.

Postby Sasquatch » 30. Mar 2008, 15:46

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.
Read the Forum Posting Guide before opening a topic.
VirtualBox FAQ: Check this before asking questions.
Online User Manual: A must read if you want to know what we're talking about.
Howto: Install Linux Guest Additions
Howto: Use Shared Folders on Linux Guest
See the Tutorials and FAQ section at the top of the Forum for more guides.
Try searching the forums first with Google and add the site filter for this forum.
E.g. install guest additions site:forums.virtualbox.org

Retired from this Forum since OSSO introduction.
Sasquatch
Volunteer
 
Posts: 17800
Joined: 17. Mar 2008, 13:41
Location: /dev/random
Primary OS: Debian other
VBox Version: PUEL
Guest OSses: Windows XP, Windows 7, Linux

Postby spindizzy » 31. Mar 2008, 20:17

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! :lol:

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
spindizzy
 
Posts: 1
Joined: 31. Mar 2008, 17:14

Postby ouro » 1. Apr 2008, 16:19

thanks spindizzy,
your solution works for me, but i can't say nothing about security implications.
ouro
 
Posts: 11
Joined: 10. Mar 2008, 15:06

Postby Aero9000 » 1. Apr 2008, 16:58

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 :D, 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.
Aero9000
 
Posts: 13
Joined: 19. Feb 2008, 15:49

with ldap server...

Postby fsalvi » 9. Apr 2008, 17:29

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...
fsalvi
 
Posts: 3
Joined: 26. Feb 2008, 17:31

Insecure Shadow File

Postby thinkdez » 16. Apr 2008, 23:50

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.
thinkdez
 
Posts: 1
Joined: 16. Apr 2008, 23:42

Re: Insecure Shadow File

Postby jhowk » 8. May 2008, 00:22

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
 
Posts: 17
Joined: 19. Sep 2007, 00:00
Primary OS: Ubuntu other
VBox Version: PUEL
Guest OSses: Any and All

SOLUTION!

Postby jhowk » 8. May 2008, 23:13

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.
Last edited by jhowk on 4. Sep 2008, 03:31, edited 1 time in total.
jhowk
 
Posts: 17
Joined: 19. Sep 2007, 00:00
Primary OS: Ubuntu other
VBox Version: PUEL
Guest OSses: Any and All

Virtualbox accept any and empty passwords when VRDP login

Postby Murz » 20. Aug 2008, 13:44

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
Murz
 
Posts: 16
Joined: 20. Aug 2008, 13:36

Re: Virtualbox accept any and empty passwords when VRDP logi

Postby jhowk » 3. Sep 2008, 06:19

Murz wrote:
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?
jhowk
 
Posts: 17
Joined: 19. Sep 2007, 00:00
Primary OS: Ubuntu other
VBox Version: PUEL
Guest OSses: Any and All

The problem was solved when I update the VRDPAuth.so

Postby Murz » 3. Sep 2008, 08:50

The problem was solved when I update the VRDPAuth.so from this ticket: http://www.virtualbox.org/ticket/1953
Murz
 
Posts: 16
Joined: 20. Aug 2008, 13:36

Re: The problem was solved when I update the VRDPAuth.so

Postby jhowk » 4. Sep 2008, 03:30

Glad you got it worked out.
jhowk
 
Posts: 17
Joined: 19. Sep 2007, 00:00
Primary OS: Ubuntu other
VBox Version: PUEL
Guest OSses: Any and All

Previous

Return to VirtualBox on Linux Hosts

Who is online

Users browsing this forum: dpai, jjalocha and 24 guests