uvnc应对vista安全机制之策略（摘录）

UltraVnc v1.03 Beta tech info

Changes

The build in winvnc service is replaced by an external service. Vista require an isolation between the service and the desktop application.
For security, applications started by a service, should by started as the same user as the desktop owner, this prevent other applications trying to gain admin access via winvnc.

v1.0.3 RC1 doesn't use any more the registry for option saving.
It was too complicated to get the registry permissions right, and because winvnc.exe needs to be started as system, password and ports could change if user and system have different settings
We are thinking about reserving the use of ultravnc.ini file for Vista only and keep the registry for others Windows versions. We could also support both modes.
Actually v1.0.3 with registry works under Vista but users must configure both WinVNC "default" and "User" settings even when then don't install the WinVNC service...

- WinVNC settings File: ultravnc.ini
- Location: same directory as winvnc.exe
- If you want to prevent normal users to change the file, you need to set restrictions on the write access of this file

The viewer now auto reconnects when the desktop security changes or when the user login/logoff.
The default delay is 10s (no viewer screen refresh).
If the autoreconnect ever fails you still can manually reconnect and should be able to gain access to all (logon/screen saver/default/UAC) security desktop.

ctrl-alt-del

Winvnc can not send the ctrl-alt-del sequence if you have UAC disable and CAD enable.
UAC not only popup a "accept" box for elevated apps, but also process the manifest security settings.
If you disable UAC, you also need to disable CAD, else no software( including MS on screen keyboard) can simulate the CAD sequence.

If you download and unzip the files Vista put a security bit on them and ask permission each time you want to execute them. This prevent the winvnc service from proper working.
After you downloaded and extracted the files you need to copy them in a subfolder in "Program Files", this reset this bit.

BACKGROUND INFO
Activate/Deactivate ctrl-alt-del in Vista
You can configure the local security policy so the Windows Security dialog box will be displayed, requiring all users to press CTRL + ALT + DEL to log on.
Users will then be prompted to provide a valid username and password to access the computer.

You can configure this option in Windows Vista by using the following steps:

1° Within the Control Panel, click System and Maintenance. 

2° Click Administrative Tools then the Local Security Policy. 

3° Within the console, expand Computer Configuration | 

Windows Settings | Security Settings | Local Policies. 

4° Click Security Options. The various security options are 

displayed in the details pane. 

5° Scroll through the options and locate Interactive Logon: 

Do not require CTRL + ALT + DEL. 

6° Double click the security option. 

7° Select Disabled to require users to press CTRL + ALT + DEL. 

8° Click OK. 

Enable/Disable UAC

1° Run MsConfig from Run option. 

2° In System Configuration window, click on the Tools tab. 

3° Scroll down and locate “Disable UAP” or “Disable UAC” option item. Click on that line. 

4° Click the Launch button. 

5° A command prompt window will open and automatically execute and run certain process to disable UAC. 

6° Close CMD window when done. 

7° Close Msconfig. 

8° Restart computer for changes to apply and effective. 

To re-enable UAC, simply select “Enable UAP” or “Enable UAC” instead of “Disable UAP” or “Disable UAC”, and then click on Launch button. 

Vista Challenge I (session isolation)

We spend about 4 months on R&D and final got it working with some support of the MS helpdesk.

Vnc and all remote control softwares are having trouble withy the new Vista security model. In de old model, winlogon was always running in the same session as the services, session0

While in the new model, the winlogon run in the same session as the desktop.

The isolation of the session0, now only used for services, prevent winvnc in service mode to access session X and no interaction with the desktop in session X is possible. Using the service, you can't logon or capture the desktop.

Running winvnc in application mode ( started manual in sessionX) all seems to work as long as you don't logoff or use any system application that popup the UAC.

Solution I

Winvnc need to split exe in a service and a application part. When we run the winvnc_service in session0 and let the service start winvnc_app in the sessionX, winvnc_app can communicate with the desktop and control the mouse and keyboard.

An other problem is that sessionX have different desktop, let's take a closer look how desktop exist in Vista. (This model was already partly in use on XP, for the "Fast user switching", remember the black screen you had with VNC after switching user)

- Session 0

|  |

|   ---- WinSta0 (interactive window station)

|  |   |

|   |  ---- Default (desktop)

|  |   |

|   |   ---- Disconnect (desktop)

|  |   |

|   |   ---- Winlogon (desktop)

|   |

|   ---- winvnc Service (non-interactive window station)

|   |   |

|   |   ---- Default (desktop)

|   |

- Session 1

|  |

|   ---- WinSta0 (interactive window station)

|   |   |

|   |   ---- Default (desktop)(1**)

|   |   |

|   |   ---- Disconnect (desktop)

|   |   |

|   |   ---- Winlogon (desktop)

|   |

- Session 2

| |

| ---- WinSta0 (interactive window station)

| | |

| | ---- Default (desktop) 

|

| | ---- Disconnect (desktop)

| |   |

| | ---- Winlogon (desktop)  (2**)

The service need to check the console desktop and session.
If the console desktop is (1**) the service need to start winvnc_app in session1 on the default desktop, the default desktop is the normal desktop where your application run on.
If the console desktop is (2**) the service need to start winvnc_app in session2 on the winlogon desktop, this is the secure desktop used to logon.
To avoid access problems, you best start the winvnc_app with the same security context as the desktop he is started in.
Default Desktop --> user
Winlogon Desktop -> local system
Createprocessasuser() allow the service to start the exe in the correct security context.

This method would be a complete solution to support Fast user switching and access on PC's running RDP. But Vista has other nasty tricks to prevent applications to control a desktop.

Vista Challenge II (elevation and UAC)

Security elevation

From previous MS OS's you know that permissions where based on users. If you logged on as administrator, you could simple click on an executable to start it. As normal user, you needed execute permission on that executable.
In Vista applications have a "security elevation".
Low: Iexplorere started as administrator runs in low security elevation, this block iexplorer access to many system sources and applications.
Normal: A standard application, word pad, run in normal elevation.
High: For system utilities, like service manager..
The elevation block some interaction from lower elevated application to higher. For Vnc the most important is that sendinput() is blocked. You can't control an application running in higher elevation then the elevation winvnc is running.
If you start the service manager from within VNC, VNC mouse clicks get locked by the elevated "service manager" application.
If the remote users minimize the "service manager" you have full access again, but remote you are blocked.

UAC

In older OS version you could simple start a "system application" with a double click, in Vista the UAC jumps in. The UAC popup a "OK" window in the secure desktop, he temporal switch to the winlogon desktop and ask your permission to execute that program.
The problem for VNC is that your winvnc_app running in the default desktop has no permission to access the winlogon desktop, remote the whole desktop lock and you need to ask the remote user the press the ok button to continue.

Solution II

UAC problem can be solved by restarting the winvnc_app in the winlogon desktop, to press OK, and the restarting it again in the default desktop.
Great, but now VNC lock because the "system app" has focus and sendinput() is locked because it run in "high" elevation.
No problem, should you think, we just add a manifest to the winvnc_app and tell that it need to start in "high" elevation, then it can control all application. ( elevation high has access to all elevation >=high)
This works, when you manual click on the winvnc_app.exe, it popup the UAC and you press OK, but when you start it from the service you get a permission denied, CreateprocessAsUser(CPAU) is not allowed to start elevated application......

Don't play with the manifest, the only way is to play with the token passed to CPAU and pass the full elevated token, then winvnc_app start elevated and you have access.

Vista Challenge II ( Ctrl-alt-del)

In previous OS's you could send a message from a service in the winlogon desktop to simulate the CAD sequence...
PostMessage(HWND_BROADCAST,WM_HOTKEY,0,MAKELPARAM(MOD_ALT|MOD_CONTROL,VK_DELETE));
This does not work in Vista....

Solution III

We are testing, it has to be possible, the osk (on screen keyboard) can simulate the sequence. The osk use undocumented functions, the "winlogon IPC API"...
As workaround, you can use the on screen keyboard. When you press the left/down icon it popup the keyboard and you can that to simulate CAD...
Problem solved , Ctrl-Alt-Del can be made with a separate exe "cad.exe"