{"action":"created","issue":{"url":"https://api.github.com/repos/chrsmith/google-security-research/issues/123","labels_url":"https://api.github.com/repos/chrsmith/google-security-research/issues/123/labels{/name}","comments_url":"https://api.github.com/repos/chrsmith/google-security-research/issues/123/comments","events_url":"https://api.github.com/repos/chrsmith/google-security-research/issues/123/events","html_url":"https://github.com/chrsmith/google-security-research/issues/123","id":58936826,"number":123,"title":"Windows Elevation of Privilege in User Profile Service","user":{"login":"GoogleCodeExporter","id":9614759,"avatar_url":"https://avatars.githubusercontent.com/u/9614759?v=3","gravatar_id":"","url":"https://api.github.com/users/GoogleCodeExporter","html_url":"https://github.com/GoogleCodeExporter","followers_url":"https://api.github.com/users/GoogleCodeExporter/followers","following_url":"https://api.github.com/users/GoogleCodeExporter/following{/other_user}","gists_url":"https://api.github.com/users/GoogleCodeExporter/gists{/gist_id}","starred_url":"https://api.github.com/users/GoogleCodeExporter/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GoogleCodeExporter/subscriptions","organizations_url":"https://api.github.com/users/GoogleCodeExporter/orgs","repos_url":"https://api.github.com/users/GoogleCodeExporter/repos","events_url":"https://api.github.com/users/GoogleCodeExporter/events{/privacy}","received_events_url":"https://api.github.com/users/GoogleCodeExporter/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/chrsmith/google-security-research/labels/auto-migrated","name":"auto-migrated","color":"ededed"},{"url":"https://api.github.com/repos/chrsmith/google-security-research/labels/CCProjectZeroMembers","name":"CCProjectZeroMembers","color":"ededed"},{"url":"https://api.github.com/repos/chrsmith/google-security-research/labels/CVE-2015-0004","name":"CVE-2015-0004","color":"ededed"},{"url":"https://api.github.com/repos/chrsmith/google-security-research/labels/Deadline-90","name":"Deadline-90","color":"ededed"},{"url":"https://api.github.com/repos/chrsmith/google-security-research/labels/Deadline-Exceeded","name":"Deadline-Exceeded","color":"ededed"},{"url":"https://api.github.com/repos/chrsmith/google-security-research/labels/Finder-forshaw","name":"Finder-forshaw","color":"ededed"},{"url":"https://api.github.com/repos/chrsmith/google-security-research/labels/Fixed-2015-Jan-13","name":"Fixed-2015-Jan-13","color":"ededed"},{"url":"https://api.github.com/repos/chrsmith/google-security-research/labels/MSRC-20674","name":"MSRC-20674","color":"ededed"},{"url":"https://api.github.com/repos/chrsmith/google-security-research/labels/Product-Windows","name":"Product-Windows","color":"ededed"},{"url":"https://api.github.com/repos/chrsmith/google-security-research/labels/PublicOn-2015-Jan-11","name":"PublicOn-2015-Jan-11","color":"ededed"},{"url":"https://api.github.com/repos/chrsmith/google-security-research/labels/Reported-2014-Oct-13","name":"Reported-2014-Oct-13","color":"ededed"},{"url":"https://api.github.com/repos/chrsmith/google-security-research/labels/Severity-Medium","name":"Severity-Medium","color":"ededed"},{"url":"https://api.github.com/repos/chrsmith/google-security-research/labels/Vendor-Microsoft","name":"Vendor-Microsoft","color":"ededed"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":45,"created_at":"2015-02-25T17:15:44Z","updated_at":"2015-02-25T17:15:55Z","closed_at":"2015-02-25T17:15:45Z","body":"```\nPlatform: Windows 8.1 Update 32/64 bit (No other OS tested)\n\nWhen a user logs into a computer the User Profile Service is used to create \ncertain directories and mount the user hives (as a normal user account cannot \ndo so). In theory the only thing which needs to be done under a privileged \naccount (other than loading the hives) is creating the base profile directory. \nThis should be secure because c:\\users requires administrator privileges to \ncreate. The configuration of the profile location is in HKLM so that can’t be \ninfluenced. \n\nHowever there seems to be a bug in the way it handles impersonation, the first \nfew resources in the profile get created under the user’s token, but this \nchanges to impersonating Local System part of the way through. Any resources \ncreated while impersonating Local System might be exploitable to elevate \nprivilege. Note that this occurs everytime the user logs in to their account, \nit isn't something that only happens during the initial provisioning of the \nlocal profile. \n\nSome identified issues are:\n\n* When creating directories the service does a recursive create, so for example \nif creating c:\\users\\user it will first create c:\\users then c:\\users\\user. \nProbably not exploitable because Users already exists but of course worth \nremembering that normal users can create directories in the c: drive root. So \nalways a possibility being able to place a junction point at c:\\users on some \nsystems.\n\n* The service creates the temporary folder for the user in \nCreateTempDirectoryForUser and gets the value from the user’s hive \nEnvironment key (TEMP and TMP). This folder is created under system privileges. \nAll it requires is the string starts with %USERPROFILE% so you can do relative \npaths or just replace USERPROFILE in the environment. This probably isn't that \nuseful on the whole as the security of the directory is inherited from the \nparent.\n\n* Creation of AppData\\LocalLow folder in EnsurePreCreateKnownFolders. This \nmight be exploited to set an arbitrary directory’s integrity level to Low as \nit tries to set the label explicitly. But that’s probably only of interest if \nthere’s a directory which a normal user would be able to write to but is \nblocked by a high/system integrity level which is unlikely. \n\n* Probably most serious is the handling of the \n%USERPROFILE\\AppData\\Local\\Microsoft\\Windows\\UsrClass.dat registry hive. The \nprofile service queries for the location of AppData\\Local from the user’s \nregistry hive then tries to create the Windows folder and UsrClass.dat file. By \ncreating a new folder structure, changing the user's  shell folders registry \nkey and placing a junction in the hierarchy you can get this process to open \nany other UsrClass.dat file on the system, assuming it isn't already loaded. \n\nFor example you could create a directory hierarchy like:\n%USERPROFILE%\\AppData\\NotLocal\\Microsoft\\Windows -> \nc:\\users\\administrator\\appdata\\local\\Microsoft\\windows\n\nThen set HKCU\\Software\\Microsoft\\Windows\\Explorer\\User Shell Folders\\Local \nAppData to %USERPROFILE%\\AppData\\NotLocal.\n\nIt seems to even set the root key security when it does so, this might be \nuseful for privilege escalation. This has a chicken-and-egg problem in that the \nNtLoadKey system call will create the file if it doesn't exist (it sets the \nFILE_OPEN_IF disposition flag), but you must be running as an administrator  \notherwise the privilege check for SeRestorePrivilege will fail.\n\nI've looked at the implementation on Windows 7 and there are a few similar \nissues but Windows 8.1 implementation of the services does a lot more things. \nAt least the most serious UsrClass.dat issue exists in 7. \n\nAttached is a batch file PoC for Windows 8.1 Update which demonstrates the \ntemporary folder issue. To verify perform the following steps:\n1) Execute the batch file as a normal user (this was tested with a local \naccount, not a Microsoft online linked account, or domain). This will change \nthe environment variables TEMP and TMP to be \n%USERPROFILE%\\..\\..\\..\\..\\Windows\\faketemp\n2) Logout then log back in again\n3) Observe that the directory \\Windows\\faketemp has been created.\n\nThis bug is subject to a 90 day disclosure deadline. If 90 days elapse\nwithout a broadly available patch, then the bug report will automatically\nbecome visible to the public.\n\n```\n\n-----\nOriginal issue reported on code.google.com by `fors...@google.com` on 13 Oct 2014 at 4:39\n\nAttachments:\n* [set_temp.bat](https://storage.googleapis.com/google-code-attachments/google-security-research/issue-123/comment-0/set_temp.bat)\n"},"comment":{"url":"https://api.github.com/repos/chrsmith/google-security-research/issues/comments/76006617","html_url":"https://github.com/chrsmith/google-security-research/issues/123#issuecomment-76006617","issue_url":"https://api.github.com/repos/chrsmith/google-security-research/issues/123","id":76006617,"user":{"login":"GoogleCodeExporter","id":9614759,"avatar_url":"https://avatars.githubusercontent.com/u/9614759?v=3","gravatar_id":"","url":"https://api.github.com/users/GoogleCodeExporter","html_url":"https://github.com/GoogleCodeExporter","followers_url":"https://api.github.com/users/GoogleCodeExporter/followers","following_url":"https://api.github.com/users/GoogleCodeExporter/following{/other_user}","gists_url":"https://api.github.com/users/GoogleCodeExporter/gists{/gist_id}","starred_url":"https://api.github.com/users/GoogleCodeExporter/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GoogleCodeExporter/subscriptions","organizations_url":"https://api.github.com/users/GoogleCodeExporter/orgs","repos_url":"https://api.github.com/users/GoogleCodeExporter/repos","events_url":"https://api.github.com/users/GoogleCodeExporter/events{/privacy}","received_events_url":"https://api.github.com/users/GoogleCodeExporter/received_events","type":"User","site_admin":false},"created_at":"2015-02-25T17:15:53Z","updated_at":"2015-02-25T17:15:53Z","body":"```\nAlso works in Win 7 Professional SP 1 64bit.\n```\n\n-----\nOriginal comment by `leibi...@googlemail.com` on 13 Jan 2015 at 7:33"}}