Is it theoretically possible to hack printer using scanner tray?

Question

If the scanner tray is considered as an interface, and it accepts input (basically it is its main functionality), could it be hacked using malicious code written on a piece of paper?

In theory,YES.Maliscous input can come from anywhere and if the code handles that input improperly it could be used to execute code.But no idea if there has been any such cases or if it is even possible but in theory it should be. — yeah_well, Jun 28 '19 at 12:34
Note that's its also theoretically possible for me to win the lottery 3 times in a row. — JPhi1618, Jun 28 '19 at 20:15
At DEF CON last year, there was a talk showing how to hack into a printer via the fax line. https://www.youtube.com/watch?v=qLCE8spVX9Q — user2752467, Jun 28 '19 at 22:45
@JustinLardinois mentioned it above, but I recall that part of the attack was that you could trigger a firmware update by asking the printer to print a special page, where the "data" for page contained updated firmware. I would speculate that this would be very different for the scanner though, since scanning images is lossy anyways. — Eidolon108, Jun 29 '19 at 01:28
@JPhi1618 I'd say the possibility of a scanner having [buggy image processing code capable of producing surprising and undesirable results](http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_are_switching_written_numbers_when_scanning) is rather higher than your winning the lottery 3 times. The idea that such bugs could be also actively exploited by a sufficiently-motivated malicious actor seems well within the realm of plausibility. — jmbpiano, Jun 29 '19 at 05:10
Buggy software that crashes or produces bad images is one thing. Software that somehow accepts commands and is able to be exploited by an attacker is a totally different level that I just don’t find plausible at all. — JPhi1618, Jun 29 '19 at 05:54
@JPhi1618 it is on a matter of how much time and efforts you will put into it. Yes, it is really difficult to fuzz such interface, but it is possible. — MrSnowMan, Jun 29 '19 at 08:06
@JPhi1618 "Software that somehow accepts commands and is able to be exploited by an attacker" is exactly what [arbitrary code execution](https://en.wikipedia.org/wiki/Arbitrary_code_execution) is. In general, any software that accepts user input has a potential (however small) for such a vulnerability. — user2752467, Jun 30 '19 at 03:56
@JustinLardinois: Having been the maintainer of a mainstream Fax PC product, I can attest that it contains non-trivial amounts of input parsing of both the protocol (T.30) and the image (T.4/T.6), and I did find some such bugs who could definitely crash, and possibly be exploitable. — Jonathan, Jun 30 '19 at 09:01
@Gravemind It's not that hard to fuzz the interface. Just extract the code from the scanner firmware and feed it input from a fuzzer directly. Then you can bypass all the unnecessary physical steps of scanning. — forest, Jul 03 '19 at 07:13
@JustinLardinois _Any_ software? That's not true. No matter how hard you try, you aren't going to compromise `mv` by giving it a malicious file. The same applies to any (sane) cryptographic library that processes e.g. elliptic curve cryptography without any point verification. And, of course, formally verified software. — forest, Jul 03 '19 at 07:15
@forest I said any software has a _potential_ to have a vulnerability. Of course you can mitigate that with careful study of the source code and compiled executable (because sometimes compiler optimizations can introduce vulnerabilities). But most software, for economic or other reasons, is not subjected to that level of scrutiny. [Vulnerabilities can even exist in open source code for years before they're detected.](http://heartbleed.com/). — user2752467, Jul 03 '19 at 11:28

VL-80 · Answer 1 · 2019-10-21T15:53:44.143

45

The answer entirely depends on implementation of scanning process in the printer. Modern printers are in essence computers and they are much more powerful than their predecessors from earlier days.

So, the question boils down to "is it possible to hack a computer by using an image"?

The answer is yes, because creating exploit-free software is almost impossible as described in the answers here: Is exploit-free software possible?

Image handling libraries happen to have vulnerabilities. An attacker could entice a user to open specifically crafted image which would exploit a vulnerability on victim's computer, and therefore affect it in some way.

So, if printer's scanning process involves some sort of processing of scanned images, and its software contains bugs, then we can assume this vulnerability can be exploited by a knowledgeable attacker.

could it be hacked using malicious code written on a piece of paper?

The printer won't execute code written on a piece of paper. However, there exists probability that printer's software used for processing of scanned images contains bugs that make printer misbehave if it encounters a certain image.

The attack surface depends on how much processing the printer does with the documents that are being scanned.

The result of this is hard to tell. It depends a lot on the printer and its software, its capabilities.

edited Oct 21 '19 at 15:53

answered Jun 28 '19 at 17:18

VL-80

1,234
1
9
17

10

It seems to me that it could *theoretically* be possible to inject code via a vulnerability in an OCR process, which many multi-function copiers run automatically when scanning to PDF. – Todd Wilcox Jun 28 '19 at 21:54
23

One could imagine a printer that has a firmware update process initiated by scanning a QR code. That opens up a whole can of worms. – Barmar Jun 29 '19 at 00:13
7

The comparison with image processing libraries has some problems. In image processing, an image file might be doctored in a way to include deliberate formatting errors, like metadata specifying a size, but actual data not corresponding to it, causing buffer overflows in naive implementations of the library. Scanners don't have this easily exploitable attack surface. If they don't interpret the contents at all, they are not hackable, at least not this way. – vsz Jun 29 '19 at 20:05
3

@vsz, You are right. However theoretically there might exist exploitable bugs in image processing or compressing libraries used by the printer that misbehave while handling certain images. I think it is incorrect to completely disregard such possibility. After all, the question asks "Is it **theoretically** possible...". – VL-80 Jun 29 '19 at 20:17
6

One big issue with trying to hack a scanner with a piece of paper is the inherent noise. Scanning head stepper moves slightly less or slightly more offsetting pixels, paper may be misaligned in the first place, CFLD backlight gets slightly dimmer when specific pixels get scanned, USB buffer being full lets scanning head settle in place, attack vector manufacturing errors... QR codes fix those, but the storage capacity may be a little lacking. – John Dvorak Jun 30 '19 at 04:19
2

@vsz How many scanners do you know that can only provide RAW data and not any particular image format? Seems to me that virtually all scanners will interpret the data they receive. (how big a risk converting raw data to jpeg or similar is, is a different question, but I'm sure there's been at least one bug at a time or another there) – Voo Jul 01 '19 at 09:56
2

I think summarizing this as ""is it possible to hack a computer by using an image" is a **gross** oversimplification. Yes, vulnerabilities in image processing libraries sometimes cause vulnerabilities in applications, but those are only exploitable when the attacker can control the image (especially meta data/headers) that he image library works with. That's hardly the case here. – Conor Mancone Jul 01 '19 at 17:59

R.. GitHub STOP HELPING ICE · Answer 2 · 2019-06-28T22:52:30.687

35

VL-80's answer is good, but there are conditions under which the answer would be a clear no for "is it possible to hack a computer by using an image?" - for example, if all the code processing the image has no branches or array offsets dependent on values from the content of the image. If all the printer did was copy the image or store it in uncompressed form, that might be the case.

However, there are at least 3 places in which there are potentially exploitable code paths dependent on image content:

Compressing the image to save it, or as an unnecessary transport step internally.
Making decisions on dither patterns to reproduce the content in the most visually accurate way.
OCR.
Backdoor code in the printer placed there by the manufacturer to assess whether the image you're scanning is money, and if so, alter the result or refuse to scan it so as to prevent use in counterfeiting.

This last one is almost surely full of complex, low quality, code that's poorly understood by the people working on it, and is where I would expect to find exploitable vulnerabilities. Exploiting them would involve partially reproducing the visual signatures in currency, but in ways the algorithms don't expect to see.

edited Jun 28 '19 at 22:52

answered Jun 28 '19 at 21:42

R.. GitHub STOP HELPING ICE

7,971
1
23
35

2

What about OCR and file format conversion? – Todd Wilcox Jun 28 '19 at 21:55
Oh, OCR is another great one. I forgot they did that. – R.. GitHub STOP HELPING ICE Jun 28 '19 at 22:52
How about the print-head alignment code that prints a test image that it then scans? – Barmar Jun 29 '19 at 00:15
4

What if it parsed QR codes for some reason... – trognanders Jun 29 '19 at 03:08
@trognanders: That's another awful one but I seriously hope they don't do that. It's completely unnecessary and inappropriate attack surface. – R.. GitHub STOP HELPING ICE Jun 29 '19 at 03:12
6

@R.. I have sitting on my desk right now an Epson scanner that uses several different plastic tray inserts for various sizes of camera film and other transparent media. It uses light and dark patterns on the trays (similar in design to large, simplistic QA codes) for the purpose of identifying which tray has been inserted and correcting the orientation and size of the resultant scans. This scanner is already several years old. I wouldn't be the least surprised to learn that newer devices were using actual QA codes for similar purposes. – jmbpiano Jun 29 '19 at 05:55
9

@R.. What about parsing and interpreting the image for anti-banknote-counterfeit-measurements like the EURion constellation like it is common for color photocopiers since 1996? – H. Idden Jun 29 '19 at 11:28
14

@H.Idden: Did you even read my answer? That was the key most likely vector I pointed to. – R.. GitHub STOP HELPING ICE Jun 29 '19 at 14:59
1

@R.. I am sorry. I should have read it again after I got interrupted while reading your answer. That point got stuck in my head as "Backdoor code in the printer placed there by the manufacturer" in the sense of secret access for the manufacturer or secret re-program-interface. – H. Idden Jun 29 '19 at 17:22
No problem. There's probably that too, but I doubt there's a vector to access it via the scanned image, rather just via network phone-home/pull.. – R.. GitHub STOP HELPING ICE Jun 29 '19 at 17:42
2

I seriously doubt there's a single operating system on the market that does fulfil all your given requirements when storing data on a storage medium - i.e. no branches or dynamic offsets (how would it find the correct place to store the data after all?) – Voo Jul 01 '19 at 10:13
1

@Voo: What data-dependent paths do you expect to find in, for example, `cp a b`? (Here data is the *contents* of the file `a`, not the names `a` and `b`.) – R.. GitHub STOP HELPING ICE Jul 01 '19 at 14:31
@R.. I'd think that the size of the content is used to figure out where to store the file on disk, one way or another. I mean I haven't checked the Linux kernel for example, but it just seems likely that there'd be something in it.Surely unlikely, but a bug triggered by storing files of specific sizes in some order seems not unthinkable. – Voo Jul 01 '19 at 14:44
1

@Voo: In a general setting (not the scanner topic here), size is arguably part of the data, but completely one-dimensional and plausible for all possible cases (1 up to disk size) to have been analyzed or tested. In the scanner case, if you're not making any decisions based on content of the data, the size is a constant. – R.. GitHub STOP HELPING ICE Jul 01 '19 at 15:47
1

I strongly object to describing code intended to prevent counterfeiting as "a manufacturer back-door". Backdoor means access. The systems that try to prevent counterfeiting are simply code that is installed and run on the printer/scanner. They are no more a backdoor than any of the other code in the printer/scanner. – Conor Mancone Jul 01 '19 at 17:57
1

@ConorMancone: It's code that the user is not aware of that explicitly behaves in ways contrary to their intent or interest. This does not require their intent to be counterfeiting to have an adverse effect. – R.. GitHub STOP HELPING ICE Jul 01 '19 at 18:48
2

@R.. My objection is to the use of the term "backdoor" A backdoor gives someone unauthorized access. The code that detects counterfeiting is not a backdoor, because it does not give manufacturers access to the printer. The fact that it may behave in ways contrary to the user's interest/intent does not make it a backdoor. – Conor Mancone Jul 01 '19 at 19:16
1

@ConorMancone: I view it as at least backdoor-adjacent because it's giving decision-making authority to an algorithmic agent that a normal user doesn't even know or expect exists. Squabbling over the word is not very useful. Do you have a better word in mind? – R.. GitHub STOP HELPING ICE Jul 01 '19 at 21:44
Redefining terms to fit your narrative doesn't make it the sane thing. No access is bypassed by currency detection algorithms. – Matthew Whited Jul 02 '19 at 10:57
I'm not here to play debate club with folks who showed up via HNQ just to start an argument. If you don't like my answer you're free to downvote it. – R.. GitHub STOP HELPING ICE Jul 02 '19 at 14:45
There's also an extraneous comma after the words _low quality_. That's a far more glaring mistake than what amounts to a lateral error at worst and proper, if uncommon, usage of a word at best. Do we really have to point out such trivial things in an otherwise great answer? Let's not be petty. This answer gets my +1. – forest Jul 03 '19 at 07:08

score 4 · Answer 3 · answered Jul 01 '19 at 13:10

4

In 2017 researchers at the Cyber Security Research Center at Ben-Gurion University in Israel demonstrated a scanner attack using lasers. Drone-mounted lasers controlled by an attacker were used to communicate with malware installed behind an air-gapped system, e.g. through a window into an office.

Article here: https://arxiv.org/abs/1703.07751

This isn't exactly what is being asked about and it doesn't involve paper codes, but it may be relevant concerning scanner vulnerabilities.

Related pop-sci article here: https://www.digitaltrends.com/cool-tech/hacked-scanner-laser-drone-method/

answered Jul 01 '19 at 13:10

Nat

41
1

Calling something like this is an viable attack is a bit of a stretch. Having physical access to both ends of the systems creates an endless number of options in "attack surface". Why go though the effort, difficulty and unreliability of some link like this when you can just swap the network card/ship or install a key logger. Much easier to perform and much more reliable. Complex attacks like this work well in conferences and Hollywood but have no practical use. – Matthew Whited Jul 01 '19 at 14:34
@MatthewWhited seeing as the question says "theoretically possible" I think this answer fits well. – Sam Dean Jul 02 '19 at 08:33
Requiring custom hardware and software to perform an "attack" is not an attack in any practical sense. This is about like saying toasters are an attack vector for your data because someone could install a wifi bridge without your knowledge. – Matthew Whited Jul 02 '19 at 10:52

score 4 · Answer 4 · edited Jun 16 '20 at 09:49

I will be the contrarian here.

could it be hacked using malicious code written on a piece of paper?

Absolutely not

While bugs in image processing libraries do happen, writing code on a piece of paper, scanning it, and expecting it to execute on the scanner for hacking purposes is the kind of thing that only happens in (bad) movies. Especially when it comes to making the scanner literally execute code that is written on a piece of paper, we're far past the realm of probability for accidental bugs and entering a realm where this would have to be programmed intentionally - and even then it wouldn't be very useful.

Of course we can loosen that requirement and ask about more "standard" weaknesses instead of literally executing code on a page. From that perspective there are three main areas of concern:

Vulnerabilities in imaging hardware - highly unlikely

You'll have the most success if you can do something to "trick" the imaging hardware into behaving in unexpected ways. If you have full control over the hardware of course this is entirely plausible - shoot lasers at it, replace chips, etc... Except that's obviously not what we're talking about. We're talking about taking over the system by scanning a "malicious" page using the system's normal operations.

Realistically though, there is no reason to think you'll find any help in hardware issues. I'm speaking here from my own years of experience performing extensive image processing on raw images straight out of hardware (in my case I was performing image processing on data coming out of CCDs, so a slightly different use case). In my experience with CCDs, the CCDs would always generate valid images (valid in this case means only that it produces images in the proper format - not that the image itself is necessarily meaningful). It was quite impossible for them to do anything else due to physical limitations of the hardware, even when exposed to sources they weren't intended to be used with (which isn't an option here anyway).

Note that I'm not trying to say that the hardware might not have issues or "hiccups". However, there is no reason to think that a specially crafted piece of paper might cause trouble for the actual imaging hardware - generally they just don't work like that.

Vulnerabilities in image processing libraries - also a no-go

This has been mentioned in previous answers. There have been a number of instances of security vulnerabilities in image processing libraries, sometimes even to the extent of a code-execution vulnerability.

However, that doesn't mean that this is a serious concern for scanners - in fact, it isn't. The trouble is that, for vulnerabilities in image processing libraries to be exploitable, the attacker has to have substantial control over the input into the image processing library. That simply isn't the case here. Instead the attacker has control over the input to the scanning hardware. The image processing library then works off of what it is given by the hardware. Therefore, to exploit a bug in the image processing library would require not just a bug in the image processing library but also a flaw in the imaging hardware that allows the attacker's "payload" to somehow survive the imaging process (which is itself subject to many sources of random error and bias, likely rendering a consistent exploit completely impossible).

Can I "prove" that such a thing is impossible? Of course not. Crazy things do happen after all, and many real world exploits happen as a result of failures at multiple levels. However, just because something might be considered "plausible" doesn't mean that it should be a real security concern, or even that it has ever happened. I certainly wouldn't waste my time trying to check the security of my office scanners/copiers for these kinds of vulnerabilities.

OCR capabilities - also not a concern

The possibility of weaknesses in OCR have been brought up. This is also not a serious concern. There are two important realities that make this a non-starter:

Most copiers don't come with built in OCR software
RCE vulnerabilities in OCR software are virtually unheard of.

Honestly, I'm just going to leave it at that.

Summary

Sure, vulnerabilities have been found in very unexpected places, and you never know what crazy things will end up in code/hardware. However, this is security.stackexchange, not worldbuilding.stackexchange, so I think an answer grounded in reality is important. Therefore I want to emphasize that, while just about anything is possible when it comes to security weaknesses, this is an attempt to hack a system at what is effectively it strongest point. The imaging hardware is effectively a powerful input normalization system, and getting a malicious payload through it should be nearly impossible. Moreover, the kinds of weaknesses that are typically present in image processing libraries rely on making modifications to images in ways that someone "attacking" through the imaging hardware physically cannot perform.

Possible? Only in the sense that any event with a non-zero probability is possible. A legitimate concern? Definitely not. I wouldn't even describe it as "theoretically" possible.

Good point, I like your answer. – MrSnowMan Jul 02 '19 at 13:28 — MrSnowMan, Jul 02 '19 at 13:28

score 1 · Answer 5 · answered Oct 21 '19 at 21:36

Theoretically possible? Yes, sure

With the scanner running the human-readable text written there? Not really, as mentioned in other answers. You would need to have a printer programmed to do something at least slightly similar. For instance, if this scanner had an Alexa assistant that expected written queries.

However, I don't think "malicious code written on a piece of paper" needs to be taken that way. The code may take many forms. In fact, the main problema for real-world explotaition will be, once you have X scanned data launching your exploit, to get a piece of paper that gets scanned to that code, since a difference of one bit will result in a completely different shellcode (a non-working one, actually). E en with a monochrome low resolution scan, you will need high prevision crafting the piece of paper.

As for which vulnerable code that could to the exploit, and this enters more into the worldbuilding realm, I would suggest the feature to prevent money photocopies.

Many photocopies detect a pattern on bank notes (the "EURion constellation) in order to refuse copying money.

This means that there is a secret specification of how the circles may be located (although a large part has been reversed), a corresponding secret algorithm used by the scanner manufacturer to detect them (whose publication could show how to 'game' the detection) and in general a quite secretive code (probably only a few people will have access to it) which won't be highly tested (in particulsr, due to the above reasons, the tests will likely consist in scanning a bank note or certain test paper).

Also note that this code will be running after the hardware copied the image. So you could imagine an exploit pattern that was located in such a way (e.g. at the begin/end of the scan data), with a naive EURion code that on finding a circle candidate, looks for another one at X location foñrom it -with no bounds check-. If that vulnerability leaded to code execution, you would only need to jump anywhere into the image data (in memory at this point), where there would be a large nop-sled leading to the shellcode (that, if it is a printer could then execute a later postcript stage).