VRDP and PAM authentication
-
- Volunteer
- Posts: 17798
- Joined: 17. Mar 2008, 13:41
- Primary OS: Debian other
- VBox Version: PUEL
- Guest OSses: Windows XP, Windows 7, Linux
- Location: /dev/random
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.
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.
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 "shadow42:" 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:
I think this is the right way to go about it.
This method has worked fine after a reboot.
Nathan
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 "shadow42:" 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
cd /usr/lib/virtualbox
sudo chown root:shadow VBoxVRDP
sudo chmod 2755 VBoxVRDP
This method has worked fine after a reboot.
Nathan
spindizzy said,
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.
and,Code: Select all
cd /usr/lib/virtualbox sudo chown root:shadow VBoxVRDP sudo chmod 2755 VBoxVRDP
while hankedr said,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
Thank you everyone for your efforts! This appears to be the solution that works on a Ubuntu server.I don't know the proper solution, although I verified that granting read access to shadow will give success
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.
with ldap server...
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...
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...
Insecure Shadow File
Just a note that this is an insecure fix. I found this on wikipedia:
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.
So unless your system isn't internet accessible I would stay away from this workaround.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]
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.
-
- Posts: 17
- Joined: 19. Sep 2007, 00:00
- Primary OS: Ubuntu other
- VBox Version: PUEL
- Guest OSses: Any and All
Re: Insecure Shadow File
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:
Looking at the source, the issue stems from the PAM api call pam_acct_mgmt. According to the PAM developers guide,
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.
I assumed the the source for the VRDPAuth library that's distributed is identical to the sample that can be found inThe "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.
Code: Select all
/usr/share/virtualbox/sdk/samples/vrdpauth/VRDPAuthPAM.c
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.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.
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.
-
- Posts: 17
- Joined: 19. Sep 2007, 00:00
- Primary OS: Ubuntu other
- VBox Version: PUEL
- Guest OSses: Any and All
SOLUTION!
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:
To fix, append "broken_shadow" to the account line. E.g.
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.
3.) In order to use a custom service you must either set the VRDP_AUTH_PAM_SERVICE environment variable (or recompile the library). So...
That's all that's needed. Easy fixes. If anyone has any questions just let me know.
--J.
[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
#
# /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
Code: Select all
account required pam_unix.so broken_shadow
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
auth required pam_unix.so
account required pam_unix.so broken_shadow
Code: Select all
jhowk@host:~$ export VRDP_AUTH_PAM_SERVICE=vrdpauth
--J.
Last edited by jhowk on 4. Sep 2008, 03:31, edited 1 time in total.
Virtualbox accept any and empty passwords when VRDP login
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:
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
u[qseo], d[], p[10]
init ok
Using PAM service: vrdpauth
start ok
auth ok
access granted
vrdpauth_pam_close completed
-
- Posts: 17
- Joined: 19. Sep 2007, 00:00
- Primary OS: Ubuntu other
- VBox Version: PUEL
- Guest OSses: Any and All
Re: Virtualbox accept any and empty passwords when VRDP logi
What does your vrdpauth look like and what version of vbox are you using?Murz wrote:
In debug file I see:Code: Select all
u[qseo], d[], p[10] init ok Using PAM service: vrdpauth start ok auth ok access granted vrdpauth_pam_close completed
The problem was solved when I update the VRDPAuth.so
The problem was solved when I update the VRDPAuth.so from this ticket: http://www.virtualbox.org/ticket/1953
-
- Posts: 17
- Joined: 19. Sep 2007, 00:00
- Primary OS: Ubuntu other
- VBox Version: PUEL
- Guest OSses: Any and All
Re: The problem was solved when I update the VRDPAuth.so
Glad you got it worked out.