Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2018-5702: Mitigate dns rebinding attacks against daemon #468

Merged
merged 1 commit into from Jan 15, 2018
Merged

CVE-2018-5702: Mitigate dns rebinding attacks against daemon #468

merged 1 commit into from Jan 15, 2018

Conversation

taviso
Copy link
Contributor

@taviso taviso commented Jan 11, 2018

This issue was originally reported to the private transmission security list on November 30th 2017

Transmission uses a client/server architecture, the user interface is the client and a daemon runs in the background managing the downloading, seeding, etc.

Clients interact with the daemon using JSON RPC requests to a web server listening on port 9091. The daemon will only accept requests from localhost by default, but it's common to configure NAS devices to accept remote clients.

Note: I regularly encounter users who don't accept that websites can access services on localhost or their intranet. These users understand that services bound to localhost are only accessible to software running on the local machine, and that their browser is running on the local machine - but somehow believe that accessing a website "transfers" execution somewhere else. It doesn't work like that, but this is a common source of confusion.

A sample RPC session looks like this:

$ curl -sI http://localhost:9091/transmission/rpc
HTTP/1.1 409 Conflict
Server: Transmission
X-Transmission-Session-Id: JL641xTn2h53UsN6bVa0kJjRBLA6oX1Ayl06AJwuhHvSgE6H
Date: Wed, 29 Nov 2017 21:37:41 GMT
$ curl -H 'X-Transmission-Session-Id: JL641xTn2h53UsN6bVa0kJjRBLA6oX1Ayl06AJwuhHvSgE6H'  -d '{"method":"session-set","arguments":{"download-dir":"/home/user"}}' -si http://localhost:9091/transmission/rpc
HTTP/1.1 200 OK
Server: Transmission
Content-Type: application/json; charset=UTF-8
Date: Wed, 29 Nov 2017 21:38:57 GMT
Content-Length: 36

{"arguments":{},"result":"success"}

As with all HTTP RPC schemes like this, any website can send requests to the daemon listening on localhost with XMLHttpRequest(), but the theory is they will be ignored because clients must prove they can read and set a specific header, X-Transmission-Session-Id.

Unfortunately, this design doesn't work because of an attack called "DNS rebinding". Any website can simply create a dns name that they are authorized to communicate with, and then make it resolve to localhost.

The attack works like this:

  1. A user visits http://attacker.com, which has an <iframe> to a subdomain the attacker controls.
  2. The attacker configures their DNS server to respond alternately with 127.0.0.1 and 123.123.123.123 (an address they control) with a very low TTL.
  3. When the browser resolves to 123.123.123.123, they serve HTML that waits for the DNS entry to expire (or force it to expire by flooding the cache with lookups), then they have permission to read and set headers.

I have a domain I use for testing dns rebinding called rbndr.us, you can use this page to generate hostnames (source code is here):

https://lock.cmpxchg8b.com/rebinder.html

Here I want to alternate between 127.0.0.1 and 199.241.29.227, so I use 7f000001.c7f11de3.rbndr.us:

$ host 7f000001.c7f11de3.rbndr.us
7f000001.c7f11de3.rbndr.us has address 127.0.0.1
$ host 7f000001.c7f11de3.rbndr.us
7f000001.c7f11de3.rbndr.us has address 199.241.29.227
$ host 7f000001.c7f11de3.rbndr.us
7f000001.c7f11de3.rbndr.us has address 127.0.0.1

Here you can see the resolution alternates between the two addresses I want (note that depending on caching it might take a while to switch, the TTL is set to minimum but some servers round up).

I just wait for the cached response to expire, and then POST commands to the server.

Exploitation is simple, you could set script-torrent-done-enabled and run any command, or set download-dir to /home/user/ and then upload a torrent for .bashrc.

Here is my (simple) demo, it's slow, but could be made very fast:

http://lock.cmpxchg8b.com/Asoquu3e.html

I've verified it works on Chrome and Firefox on Windows and Linux (I tried Fedora and Ubuntu), I expect other platforms and browsers are affected. There are screenshots of how the attack is supposed to look below.

This Pull Request mitigates this attack by requiring a host whitelist for requests that cannot be proven to be secure, but it can be disabled if a user does not want security. I think users might not be find it intuitive that servers on localhost or their intranet are exposed to the web, but hopefully they will read the warning.

Here are some screenshots demonstrating the attack:

Before the attack begins, the Download directory is set correctly:
fedora 64-bit-2017-11-29-16-25-19

Here is how the exploit looks:
fedora 64-bit-2017-11-29-16-25-27

Here is the exploit running:
fedora 64-bit-2017-11-29-16-25-48

The attack succeeds:
fedora 64-bit-2017-11-29-16-30-12

And the result:
fedora 64-bit-2017-11-29-16-30-26

@lfam
Copy link

lfam commented Jan 11, 2018

I naively adapted the patch so it applies to the 2.92 release (attached).
transmission-fix-dns-rebinding-vuln.patch.txt

As the CI server shows, with these changes the quark-test fails with exit status: 29.

@woodsb02
Copy link

Has a CVE been assigned for this?

@taviso
Copy link
Contributor Author

taviso commented Jan 11, 2018

I believe I've fixed the quark-test fail, the list wasn't ordered correctly.

(I broke the merge, but I think it's fixed now)

@taviso
Copy link
Contributor Author

taviso commented Jan 11, 2018

@woodsb02 No, but I've just requested one and will update when received.

@lfam
Copy link

lfam commented Jan 11, 2018

I've updated the 2.92 patch with the latest changes from @taviso. The tests do pass now.
transmission-fix-dns-rebinding-vuln.patch.txt

@wknapik
Copy link

wknapik commented Jan 12, 2018

@taviso the demo works, unless you load it over https. Mixed content.
@EFForg HTTPS Everywhere ftw!;]

@jggimi
Copy link

jggimi commented Jan 13, 2018

@taviso and @lfam thank you. I've adapted lfam's second 2.92 patch set to the OpenBSD port of transmission, which I maintain. Testing underway.

@smithfred
Copy link

Just a naïve question for my own edification - this basically uses Host for header checking-based protection instead of relying on X-Transmission-Session-Id, because Host is a Fetch Standard forbidden header name, and so not vulnerable to the same exploit, is that correct?

@taviso
Copy link
Contributor Author

taviso commented Jan 13, 2018

@smithfred Yes, correct.

@wfiveash
Copy link

If transmission is configured such that the daemon/web server requires authorization (user ID, password) does this mitigate this attack?

@taviso
Copy link
Contributor Author

taviso commented Jan 13, 2018

@wfiveash Yes, but be aware that it's possible to guess the credentials, so make them strong.

@lfam
Copy link

lfam commented Jan 13, 2018

@jggimi Okay, let us know if you notice any problems.

Remember I described my adaptation as "naive". I only made sure the patch applies and Transmission still works.

uqs pushed a commit to freebsd/freebsd-ports that referenced this pull request Jan 14, 2018
Incorporate upstream pull request 468, proposed by Tavis Ormandy from
Google Project Zero, which mitigates this attack by requiring a host
whitelist for requests that cannot be proven to be secure, but it can
be disabled if a user does not want security.

PR:		225150
Submitted by:	Tavis Ormandy
Approved by:	crees (maintainer)
Obtained from:	transmission/transmission#468 (comment)
MFH:		2018Q1
Security:	https://www.vuxml.org/freebsd/3e5b8bd3-0c32-452f-a60e-beab7b762351.html


git-svn-id: svn+ssh://svn.freebsd.org/ports/head@459011 35697150-7ecd-e111-bb59-0022644237b5
uqs pushed a commit to freebsd/freebsd-ports that referenced this pull request Jan 14, 2018
Incorporate upstream pull request 468, proposed by Tavis Ormandy from
Google Project Zero, which mitigates this attack by requiring a host
whitelist for requests that cannot be proven to be secure, but it can
be disabled if a user does not want security.

PR:		225150
Submitted by:	Tavis Ormandy
Approved by:	crees (maintainer)
Obtained from:	transmission/transmission#468 (comment)
MFH:		2018Q1
Security:	https://www.vuxml.org/freebsd/3e5b8bd3-0c32-452f-a60e-beab7b762351.html
@woodsb02
Copy link

In my setup, the settings.json file is re-written each time transmission-daemon is started, based on the command line arguments passed to it.

Can we please add new command line arguments to transmission-daemon set the rpc-host-whitelist-enabled and rpc-host-whitelist parameters?

andir added a commit to andir/nixpkgs that referenced this pull request Jan 14, 2018
andir added a commit to andir/nixpkgs that referenced this pull request Jan 14, 2018
Jehops pushed a commit to Jehops/freebsd-ports-legacy that referenced this pull request Jan 15, 2018
Incorporate upstream pull request 468, proposed by Tavis Ormandy from
Google Project Zero, which mitigates this attack by requiring a host
whitelist for requests that cannot be proven to be secure, but it can
be disabled if a user does not want security.

PR:		225150
Submitted by:	Tavis Ormandy
Approved by:	crees (maintainer)
Obtained from:	transmission/transmission#468 (comment)
MFH:		2018Q1
Security:	https://www.vuxml.org/freebsd/3e5b8bd3-0c32-452f-a60e-beab7b762351.html


git-svn-id: svn+ssh://svn.freebsd.org/ports/head@459011 35697150-7ecd-e111-bb59-0022644237b5
tota pushed a commit to tota/freebsd-ports that referenced this pull request Jan 15, 2018
Incorporate upstream pull request 468, proposed by Tavis Ormandy from
Google Project Zero, which mitigates this attack by requiring a host
whitelist for requests that cannot be proven to be secure, but it can
be disabled if a user does not want security.

PR:		225150
Submitted by:	Tavis Ormandy
Approved by:	crees (maintainer)
Obtained from:	transmission/transmission#468 (comment)
MFH:		2018Q1
Security:	https://www.vuxml.org/freebsd/3e5b8bd3-0c32-452f-a60e-beab7b762351.html


git-svn-id: svn+ssh://svn.freebsd.org/ports/head@459011 35697150-7ecd-e111-bb59-0022644237b5
@msmeissn
Copy link

cve requested at Mitre.org

@msmeissn
Copy link

CVE-2018-5702

@taviso taviso changed the title mitigate dns rebinding attacks against daemon CVE-2018-5702: Mitigate dns rebinding attacks against daemon Jan 15, 2018
cfpp2p pushed a commit to cfpp2p/transmission that referenced this pull request Jan 21, 2018
@lnicola
Copy link

lnicola commented Jan 21, 2018

Yes, but be aware that it's possible to guess the credentials, so make them strong.

@taviso Does [enabling rpc-password] mitigate this even if I previously connected to the Web UI? Transmission uses HTTP Basic Authentication and e.g. Firefox caches that until it's closed.

EDIT: Suppose so, since the credentials I logged in with are for a different origin.

@taviso
Copy link
Contributor Author

taviso commented Jan 21, 2018

@lnicola Yep, exactly, it will be a different hostname and so credentials won't be cached. Transmission already has a CSRF protection scheme, so you can't just POST commands to the real hostname.

buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this pull request Jan 28, 2018
Fixes CVE-2018-5702:
transmission/transmission#468

Added license hash.

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
alllexx88 pushed a commit to Optware/Optware-ng that referenced this pull request Jan 30, 2018
Fix CVE-2018-5702 (#468)
REQUIRE authentication always. Fixes transmission/transmission#468
Fix memory leak in `tr_dhtInit` in failure condition
Fixes transmission/transmission#482
buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this pull request Jan 31, 2018
Fixes CVE-2018-5702:
transmission/transmission#468

Added license hash.

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 6e43a52)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this pull request Jan 31, 2018
Fixes CVE-2018-5702:
transmission/transmission#468

Added license hash.

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 6e43a52)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
@1265578519
Copy link

这需要更新html来修复还是核心?

CGA1123 added a commit to CGA1123/F20AN that referenced this pull request Feb 21, 2018
Tavis Ormandy from Google Project Zero reported this Vulnerability to
the Transmission team and wrote up an exploit to demo it. This code is a
slightly refactored version of that code.

See: transmission/transmission#468 for the PR
See: lock.cmpxchg8b.com/Asoquu3e.html for the original exploit page
@joq3
Copy link

joq3 commented Feb 22, 2018

I have used an NGinx Reverse Proxy on my server for a while now, and directly after I installed this update I could no longer visit Transmission via my domain.
I have made some changes and I have come as far as being able to reach it with https://bt.mydomain.com/web/, but if I try https://bt.mydomain.com it will only give me the "409: Conflict Your request had an invalid session-id header.".

This is the current Nginx setup: https://hastebin.com/oyicigowuz.nginx

I have tried changing proxy_pass to http://localhost:9091/transmission/web/; but that won't work at all.

Please help me solve this new problem. Thank you!

@1265578519
Copy link

@joq3 用nginx不麻烦么。。

@joq3
Copy link

joq3 commented Feb 25, 2018

@1265578519 sorry? I don't understand?

@1265578519
Copy link

@joq3 你根本不用通过nginx,直接通过DNS解析你的域名,通过域名:9091访问即可。

@mikedld
Copy link
Member

mikedld commented Feb 25, 2018

@1265578519 When walking into a room with 17 people conversing in English, please speak English.

uqs pushed a commit to freebsd/freebsd-ports that referenced this pull request Apr 1, 2021
net-p2p/transmission-daemon: Mitigate DNS rebinding attack

Incorporate upstream pull request 468, proposed by Tavis Ormandy from
Google Project Zero, which mitigates this attack by requiring a host
whitelist for requests that cannot be proven to be secure, but it can
be disabled if a user does not want security.

PR:		225150
Submitted by:	Tavis Ormandy
Approved by:	crees (maintainer)
Obtained from:	transmission/transmission#468 (comment)
Security:	https://www.vuxml.org/freebsd/3e5b8bd3-0c32-452f-a60e-beab7b762351.html

Add note to UPDATING for net-p2p/transmission-daemon explaining how to
allow client access with the new DNS rebinding mitigations.

PR:		225150
Security:	https://www.vuxml.org/freebsd/3e5b8bd3-0c32-452f-a60e-beab7b762351.html

net-p2p/transmission-daemon: Improve UPDATING entry and add pkg-message

This will ensure users who do not read UPDATING are still presented with
the message about how to allow clients to connect to the daemon using
DNS when they upgrade the package.

PR:		225150
Reported by:	swills
Security:	https://www.vuxml.org/freebsd/3e5b8bd3-0c32-452f-a60e-beab7b762351.html

Approved by:	ports-secteam (swills)
svmhdvn pushed a commit to svmhdvn/freebsd-ports that referenced this pull request Jan 10, 2024
Incorporate upstream pull request 468, proposed by Tavis Ormandy from
Google Project Zero, which mitigates this attack by requiring a host
whitelist for requests that cannot be proven to be secure, but it can
be disabled if a user does not want security.

PR:		225150
Submitted by:	Tavis Ormandy
Approved by:	crees (maintainer)
Obtained from:	transmission/transmission#468 (comment)
MFH:		2018Q1
Security:	https://www.vuxml.org/freebsd/3e5b8bd3-0c32-452f-a60e-beab7b762351.html
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

None yet