* Windows explorer special folders APIs are COM APIs, not Win32 or C runtime library calls. In typical Windows fashion, we can't just call 'free()' on it.* Now we need to free the memory that the path-idl was stored in. We need to convert this COM-based explorer-centric array list to a Windows path. * Windows Explorer, aka 'Windows 'shell', uses IDLists to access various things, including special folders. * Convert the path from an "ID List" (whatever that is!) to a path. Here are updated comments stated more clearly. Strlcpy(p,get_windows_conf_root(),MAX_PATH) Īlso, in this Windows-centric error codepath, there is no warning to theĪlso, elsewhere in get_windows_conf_root(), there are 2 comments, with potentially-open questions. 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.Īlso, this function doesn't check this return code, and assumes to be true: 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. I don't understand why this Windows-centric feature needs to be abstracted with GNU/autotools in the first place. * Defined if we default to host local appdata paths on Windows */ It is defined/used in config.ac and orconfig.h.in. I am not great at Autotools, but I don't believe anyone is settingĮNABLE_LOCAL_APPDATA, so the directive might be 0. I am pretty sure that it is the above definitions that're causing you to install the Roaming data location on my Win7 box.ĬSIDL_LOCAL_APPDATA = FOLDERID_LocalAppData It talks about IE4 which shipped aeons ago, maybe time to revisit this hesitation. It begins with "X:" (instead of "C:") which would likely be remote, not local. We would use SHGetSpecialFolder path, but that wasn't addedįirst, this comment is wrong on many levels.* Find X:\documents and settings\username\application data\. 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: In the future, we should migrate to LOCAL_APPDATA The default location of the datadir on win32 from APPDATA to Add a new -enable-local-appdata configuration switch to change.This bug was probably added to Tor in 0.2.1.11-alpha - : So the user's Tor data is available over multiple SMB hosts, making things easier for attackers. Probably means replication/backups of that data in the domainĬontroller's Active Directory box. So, Remote user data might be sniffable over the network, hopefully this is encrypted.ĭepending on how enterprise is configured, Remote user data also The point of Roaming profiles is to let user data migrate to multiple boxes, and the remoting of that data happens with SMBs. Roaming means that it gets remoted to other systems, which is probably a bad thing for Tor user data. Tor uses Roaming ("%USERPROFILE%\AppData\Roaming\tor). 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. The Windows version of Tor calls the Windows Explorer 'shell' special folder COM APIs, to obtain the location for %APPDATA%. Until this is fixed, Windows Tor users should never use Tor on a Windows network. Remote data gives many more opportunities for adversaries to mess with Tor Windows users, especially when they are using a domained enterprise. This location can be local or roaming (remote). 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |