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

Conversation

Projects
None yet
@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

This comment has been minimized.

Show comment
Hide comment
@lfam

lfam 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.

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

This comment has been minimized.

Show comment
Hide comment
@woodsb02

woodsb02 Jan 11, 2018

Has a CVE been assigned for this?

woodsb02 commented Jan 11, 2018

Has a CVE been assigned for this?

@taviso

This comment has been minimized.

Show comment
Hide comment
@taviso

taviso 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 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

This comment has been minimized.

Show comment
Hide comment
@taviso

taviso Jan 11, 2018

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

taviso commented Jan 11, 2018

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

@lfam

This comment has been minimized.

Show comment
Hide comment
@lfam

lfam 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

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

This comment has been minimized.

Show comment
Hide comment
@wknapik

wknapik Jan 12, 2018

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

wknapik commented Jan 12, 2018

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

@jggimi

This comment has been minimized.

Show comment
Hide comment
@jggimi

jggimi 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.

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

This comment has been minimized.

Show comment
Hide comment
@smithfred

smithfred Jan 13, 2018

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?

smithfred commented Jan 13, 2018

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

This comment has been minimized.

Show comment
Hide comment
@taviso

taviso commented Jan 13, 2018

@smithfred Yes, correct.

@wfiveash

This comment has been minimized.

Show comment
Hide comment
@wfiveash

wfiveash Jan 13, 2018

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

wfiveash commented Jan 13, 2018

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

@taviso

This comment has been minimized.

Show comment
Hide comment
@taviso

taviso Jan 13, 2018

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

taviso commented Jan 13, 2018

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

@lfam

This comment has been minimized.

Show comment
Hide comment
@lfam

lfam 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.

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.

andir added a commit to andir/nixpkgs that referenced this pull request Jan 14, 2018

uqs pushed a commit to freebsd/freebsd-ports that referenced this pull request Jan 14, 2018

woodsb02
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)
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

woodsb02 woodsb02
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)
MFH:		2018Q1
Security:	https://www.vuxml.org/freebsd/3e5b8bd3-0c32-452f-a60e-beab7b762351.html

andir added a commit to andir/nixpkgs that referenced this pull request Jan 14, 2018

@woodsb02

This comment has been minimized.

Show comment
Hide comment
@woodsb02

woodsb02 Jan 14, 2018

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?

woodsb02 commented Jan 14, 2018

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

andir added a commit to andir/nixpkgs that referenced this pull request Jan 14, 2018

Jehops pushed a commit to Jehops/freebsd-ports that referenced this pull request Jan 15, 2018

Ben Woods Ben Woods
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)
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

woodsb02
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)
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

This comment has been minimized.

Show comment
Hide comment
@msmeissn

msmeissn Jan 15, 2018

cve requested at Mitre.org

msmeissn commented Jan 15, 2018

cve requested at Mitre.org

mat813 pushed a commit to mat813/freebsd-ports that referenced this pull request Jan 15, 2018

woodsb02
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)
MFH:		2018Q1
Security:	https://www.vuxml.org/freebsd/3e5b8bd3-0c32-452f-a60e-beab7b762351.html


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

This comment has been minimized.

Show comment
Hide comment
@msmeissn

msmeissn Jan 15, 2018

CVE-2018-5702

msmeissn commented Jan 15, 2018

CVE-2018-5702

@taviso taviso changed the title from mitigate dns rebinding attacks against daemon to CVE-2018-5702: Mitigate dns rebinding attacks against daemon Jan 15, 2018

uqs pushed a commit to freebsd/freebsd-ports that referenced this pull request Jan 20, 2018

woodsb02 woodsb02
MFH: r459011 r459013 r459492
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)

@lnicola lnicola referenced this pull request Jan 21, 2018

Open

New release #318

cfpp2p pushed a commit to cfpp2p/transmission that referenced this pull request Jan 21, 2018

cfpp2p pushed a commit to cfpp2p/transmission that referenced this pull request Jan 21, 2018

@lnicola

This comment has been minimized.

Show comment
Hide comment
@lnicola

lnicola 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.

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.

mat813 pushed a commit to mat813/freebsd-ports that referenced this pull request Jan 21, 2018

woodsb02
MFH: r459011 r459013 r459492
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)


git-svn-id: https://svn.freebsd.org/ports/branches/2018Q1@459493 35697150-7ecd-e111-bb59-0022644237b5
@taviso

This comment has been minimized.

Show comment
Hide comment
@taviso

taviso 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.

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.

@rzcat rzcat referenced this pull request Jan 23, 2018

Open

GeoIP support for IPv6 #977

buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this pull request Jan 28, 2018

package/transmission: security bump version to 2.93
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 added a commit to Optware/Optware-ng that referenced this pull request Jan 30, 2018

transmissiondcfp: update to revision 14734-11
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

package/transmission: security bump version to 2.93
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

package/transmission: security bump version to 2.93
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

This comment has been minimized.

Show comment
Hide comment
@1265578519

1265578519 Feb 1, 2018

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

1265578519 commented Feb 1, 2018

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

CGA1123 added a commit to CGA1123/F20AN that referenced this pull request Feb 21, 2018

Add / Refactor code from PoC test
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

This comment has been minimized.

Show comment
Hide comment
@joq3

joq3 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!

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

This comment has been minimized.

Show comment
Hide comment
@1265578519

1265578519 Feb 25, 2018

@joq3 用nginx不麻烦么。。

1265578519 commented Feb 25, 2018

@joq3 用nginx不麻烦么。。

@joq3

This comment has been minimized.

Show comment
Hide comment
@joq3

joq3 Feb 25, 2018

@1265578519 sorry? I don't understand?

joq3 commented Feb 25, 2018

@1265578519 sorry? I don't understand?

@1265578519

This comment has been minimized.

Show comment
Hide comment
@1265578519

1265578519 Feb 25, 2018

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

1265578519 commented Feb 25, 2018

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

@mikedld

This comment has been minimized.

Show comment
Hide comment
@mikedld

mikedld Feb 25, 2018

Member

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

Member

mikedld commented Feb 25, 2018

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

mat813 pushed a commit to mat813/freebsd-ports that referenced this pull request Jul 9, 2018

Ben Woods Ben Woods
MFH: r459011 r459013 r459492
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)


git-svn-id: https://svn.freebsd.org/ports/branches/2018Q1@459493 35697150-7ecd-e111-bb59-0022644237b5

@diracdeltas diracdeltas referenced this pull request Aug 2, 2018

Merged

Eth-wallet rebased #14734

0 of 10 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment