6 ms·

Why's it so difficult to write a print spooler? I'm not too familar with what it does exactly. But I presume it's a queue of documents to send to a printer and

by Jonnax 6y ago

Why's it so difficult to write a print spooler? I'm not too familar with what it does exactly. But I presume it's a queue of documents to send to a printer and some level of conversation of the data from a print document format to what the printer driver understands. This seems like quite a crazy bug. Also today, a lot of home printers are network printers so it shouldn't even require higher privilages to send the document to the printer, right? Or is printing in Windows a huge can of worms like its use of UTF-16?

derefr 6y ago
It is indeed possible to design a system that only works as a client for network printers as a pure-userland service; I believe this is what iOS has, in the form of AirPrint. But most OS printing services cover both network and local (USB, parallel, even serial!) printing, and therefore the print daemon needs to essentially "own" ACLs on some collection of USB-devices and even "own" direct bit-banging access to a set of serial/parallel-ports, in the same sense that X11 gets to own VRAM memory-regions, or an audio daemon gets to own bit-banging access to a set of DAC controllers. Coupled with this is the problem of supporting legacy software that expects older consumer-microcomputer OS paradigms for device access. This isn't so much of a problem on POSIX systems, where the oldest paradigm (having /var/spool as a sticky dir, where roff(1) would just write files there) was already multitenant-friendly; you just need a print daemon (CUPS) that can watch /var/spool for changes, along with its non-legacy API. I believe you can roff(1) even within Termux on Android, and it'll "just work", without special kernel support other than the generic filesystem notification-event API. But Windows specifically inherits a print-system design all the way from DOS, and still supports software (e.g. Win9x software written for the Win32 API) that was written to expect that legacy API. I don't know too much about the Win32 print API specifically, but I'd guess that it was designed to be a forward-compatible shim on top of the DOS printing "API"—which was really just allowing the application to bang bits down the serial/parallel port through memory-mapped IO. That's what the "LPT1", "COM", etc. devices in Windows are: emulations of those same legacy memory-mapped IO channels that only make sense to access in a single-tasking OS. But, as of NT/W2K, it's actually the OS on the other end of that pipe, arbitrating data flows. So that's another thing that needs to happen in kernel-land in Windows: the emulation of an unprotected MMIO memory region within the process's address space, as a glorified syscall ABI, which just (these days) routes messages to the userspace print daemon, but back in Win9x probably did do all its work in kernelspace.
- ancarda 6y ago
  Why don't we have a version of Windows without as much legacy support? Like a security hardened (or really just modern-only) version of Windows? I suspect most people would be fine using that version of Windows, and it would have less security problems.
  - derefr 6y ago
    Much of the "point" of Windows as a platform at this point (i.e. the reason that developers stick with targeting Windows APIs, instead of re-developing their software for portability using Java or Qt or Electron or whatever-else) is backward-compatibility. People say that a lot, but it has a very specific meaning when talking about a platform SDK: "backward compatibility" here specifically means that if you wrote version N of your software for version N of Windows, then when you're writing version N+1 of your software targeting version N+1 of Windows, you don't need to re-write any of the old code. You can just start taking advantage of the new Windows API features in the new code you write, while leaving your old code that calls legacy Windows APIs alone. Almost all large Windows applications are written this way: a gradual sedimentary accretion of calls to whatever Windows APIs were modern at the time of writing. Even first-party software like Office still makes calls to kernel-shimmed 16-bit APIs, right alongside calls to the modern UWP APIs. But nevertheless: > Why don't we have a version of Windows without as much legacy support? Like a security hardened (or really just modern-only) version of Windows? We did get this; it was called Windows RT, which could only run software (re)developed specifically for the WinRT platform SDK. WinRT applications are automatically sandboxed; are able to be developed in many languages, including Rust and Javascript; and, while being native code (when you use a compiled language), are also architecture-agnostic—meaning mostly that you can easily build one deliverable for the Windows Store that contains binaries for x86, ARM, and any other arch Windows Store supports, and then by downloading your app people will transparently be downloading whichever sub-package their device needs. But, well, few developers bothered, because most major pieces of software would need to be majorly rewritten to support WinRT. It was mostly used for greenfield projects by existing companies; or as a target for new Windows porting efforts (e.g. of iOS/Android software.) Originally the incentive for using WinRT was supposed to be that only WinRT apps could be sold through the Windows Store; but since so few third-parties bit this bullet, Microsoft backed off and allowed all their biggest bigcorp partners—exactly the people they were really trying to convince—to just submit non-WinRT apps to the store. As of that moment, WinRT-the-SDK was dead in the water; basically no large project has been rewritten for it since then.
pjc50 6y ago
I think the key problem is that it's very old; almost certainly the core code dates from NT, possibly earlier. Longer analysis: https://windows-internals.com/printdemon-cve-2020-1048/ https://windows-internals.com/printdemon-cve-2020-1048/ The core is: a) you can set up a printer port that prints to a file b) no admin privilege is required to do this, just a check on the ownership of the file c) the ownership check is in the wrong place, so you can just create a port that prints to a DLL in system32 d) a second export forces Windows to load that DLL and run a specific function as SYSTEM, at which point game over
JeremyHerrman 6y ago
FYI this comment is getting roasted on twitter https://twitter.com/browserdotsys/status/1261100295704190981 https://twitter.com/browserdotsys/status/1261100295704190981

by Jonnax 6y ago

derefr 6y ago

It is indeed possible to design a system that only works as a client for network printers as a pure-userland service; I believe this is what iOS has, in the form of AirPrint. But most OS printing services cover both network and local (USB, parallel, even serial!) printing, and therefore the print daemon needs to essentially "own" ACLs on some collection of USB-devices and even "own" direct bit-banging access to a set of serial/parallel-ports, in the same sense that X11 gets to own VRAM memory-regions, or an audio daemon gets to own bit-banging access to a set of DAC controllers. Coupled with this is the problem of supporting legacy software that expects older consumer-microcomputer OS paradigms for device access. This isn't so much of a problem on POSIX systems, where the oldest paradigm (having /var/spool as a sticky dir, where roff(1) would just write files there) was already multitenant-friendly; you just need a print daemon (CUPS) that can watch /var/spool for changes, along with its non-legacy API. I believe you can roff(1) even within Termux on Android, and it'll "just work", without special kernel support other than the generic filesystem notification-event API. But Windows specifically inherits a print-system design all the way from DOS, and still supports software (e.g. Win9x software written for the Win32 API) that was written to expect that legacy API. I don't know too much about the Win32 print API specifically, but I'd guess that it was designed to be a forward-compatible shim on top of the DOS printing "API"—which was really just allowing the application to bang bits down the serial/parallel port through memory-mapped IO. That's what the "LPT1", "COM", etc. devices in Windows are: emulations of those same legacy memory-mapped IO channels that only make sense to access in a single-tasking OS. But, as of NT/W2K, it's actually the OS on the other end of that pipe, arbitrating data flows. So that's another thing that needs to happen in kernel-land in Windows: the emulation of an unprotected MMIO memory region within the process's address space, as a glorified syscall ABI, which just (these days) routes messages to the userspace print daemon, but back in Win9x probably did do all its work in kernelspace.

ancarda 6y ago
Why don't we have a version of Windows without as much legacy support? Like a security hardened (or really just modern-only) version of Windows? I suspect most people would be fine using that version of Windows, and it would have less security problems.
- derefr 6y ago
  Much of the "point" of Windows as a platform at this point (i.e. the reason that developers stick with targeting Windows APIs, instead of re-developing their software for portability using Java or Qt or Electron or whatever-else) is backward-compatibility. People say that a lot, but it has a very specific meaning when talking about a platform SDK: "backward compatibility" here specifically means that if you wrote version N of your software for version N of Windows, then when you're writing version N+1 of your software targeting version N+1 of Windows, you don't need to re-write any of the old code. You can just start taking advantage of the new Windows API features in the new code you write, while leaving your old code that calls legacy Windows APIs alone. Almost all large Windows applications are written this way: a gradual sedimentary accretion of calls to whatever Windows APIs were modern at the time of writing. Even first-party software like Office still makes calls to kernel-shimmed 16-bit APIs, right alongside calls to the modern UWP APIs. But nevertheless: > Why don't we have a version of Windows without as much legacy support? Like a security hardened (or really just modern-only) version of Windows? We did get this; it was called Windows RT, which could only run software (re)developed specifically for the WinRT platform SDK. WinRT applications are automatically sandboxed; are able to be developed in many languages, including Rust and Javascript; and, while being native code (when you use a compiled language), are also architecture-agnostic—meaning mostly that you can easily build one deliverable for the Windows Store that contains binaries for x86, ARM, and any other arch Windows Store supports, and then by downloading your app people will transparently be downloading whichever sub-package their device needs. But, well, few developers bothered, because most major pieces of software would need to be majorly rewritten to support WinRT. It was mostly used for greenfield projects by existing companies; or as a target for new Windows porting efforts (e.g. of iOS/Android software.) Originally the incentive for using WinRT was supposed to be that only WinRT apps could be sold through the Windows Store; but since so few third-parties bit this bullet, Microsoft backed off and allowed all their biggest bigcorp partners—exactly the people they were really trying to convince—to just submit non-WinRT apps to the store. As of that moment, WinRT-the-SDK was dead in the water; basically no large project has been rewritten for it since then.

pjc50 6y ago

I think the key problem is that it's very old; almost certainly the core code dates from NT, possibly earlier. Longer analysis: https://windows-internals.com/printdemon-cve-2020-1048/ https://windows-internals.com/printdemon-cve-2020-1048/ The core is: a) you can set up a printer port that prints to a file b) no admin privilege is required to do this, just a check on the ownership of the file c) the ownership check is in the wrong place, so you can just create a port that prints to a DLL in system32 d) a second export forces Windows to load that DLL and run a specific function as SYSTEM, at which point game over

JeremyHerrman 6y ago

FYI this comment is getting roasted on twitter https://twitter.com/browserdotsys/status/1261100295704190981 https://twitter.com/browserdotsys/status/1261100295704190981