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.
I'm not a Windows user or admin, but I'm curious:
Does Samba support the corresponding protocols and emulate this behavior (and is it compatible enough with Microsoft's code to support the exploit)?
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Great idea to allow an external device to automatically install software on your computer.
What are these people thinking?... or not...
I don't read your sig. Why are you reading mine?
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 ;)
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.
Interesting.
So bad guys don't even have to hack a printer to exploit this bug. They can just host a Samba print server (maybe even without a printer attached) with the nasty driver in its database. Anyone who tries to print on that "printer" from a Windows machine gets pwned.
Ought to fit in a BeagleBone, Raspberry, Shiva Plug, etc., or something even smaller, just fine. Plug it into an Ethernet LAN, or just plug in a USB WiFi dongle and it can advertise on the air like any other WiFi-connectable printer.
Add a battery, good for a few days, and they have a pocket-sized exploiter that they can carry or drop within radio range of an office, or bury in the packing material of something they mail to the victim.
If it can detect a local printer and masquerade as it, forwarding the print jobs to it, there might be no obvious sign that anything unusual was happening.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I am also wondering about why you actually need to run printer driver code with system privileges. Isn't that a wrong approach? Yes, I agree printer drivers might not be required at all, but why do network printer drivers need full system privileges?
Its not that they are trying to speak over some hardware bus or something, all they need to have is an interface to the OS where the documents come in, and a network fd or something. They don't even need access to the file system, do they. Maybe for some settings and a cache and stuff. But really, they can be totally sandboxed. But well its windows...
NAT requires packet inspection. Thus every NATting device is a packet inspection engine, and having some configurable rules which packets to translate and which packets to discard gives you a stateful firewall. That's the main reason why NATting is done on the same device that does firewalling.