4 ms·

Is there any historical reason that conhost is the only executable able to open a master handle?

by bpye 10y ago

quotemstr 10y ago
Well, originally, console handles weren't real handles. They were userspace hacks, which is why DuplicateHandle[1] has special cases for console handles. (Imagine using negative file descriptor values that libc understood.) Originally, the terminal emulator ran as SYSTEM and was spawned from (IIRC) csrss (which is special, because reasons). In Vista, with integrity levels introduced, the terminal emulator had to run in a different security context, and so wasn't themed. (To prevent shatter attacks.) In Windows 7 and 8, Microsoft developed a real, honest-to-god pseudoconsole API, with a real protocol. In this implementation, console handles are real handles and conhost is just a normal program that speaks a protocol. IIRC, the only thing at this point stopping Microsoft creating a pseudoconsole API based on real, honest-to-god kernel HANDLEs is a willingness to externalize, document, and support what has been until now a Windows-internal API. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms724251(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...
- dman 10y ago
  How do you know all this? :)
  - quotemstr 10y ago
    Three years on Windows and Windows Phone. I sometimes miss those days. :-)
- dfox 10y ago
  On Vista, conhost.also ran in user context and console windows were themed, on XP they was not. I believe that conhost.exe was introduced in Vista together with new desktop separation mechanism and on earlier version all the console window logic was internal to csrss (which in original NT design was essentially display server and window manager and placing console emulation in there makes some kind of sense given the NT's model of that).
  - quotemstr 10y ago
    Ah, yes, you're right! The windows were created directly.
  - yuhong 10y ago
    Win7, not Vista.
- ryanprichard 10y ago
  Regarding a public API, this GitHub comment suggests that people at Microsoft are working on it.[1] Of course, Microsoft can't commit to anything. As the winpty maintainer, I hope some kind of public API emerges to reduce my maintenance burden and make winpty more robust and efficient. Aside: About a year ago, I studied how the console handles worked (especially in relation to console attach/detach/alloc and CreateProcess), and I discovered a bunch of interesting things. For example, the "fake" handles were inherited regardless of the bInheritHandles parameter to CreateProcess, and an entire "ConsoleHandleSet" was inherited if a process attached to another process' console. Real handles in Win8 seemed to be either "bound" to a particular input/screen buffer or "unbound" so they worked with any attached console. It was possible to have a console open with no attached processes. I tried to formalize the behavior I observed here: https://github.com/rprichard/win32-console-docs https://github.com/rprichard/win32-console-docs In the course of testing, I found some neat bugs like: - A small program that blue-screens Vista - The inheritable flag on a console handle can be changed on any Windows version, except for Windows 7. - CreateProcess has an undocumented(?) behavior where it duplicates stdio handles into the new process rather than inherit them. (The handle values will generally change.) Up until Windows 8.1, a stdio handle of INVALID_HANDLE_VALUE was duplicated into a true handle to the parent process. (Because INVALID_HANDLE_VALUE is actually the GetCurrentProcess() pseudo-handle, you see.) - Assorted inconsistencies in Windows XP and WOW64 (probably fixed in newer OSs). I'm not sure how much confidence I have in the spec. It is backed by a big test suite, but there are so many cases to consider. [1] https://github.com/Microsoft/BashOnWindows/issues/111#issuecomment-238302654 https://github.com/Microsoft/BashOnWindows/issues/111#issuec...
  - poizan42 10y ago
    > - A small program that blue-screens Vista You mean like on current up-to-date versions of Vista and Server 2008? With a PoC on the github page? You realise that you have found a security vulnerability and are disclosing it publicly, right? Userspace must never crash the kernel, even if not further exploitable, especially so if it's possible for an unprivileged user. Be responsible, send a mail to secure@microsoft.com
    - 10y ago

Is there any historical reason that conhost is the only executable able to open a master handle?

by bpye 10y ago

Is there any historical reason that conhost is the only executable able to open a master handle?

Well, originally, console handles weren't real handles. They were userspace hacks, which is why DuplicateHandle[1] has special cases for console handles. (Imagine using negative file descriptor values that libc understood.) Originally, the terminal emulator ran as SYSTEM and was spawned from (IIRC) csrss (which is special, because reasons). In Vista, with integrity levels introduced, the terminal emulator had to run in a different security context, and so wasn't themed. (To prevent shatter attacks.) In Windows 7 and 8, Microsoft developed a real, honest-to-god pseudoconsole API, with a real protocol. In this implementation, console handles are real handles and conhost is just a normal program that speaks a protocol. IIRC, the only thing at this point stopping Microsoft creating a pseudoconsole API based on real, honest-to-god kernel HANDLEs is a willingness to externalize, document, and support what has been until now a Windows-internal API. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms724251(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...

dman 10y ago
How do you know all this? :)
- quotemstr 10y ago
  Three years on Windows and Windows Phone. I sometimes miss those days. :-)
dfox 10y ago
On Vista, conhost.also ran in user context and console windows were themed, on XP they was not. I believe that conhost.exe was introduced in Vista together with new desktop separation mechanism and on earlier version all the console window logic was internal to csrss (which in original NT design was essentially display server and window manager and placing console emulation in there makes some kind of sense given the NT's model of that).
- quotemstr 10y ago
  Ah, yes, you're right! The windows were created directly.
- yuhong 10y ago
  Win7, not Vista.
ryanprichard 10y ago
Regarding a public API, this GitHub comment suggests that people at Microsoft are working on it.[1] Of course, Microsoft can't commit to anything. As the winpty maintainer, I hope some kind of public API emerges to reduce my maintenance burden and make winpty more robust and efficient. Aside: About a year ago, I studied how the console handles worked (especially in relation to console attach/detach/alloc and CreateProcess), and I discovered a bunch of interesting things. For example, the "fake" handles were inherited regardless of the bInheritHandles parameter to CreateProcess, and an entire "ConsoleHandleSet" was inherited if a process attached to another process' console. Real handles in Win8 seemed to be either "bound" to a particular input/screen buffer or "unbound" so they worked with any attached console. It was possible to have a console open with no attached processes. I tried to formalize the behavior I observed here: https://github.com/rprichard/win32-console-docs https://github.com/rprichard/win32-console-docs In the course of testing, I found some neat bugs like: - A small program that blue-screens Vista - The inheritable flag on a console handle can be changed on any Windows version, except for Windows 7. - CreateProcess has an undocumented(?) behavior where it duplicates stdio handles into the new process rather than inherit them. (The handle values will generally change.) Up until Windows 8.1, a stdio handle of INVALID_HANDLE_VALUE was duplicated into a true handle to the parent process. (Because INVALID_HANDLE_VALUE is actually the GetCurrentProcess() pseudo-handle, you see.) - Assorted inconsistencies in Windows XP and WOW64 (probably fixed in newer OSs). I'm not sure how much confidence I have in the spec. It is backed by a big test suite, but there are so many cases to consider. [1] https://github.com/Microsoft/BashOnWindows/issues/111#issuecomment-238302654 https://github.com/Microsoft/BashOnWindows/issues/111#issuec...
- poizan42 10y ago
  > - A small program that blue-screens Vista You mean like on current up-to-date versions of Vista and Server 2008? With a PoC on the github page? You realise that you have found a security vulnerability and are disclosing it publicly, right? Userspace must never crash the kernel, even if not further exploitable, especially so if it's possible for an unprivileged user. Be responsible, send a mail to secure@microsoft.com
  - 10y ago