Correspondance Date: 29 Oct 2014

< Microsoft confirm they've reproduced the issue and think it might constitute a security feature bypass. Further confirmation will be provided soon.

Correspondance Date: 14 Jan 2015

< Asked Microsoft for information on whether they were going to fix this issue and timescales of it. Notified them that the current deadline is the 15th January.

Correspondance  Date: 14 Jan 2015

> Microsoft informed us that a fix was planned for the January patches but has to be pulled due to compatibility issues. Therefore the fix is now expected in the February patches. 

Deadline exceeded - automatically derestricting

Note that the bug tracker is intended for technical analysis and bookkeeping related to the specific issue described. In this instance, we're looking to keep comments strictly about the technical aspects of this issue.

Thanks!
Ben

I cannot imagine any circumstance in which it would be desirable for this feature to behave this way. If there's a compatibility issue, this means that some poorly written code is relying on this bug to function correctly and, therefore, those components might be a ripe opportunity for further security bug exploration.

Just my thoughts on the matter. Great find!

on Windows 10 i got Encryption doesn't match, impersonated session?

on my Windows 8.1 i got:
"Encryption doesn't match, impersonated session?"

What does it mean?

Can someone point me to an explanation of what exactly this does?

Is this vulnerability relevant to EFS? Does it allow a simultaneously logged-on user to use a different user's EFS key?

Ok, I have read it is a privilege escalation, but this still isn't entirely clear to me.
Acquiring an impersonation token doesn't necessarily mean you have really escalated privilege does it? My understanding was that system-level functions are supposed to check if your token is legitimate and so would not let you use this impersonation token to perform privileged functions, unless they themselves were bugged.
Looking at the "Encryption doesn't match, impersonated session?" from an EFS perspective I again don't necessarily see this as problem. If you impersonated a user and gained access to their EFS public key there is no problem, and that could produce data reasonably described by "Encryption doesn't match". Only private key access, and subsequent ability to decrypt data would be a real problem.
Anyway, I'm not reading that EFS is involved here; just going back to it as an example.

OK, nevermind; I think I got a better explanation now, but please tell me I'm wrong if this is not it:
"a normal user can impersonate at Identification level and decrypt or encrypt data for that logon session"

So processes in your user space may be encrypting their memory such that only processes in your user space can read their content. This vulnerability breaks this protection, allowing other simultaneous users to read the encrypted memory of processes in your user space that attempted to encrypt their memory.

So this would have an impact in situations like:
*) A web server with an SSL certificate storing it in encrypted memory could have the private key stolen by another process running on the computer
*) A password database program, if they even use this function, could have passwords stolen from memory by programs running in other users' spaces

I keep talking about EFS because it concerns me; but it doesn't look particularly likely that it is affected here: that another user on the computer could use this vulnerability to extract an EFS private key from memory.

This isn't related to EFS, that's a separate system service. The CryptProtectMemory is an API which you're supposed to use to protect ephemeral data, such as passwords in memory or encryption keys. The actual key for the memory is stored in the kernel so user-mode programs shouldn't be able to access it directly. There are three levels of protection:

1) The current process only
2) The current logon session
3) The current computer

This issue only affects 2, the PoC demonstrates that if you impersonate using the token which is tied to another logon session (such as Local System's session) you can encrypt and decrypt memory. The kernel driver's missing the impersonation level check so a normal system user can impersonate at Identification level and decrypt data encrypted in the local system's logon session. This impersonation level doesn't provide the normal user any additional privileges. The issue description does not provide a concrete example of accessible encrypted data but there could be many places it might leak such as shared memory sections or temporary files. The ultimate severity of the issue therefore depends on what data could be decrypted or encrypted and what you might be able to do with it (think if the data was another user's password).

Great description, thank you!

Bulletin: https://technet.microsoft.com/library/security/MS15-010

can be explained in more detail ga I do not understand http://tricajus-asli.com/obat-kanker-payudara-tanpa-operasi-terampuh/