| 2015-04-27 12:20:11 |
Malcolm Scott |
bug |
|
|
added bug |
| 2015-04-27 12:21:38 |
Malcolm Scott |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658 |
|
| 2015-04-27 12:21:38 |
Malcolm Scott |
bug task added |
|
systemd |
|
| 2015-04-27 12:38:46 |
Martin Pitt |
systemd (Ubuntu): status |
New |
Triaged |
|
| 2015-04-27 12:38:48 |
Martin Pitt |
systemd (Ubuntu): importance |
Undecided |
Low |
|
| 2015-04-27 23:44:23 |
Bug Watch Updater |
systemd: status |
Unknown |
Fix Released |
|
| 2015-06-08 17:55:36 |
Aminda Suomalainen |
bug |
|
|
added subscriber Mikaela Suomalainen |
| 2015-11-24 11:16:04 |
stinger |
bug |
|
|
added subscriber stinger |
| 2016-10-10 21:52:46 |
Anders Kaseorg |
bug watch added |
|
https://github.com/systemd/systemd/issues/4175 |
|
| 2016-10-10 21:56:37 |
Anders Kaseorg |
bug |
|
|
added subscriber Anders Kaseorg |
| 2016-12-07 10:04:58 |
Martin Pitt |
tags |
|
resolved |
|
| 2017-06-20 18:01:48 |
Brian Murray |
tags |
resolved |
resolved rls-aa-incoming |
|
| 2017-06-21 09:49:21 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Artful |
|
| 2017-06-21 09:49:21 |
Dimitri John Ledkov |
bug task added |
|
systemd (Ubuntu Artful) |
|
| 2017-06-21 09:49:21 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Yakkety |
|
| 2017-06-21 09:49:21 |
Dimitri John Ledkov |
bug task added |
|
systemd (Ubuntu Yakkety) |
|
| 2017-06-21 09:49:21 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-06-21 09:49:21 |
Dimitri John Ledkov |
bug task added |
|
systemd (Ubuntu Xenial) |
|
| 2017-06-21 09:49:21 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-06-21 09:49:21 |
Dimitri John Ledkov |
bug task added |
|
systemd (Ubuntu Zesty) |
|
| 2017-06-21 09:49:57 |
Dimitri John Ledkov |
systemd (Ubuntu Artful): assignee |
|
Dimitri John Ledkov (xnox) |
|
| 2017-06-21 09:50:02 |
Dimitri John Ledkov |
systemd (Ubuntu Artful): milestone |
|
ubuntu-17.06 |
|
| 2017-06-21 15:47:38 |
Dimitri John Ledkov |
systemd (Ubuntu Artful): status |
Triaged |
Fix Committed |
|
| 2017-06-21 23:35:28 |
Anders Kaseorg |
bug task added |
|
systemd (Debian) |
|
| 2017-06-21 23:35:45 |
Anders Kaseorg |
systemd: importance |
Unknown |
Undecided |
|
| 2017-06-21 23:35:45 |
Anders Kaseorg |
systemd: status |
Fix Released |
New |
|
| 2017-06-21 23:35:45 |
Anders Kaseorg |
systemd: remote watch |
Debian Bug tracker #761658 |
|
|
| 2017-06-22 15:38:10 |
Dimitri John Ledkov |
tags |
resolved rls-aa-incoming |
resolved |
|
| 2017-06-22 15:43:42 |
Bug Watch Updater |
systemd (Debian): status |
Unknown |
Fix Released |
|
| 2017-07-02 18:19:36 |
Launchpad Janitor |
systemd (Ubuntu Artful): status |
Fix Committed |
Fix Released |
|
| 2017-07-02 18:19:36 |
Launchpad Janitor |
cve linked |
|
2017-9445 |
|
| 2017-07-04 08:57:31 |
Dimitri John Ledkov |
bug task deleted |
systemd (Ubuntu Xenial) |
|
|
| 2017-07-12 08:17:55 |
Launchpad Janitor |
systemd (Ubuntu Yakkety): status |
New |
Confirmed |
|
| 2017-07-12 08:17:55 |
Launchpad Janitor |
systemd (Ubuntu Zesty): status |
New |
Confirmed |
|
| 2017-07-21 09:23:08 |
Dimitri John Ledkov |
bug task deleted |
systemd (Ubuntu Yakkety) |
|
|
| 2017-08-05 09:47:29 |
Andre |
bug |
|
|
added subscriber Andre |
| 2017-08-31 10:12:59 |
Dimitri John Ledkov |
systemd (Ubuntu Zesty): status |
Confirmed |
In Progress |
|
| 2017-09-04 10:44:35 |
Dimitri John Ledkov |
description |
systemd-resolved will fall back to Google public DNS (8.8.8.8, etc.) in the absence of other configured DNS servers.
systemd-resolved is not enabled by default in Ubuntu 15.04, but it is installed by default and will behave in this way if enabled by the user.
$ cat /etc/systemd/resolved.conf
(...)
# Entries in this file show the compile time defaults.
(...)
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
This raises privacy concerns since in the event of accidental misconfiguration DNS queries will be sent unencrypted across the internet, and potentially also security concerns given systemd-resolved does not perform DNSSEC validation and is not particularly well hardened against malicious responses e.g. from a MITM (http://www.openwall.com/lists/oss-security/2014/11/12/5).
I believe that it would be better to fail safe if no DNS server is configured -- i.e. have DNS lookups fail; it's better that the user is aware of their misconfiguration, rather than silently sending their queries to Google. The user can intentionally opt to use Google public DNS if they wish.
Steps to reproduce:
1. Remove existing DNS configuration (from /etc/network/interfaces, /etc/resolv.conf, /etc/resolvconf/resolv.conf.d/*)
2. Reboot, or otherwise clear relevant state
3. sudo service systemd-resolved start
4. Note that Google's servers are listed in /run/systemd/resolve/resolv.conf
5. If systemd-resolved is enabled in /etc/nsswitch.conf (it isn't by default), observe that DNS lookups probably still work, and queries are being sent to one of Google's servers
Possible workaround/bugfix: ship a resolved.conf which clears the FallbackDNS parameter.
This issue has been discussed in the Debian BTS (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658). My interpretation of the Debian package maintainer's position is that a user concerned with the privacy implications shouldn't let systemd get into a state where it uses the fallback DNS servers (quoting Marco d'Itri: "Short summary: have a resolv.conf file or use DHCP"). I would argue that it's safest not to have fallback DNS servers configured at all by default. |
[Impact]
systemd-resolved will fall back to Google public DNS (8.8.8.8, etc.) in the absence of other configured DNS servers.
systemd-resolved is not enabled by default in Ubuntu 15.04, but it is installed by default and will behave in this way if enabled by the user.
$ cat /etc/systemd/resolved.conf
(...)
# Entries in this file show the compile time defaults.
(...)
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
This raises privacy concerns since in the event of accidental misconfiguration DNS queries will be sent unencrypted across the internet, and potentially also security concerns given systemd-resolved does not perform DNSSEC validation and is not particularly well hardened against malicious responses e.g. from a MITM (http://www.openwall.com/lists/oss-security/2014/11/12/5).
I believe that it would be better to fail safe if no DNS server is configured -- i.e. have DNS lookups fail; it's better that the user is aware of their misconfiguration, rather than silently sending their queries to Google. The user can intentionally opt to use Google public DNS if they wish.
[Testcase]
Steps to reproduce:
1. Remove existing DNS configuration (from /etc/network/interfaces, /etc/resolv.conf, /etc/resolvconf/resolv.conf.d/*)
2. Reboot, or otherwise clear relevant state
3. sudo service systemd-resolved start
4. Note that Google's servers are listed in /run/systemd/resolve/resolv.conf
5. If systemd-resolved is enabled in /etc/nsswitch.conf (it isn't by default), observe that DNS lookups probably still work, and queries are being sent to one of Google's servers
Possible workaround/bugfix: ship a resolved.conf which clears the FallbackDNS parameter.
[Solution]
In ubuntu, we disable fallback DNS at build time, via build system configuration flags.
This issue has been discussed in the Debian BTS (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658). My interpretation of the Debian package maintainer's position is that a user concerned with the privacy implications shouldn't let systemd get into a state where it uses the fallback DNS servers (quoting Marco d'Itri: "Short summary: have a resolv.conf file or use DHCP"). I would argue that it's safest not to have fallback DNS servers configured at all by default. |
|
| 2017-09-04 10:48:22 |
Dimitri John Ledkov |
description |
[Impact]
systemd-resolved will fall back to Google public DNS (8.8.8.8, etc.) in the absence of other configured DNS servers.
systemd-resolved is not enabled by default in Ubuntu 15.04, but it is installed by default and will behave in this way if enabled by the user.
$ cat /etc/systemd/resolved.conf
(...)
# Entries in this file show the compile time defaults.
(...)
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
This raises privacy concerns since in the event of accidental misconfiguration DNS queries will be sent unencrypted across the internet, and potentially also security concerns given systemd-resolved does not perform DNSSEC validation and is not particularly well hardened against malicious responses e.g. from a MITM (http://www.openwall.com/lists/oss-security/2014/11/12/5).
I believe that it would be better to fail safe if no DNS server is configured -- i.e. have DNS lookups fail; it's better that the user is aware of their misconfiguration, rather than silently sending their queries to Google. The user can intentionally opt to use Google public DNS if they wish.
[Testcase]
Steps to reproduce:
1. Remove existing DNS configuration (from /etc/network/interfaces, /etc/resolv.conf, /etc/resolvconf/resolv.conf.d/*)
2. Reboot, or otherwise clear relevant state
3. sudo service systemd-resolved start
4. Note that Google's servers are listed in /run/systemd/resolve/resolv.conf
5. If systemd-resolved is enabled in /etc/nsswitch.conf (it isn't by default), observe that DNS lookups probably still work, and queries are being sent to one of Google's servers
Possible workaround/bugfix: ship a resolved.conf which clears the FallbackDNS parameter.
[Solution]
In ubuntu, we disable fallback DNS at build time, via build system configuration flags.
This issue has been discussed in the Debian BTS (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658). My interpretation of the Debian package maintainer's position is that a user concerned with the privacy implications shouldn't let systemd get into a state where it uses the fallback DNS servers (quoting Marco d'Itri: "Short summary: have a resolv.conf file or use DHCP"). I would argue that it's safest not to have fallback DNS servers configured at all by default. |
[Impact]
systemd-resolved will fall back to Google public DNS (8.8.8.8, etc.) in the absence of other configured DNS servers.
systemd-resolved is not enabled by default in Ubuntu 15.04, but it is installed by default and will behave in this way if enabled by the user.
$ cat /etc/systemd/resolved.conf
(...)
# Entries in this file show the compile time defaults.
(...)
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
This raises privacy concerns since in the event of accidental misconfiguration DNS queries will be sent unencrypted across the internet, and potentially also security concerns given systemd-resolved does not perform DNSSEC validation and is not particularly well hardened against malicious responses e.g. from a MITM (http://www.openwall.com/lists/oss-security/2014/11/12/5).
I believe that it would be better to fail safe if no DNS server is configured -- i.e. have DNS lookups fail; it's better that the user is aware of their misconfiguration, rather than silently sending their queries to Google. The user can intentionally opt to use Google public DNS if they wish.
[Testcase]
Steps to reproduce:
1. Remove existing DNS configuration (from /etc/network/interfaces, /etc/resolv.conf, /etc/resolvconf/resolv.conf.d/*)
2. Reboot, or otherwise clear relevant state
3. sudo service systemd-resolved start
4. Note that Google's servers are listed in /run/systemd/resolve/resolv.conf
5. If systemd-resolved is enabled in /etc/nsswitch.conf (it isn't by default), observe that DNS lookups probably still work, and queries are being sent to one of Google's servers
Possible workaround/bugfix: ship a resolved.conf which clears the FallbackDNS parameter.
[Solution]
In ubuntu, we disable fallback DNS at build time, via build system configuration flags.
This issue has been discussed in the Debian BTS (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658). My interpretation of the Debian package maintainer's position is that a user concerned with the privacy implications shouldn't let systemd get into a state where it uses the fallback DNS servers (quoting Marco d'Itri: "Short summary: have a resolv.conf file or use DHCP"). I would argue that it's safest not to have fallback DNS servers configured at all by default.
[Regression Potential]
Missconfigured networks, that do not have a DNS server would previously magically work due to having Google DNS preconfigured regardless. With this change, such network configurations will fail to work, and one will have to properly fix network config to point at the right/existing name server. |
|
| 2017-09-07 18:04:21 |
Brian Murray |
systemd (Ubuntu Zesty): status |
In Progress |
Fix Committed |
|
| 2017-09-07 18:04:23 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-09-07 18:04:26 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2017-09-07 18:04:32 |
Brian Murray |
tags |
resolved |
resolved verification-needed verification-needed-zesty |
|
| 2017-09-15 04:47:10 |
Mathew Hodson |
systemd (Ubuntu Zesty): importance |
Undecided |
Low |
|
| 2017-10-02 13:58:07 |
Dimitri John Ledkov |
tags |
resolved verification-needed verification-needed-zesty |
resolved verification-done verification-done-zesty |
|
| 2017-10-05 17:31:08 |
Brian Murray |
tags |
resolved verification-done verification-done-zesty |
resolved verification-needed verification-needed-zesty |
|
| 2017-10-09 22:04:18 |
Anders Kaseorg |
tags |
resolved verification-needed verification-needed-zesty |
resolved verification-done verification-done-zesty |
|
| 2017-10-26 14:28:26 |
Launchpad Janitor |
systemd (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2017-10-26 14:28:45 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2020-05-22 19:01:22 |
Simon May |
bug |
|
|
added subscriber Simon May |
