4 ms·

My understanding is that its it's about the code path for installation of drivers that is being exploited. In order for people to print to printers not seen bef

by kerng 5y ago

My understanding is that its it's about the code path for installation of drivers that is being exploited. In order for people to print to printers not seen before, Windows downloads and installs the driver automatically from a remote printer when a low privilege user wants to print. I guess that's why it runs as high privilege. Not defending anything just hoping to provide useful insights.

tialaramex 5y ago
This feels like the sum of many independently defensible decisions that somebody ought to have stood back from and gone "Woah, that's not OK" overall. Should we do a modern rewrite of the print spooler, maybe cut it up into different chunks following modern practices and use the less risky codepaths invented since it was built? No, printing is no longer critical path for many customers, so minimal budget for this software. Should there be a separate fancy print spooler for the people who might actually want unprivileged print requests to result in magically installing privileged device drivers? Alas this would take a rewrite, which we can't do, see above. Should the print spooler have SYSTEM? Alas the single print spooler we ended up with because of the above decision needs SYSTEM or it will not function as intended. Should machines with no business printing anything need Print Spoolers (which get SYSTEM)? Alas the single print spooler we ended up with also performs necessary central clean-up that must take place on systems with no print spool. Only when you zoom out and see the result is it obvious, we should spend some of our security budget getting rid of this arrangement, it's clearly a problem waiting to happen.
tonyedgecombe 5y ago
>My understanding is that its it's about the code path for installation of drivers that is being exploited. That was the PrintNightmare exploit. There don't seem to be any details on this one yet.

by kerng 5y ago

tialaramex 5y ago

This feels like the sum of many independently defensible decisions that somebody ought to have stood back from and gone "Woah, that's not OK" overall. Should we do a modern rewrite of the print spooler, maybe cut it up into different chunks following modern practices and use the less risky codepaths invented since it was built? No, printing is no longer critical path for many customers, so minimal budget for this software. Should there be a separate fancy print spooler for the people who might actually want unprivileged print requests to result in magically installing privileged device drivers? Alas this would take a rewrite, which we can't do, see above. Should the print spooler have SYSTEM? Alas the single print spooler we ended up with because of the above decision needs SYSTEM or it will not function as intended. Should machines with no business printing anything need Print Spoolers (which get SYSTEM)? Alas the single print spooler we ended up with also performs necessary central clean-up that must take place on systems with no print spool. Only when you zoom out and see the result is it obvious, we should spend some of our security budget getting rid of this arrangement, it's clearly a problem waiting to happen.

tonyedgecombe 5y ago

>My understanding is that its it's about the code path for installation of drivers that is being exploited. That was the PrintNightmare exploit. There don't seem to be any details on this one yet.