Slashdot Mirror
Vulnerability Exploitable Via Printer Protocols Affects All Windows Versions (softpedia.com)
An anonymous reader writes from a report via Softpedia: "Microsoft patched today a critical security vulnerability in the Print Spooler service that allows attackers to take over devices," reports Softpedia. "The vulnerability affects all Windows versions ever released. [Security firm Vectra discovered the vulnerability (CVE-2016-3238), which Microsoft fixed in MS16-087.] At its core, the issue resides in how Windows handles printer driver installations and how end users connect to printers. By default, in corporate networks, network admins allow printers to deliver the necessary drivers to workstations connected to the network. These drivers are silently installed without any user interaction and run under the SYSTEM user, with all the available privileges." An attacker can hack printers and replace these files with his own. The vulnerability is exploitable from both the local network, but also from the internet, thanks to protocols like Internet Printing Protocol or the webPointNPrint. The exploit can be delivered via ads or JavaScript code inside a compromised website. The vulnerability is actually an OS design issue and affects all Windows versions ever released. Microsoft also announced today plans to make its recently renamed Windows 10 Enterprise product available as a subscription for $7 per user per month, or $84 per year.
Yes, if you share a printer using Samba you can optionally create the print$ share that windows will use when trying to download the drivers.
As documented at https://www.suse.com/communiti... (and many other places)
Well, the computer at least needs to have a good idea of the printer capabilities. I suppose we could put that in a plain-text file, and call it 'printcap' or something. Of course, we'll also need to know how to trigger those capabilities. Maybe some sort of in-band signaling with special characters, like escape codes.
That's all good, but what if we want more advanced features like graphics. We could generate bitmaps, but that would be terribly device-specific and bandwidth-hungry. How about we use an encoding that can encapsulate the way we intend the page to look? We could call it a 'page description language'. Yeah, that'd be cool.
Well, now that we've got that, we do need some software to take the output from a program and encode it in out page description language. Otherwise, each and every program would need to know each and every common PDL. That's dumb -- we should use a standard intermediate representation that each program can speak to the OS, and let the OS transform that into the PDL of the printer it's talking to!
OK, now we've got it: a common, logical way for programs to describe their output to the OS, the OS providing a translation service to send that representation to the printer, and page description languages that let us produce sophisticated output without having to generate and transmit bitmaps and escape codes for every little thing.
That would be much better that this 'printer driver' crap, right ;)