An introduction…
Dealing with the family over holidays can be stressful, and being an obvious geek sometimes helps. Sometimes it is just easier to disappear into the computer rather than ask questions, and because they are family they know me well enough to give me some slack. Because sometimes I see something and I just don’t want to know why. And clearly this is one of those times. You now also get to wonder without knowlege, since I’m writing this post instead of asking those questions. By the way, Fern the dog has her own Facebook page so if you really have the need, you can ask her yourself.
On to the post…
Score One for Justin Glass of Indiana University.
One great thing about teaching is that you always learn something new from the students. For some things, it is important to not to have been trained yet since you are not contaminated with pre-conceived notions of what should work and what shouldn’t. When you aren’t polluted with incorrect rules of how things work, it can help you to find things that none of us know about. And when it isn’t about my nephew’s dog, I might really want to know why. Our last Masters Level App-V Training Class is a great example of this.
One of our students made a mistake when sequencing an app and manually copied the wrong file into the package. He was testing this app up on the screen so that we could demonstrate a technique to break into the virtual environment to look at the files without cracking the package back in the sequencer. He confirmed that he had the wrong file and I was about to send him back to the sequencer. Then something extrordinary happened that I never would have considered.
Another student, Justin Glass, said “hold on, I’ll fix that from here”. A slight pause, then “OK, look at it now”. The original student looked at the file version inside his virtual environment. It now was the right version.
I asked how he did it. Quite simply really. He opened up the admin share to the virtual drive on the first students computer, then copied the file in. ” WHAT???? You can’t do that!” I exclaimed. Well he did and I was wrong.
I have since done some additional testing to look at what is hapening, and I am even more confused by what I found and what it means. While we were dealing with the desktop client OS in the class at that time, I have now also looked at a Terminal Server with the App-V client as well.
Let’s start with the Desktop OS:
- With the OS running, the user logged in, and no virtual apps running, you can remotely access the admin share to the virtual drive. On the other machine logged in with a domain admin account, just run the command “\\clientname\Q$” (where clientname is the name of the client machine and Q represents the virtual drive letter). You can connect, and you can view the asset folder list of all deployed virtual apps on that machine. You can’t look into the folders at this time.
- At the client machine, have the user start an app. From the admin share you can now change directory into that virtual app package asset folder. You can’t see into the other virtual app folders, just that one.
- Have the client user start another app in another package (without closing the first). From the remote share you can now see into the virtual app package folder of each open package.
- Have the client user make a visible file change that would affect the package. For example, save a file directly into the virtual app package folder. The new file is visible via the admin share.
- Do Justin’s trick. Overwrite a file in the asset folder by using the admin share. You can verify that the user sees this change at the client.
- Have the user close the app and re-open it. The changed file remains.
- Have the client user log off and log in using another account. Verify if this user sees the changed file when running the virtual application package. Huge sigh of relief when this session does not have the changed file.
- Use PkgView to verify that the changed file was stored in the original user’s PKG file in their APPDATA folder.
OK. So is this a security hole? Well you need admin rights to do this, and with those rights this might not be the worst thing that you can do. Still, it doesn’t seem “right” to be able to do this. Especially since it will look like the user did it to themselves.
But the clever of you out there now ask, “but what happens if you try that on a terminal server when multiple users are logged in at the same time”? Being a clever type myself, I did more testing.
The client on a terminal server (oh, forgive me, it is “remote desktop session host” now) has to deal with multiple users. So how would it know which user PKG to consider.
- Log into the TS machine 2 users. Have two different applications published, one to the first user and one to the second. With no apps open, check the admin share. You can view each asset folder in the list.
- Have each user start their app. From the admin share you can now change directory into each package.
- Notice that although you can cd into the VFS folder within the package, you cannot see anything below that level. I didn’t go back to the desktop OS to confirm if that behavior is consistent.
- Assign the same app to two users, one an administrator and another a standard user. Have each create a different file or folder under the asset root inside the virtual applciation. What do you see in the admin share? Only the changes made by the admin user.
- Have the administrative user close the virtual app. The admin share can still not see the standard user’s changes.
I don’t think these behaviors have much practical use, and I am inclined to think that Microsoft should probably look at this and close this loophole if they can. Strange behaviors indeed!
