Tor uses Roaming (remote) %APPDATA% instead of %LOCALAPPDATA%

[First tor-bug post, hope I got this right...]

The Windows tor.exe -- all current versions, standalone expert bundle and TBB/etc bundles -- has outdated Windows Explorer COM interface code to get the user's %APPDATA% location. This location can be local or roaming (remote).

Remote data gives many more opportunities for adversaries to mess with Tor Windows users, especially when they are using a domained enterprise.

The solution is below. Until this is fixed, Windows Tor users should never use Tor on a Windows network.

The Windows version of Tor calls the Windows Explorer 'shell' special folder COM APIs, to obtain the location for %APPDATA%. App data can be local or roaming.

On my box, %USERPROFILE%\AppData* has 3 directories where apps install files, Local, LocalLow, and Roaming, where about 55% of the apps use Local, 5% uses LocalLow, and 40% use Remote.

Tor uses Roaming ("%USERPROFILE%\AppData\Roaming\tor).

Roaming means that it gets remoted to other systems, which is probably a bad thing for Tor user data. The point of Roaming profiles is to let user data migrate to multiple boxes, and the remoting of that data happens with SMBs. So, Remote user data might be sniffable over the network, hopefully this is encrypted.

Depending on how enterprise is configured, Remote user data also probably means replication/backups of that data in the domain controller's Active Directory box. So the user's Tor data is available over multiple SMB hosts, making things easier for attackers.

This bug was probably added to Tor in 0.2.1.11-alpha - 2009-01-20:

----snip----

Add a new --enable-local-appdata configuration switch to change the default location of the datadir on win32 from APPDATA to LOCAL_APPDATA. In the future, we should migrate to LOCAL_APPDATA entirely. Patch from coderman. ----snip----

Tor explicitly checks the location. in or/config.c's get_windows_conf_root(), in it's use of the Windows Explorer COM APIs SHGetSpecialFolderLocation() and SHGetPathFromIDList(), using this definition of the APP_DATA flag:

----snip---- /* Find X:\documents and settings\username\application data\ .

We would use SHGetSpecialFolder path, but that wasn't added
until IE4. */ #ifdef ENABLE_LOCAL_APPDATA #define APPDATA_PATH CSIDL_LOCAL_APPDATA #else #define APPDATA_PATH CSIDL_APPDATA #endif ----snip----

First, this comment is wrong on many levels. It begins with "X:" (instead of "C:") which would likely be remote, not local. It talks about IE4 which shipped aeons ago, maybe time to revisit this hesitation. And you you do use this COM API, anyway.

I am pretty sure that it is the above definitions that're causing you to install the Roaming data location on my Win7 box.

CSIDL_LOCAL_APPDATA == FOLDERID_LocalAppData

CSIDL_APPDATA == FOLDERID_RoamingAppData

I am not great at Autotools, but I don't believe anyone is setting ENABLE_LOCAL_APPDATA, so the directive might be 0. It is defined/used in config.ac and orconfig.h.in.

----snip---- /* Defined if we default to host local appdata paths on Windows */ #undef ENABLE_LOCAL_APPDATA ----snip----

I don't understand why this Windows-centric feature needs to be abstracted with GNU/autotools in the first place. Can Erin's Mac OSX-based, MinGW cross-compiled Autotools determine that I'm running WinXP or Win7, etc? This abstraction, using legacy APIs, is probably why this bug has been there since 2009.

Tor already abstracts this Windows-centric code into it's own function, it would be clearer if you removed all the autotools absraction to the Windows Special Folder COM API that Tor uses, IMO.

Also, this function doesn't check this return code, and assumes to be true:

strlcpy(p,get_windows_conf_root(),MAX_PATH);

Also, in this Windows-centric error codepath, there is no warning to the user, AFAICT:

if (!SUCCEEDED(result)) { return NULL; }

Also, elsewhere in get_windows_conf_root(), there are 2 comments, with potentially-open questions. Here are updated comments stated more clearly. Replace:

/* Convert the path from an "ID List" (whatever that is!) to a path. */

with:

/* Windows Explorer, aka 'Windows 'shell', uses IDLists to access various things, including special folders. We need to convert this COM-based explorer-centric array list to a Windows path. */

And replace:

/* Now we need to free the memory that the path-idl was stored in.

In typical Windows fashion, we can't just call 'free()' on it. */

with:

/* Windows explorer special folders APIs are COM APIs, not Win32 or C runtime library calls. To use special folders, we have to use the COM memory mgmt APIs, to allocate, and now release that memory. Read the SDK ShObj.h or MSDN for more info. */

Note also that you are using legacy, deprecated version of the Special folders API, there have been revisions, apparently during Vista and Win7. The newer API has more features than the one you're using, including the local/roaming granularity. I think f you explicitly stick to local data, I think you can stick with legacy APIs.

You can't just test this with one version of Windows, you'll need to test with each version you are supporting.

More info: http://msdn.microsoft.com/en-us/library/windows/desktop/bb762181%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/dd378457%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb762494%28v=vs.85%29.aspx http://technet.microsoft.com/en-us/library/cc766489.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb776779%28v=vs.85%29.aspx http://www.blogtechnika.com/what-is-application-data-folder-in-windows-7/ http://superuser.com/questions/150012/what-is-the-difference-between-local-and-roaming-folders http://superuser.com/questions/21458/why-are-there-directories-called-local-locallow-and-roaming-under-users-user http://social.technet.microsoft.com/Forums/en/w7itprogeneral/thread/b4fd7ac2-8ad9-4a06-8c28-3f7993aa0272 http://blogs.technet.com/b/fdcc/archive/2009/07/08/fdcc-vista-application-development-requirements.aspx http://social.msdn.microsoft.com/Forums/en/windowsgeneraldevelopmentissues/thread/8fa38285-e4f5-43f9-ab0b-8fe184d476f9 http://technet.microsoft.com/en-us/library/cc778976.aspx

Thanks, Lee

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information