[tor-bugs] #7956 [Tor]: Tor uses Roaming (remote) AppData, not Local

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Jan 15 00:02:58 UTC 2013


#7956: Tor uses Roaming (remote) AppData, not Local
-------------------------------------------+--------------------------------
 Reporter:  cypherpunks                    |          Owner:                  
     Type:  defect                         |         Status:  new             
 Priority:  normal                         |      Milestone:                  
Component:  Tor                            |        Version:  Tor: unspecified
 Keywords:  AppData Roaming Local Windows  |         Parent:                  
   Points:                                 |   Actualpoints:                  
-------------------------------------------+--------------------------------
 [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

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7956>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list