(Update recommendations, add one for the nsswitch.conf issue) |
|||
| Line 30: | Line 30: | ||
* CPU architecture, and system type (HINFO records) | * CPU architecture, and system type (HINFO records) | ||
Recommendation: Don't publish anything unless specifically approved by the user. | '''Recommendation''': Don't publish anything unless specifically approved by the user. | ||
=== Privacy: SSH service === | === Privacy: SSH service === | ||
| Line 36: | Line 36: | ||
Installed by avahi package on Fedora. | Installed by avahi package on Fedora. | ||
Recommendation: Only advertise over Avahi when service is enabled. When service is enabled allow through firewall. Disable service by default. | '''Recommendation''': Only advertise over Avahi when service is enabled. When service is enabled allow through firewall. Disable service by default. | ||
=== Privacy: libvirt service === | === Privacy: libvirt service === | ||
| Line 42: | Line 42: | ||
virt-manager can connect to it and show you the VM available on the remote system: http://virt-manager.org/page/LibvirtDiscovery | virt-manager can connect to it and show you the VM available on the remote system: http://virt-manager.org/page/LibvirtDiscovery | ||
Recommendation: Disable remote VM access and discovery by default | '''Recommendation''': Disable remote VM access and discovery by default | ||
=== Privacy: udisks service === | === Privacy: udisks service === | ||
| Line 52: | Line 52: | ||
From the man page it's just not clear what "browse-domains" actually does, but based on http://0pointer.de/blog/projects/avahi-wide-area.html and some experiments this seems to add more hosts that can be offered automatically by a GUI. The default <code>browse-domains=0pointer.de, zeroconf.org</code> should probably be disabled - it's very unlikely these entries will be useful, and it just adds more ways to attack the code (in particular, by a MITM that is not connected to the local network). | From the man page it's just not clear what "browse-domains" actually does, but based on http://0pointer.de/blog/projects/avahi-wide-area.html and some experiments this seems to add more hosts that can be offered automatically by a GUI. The default <code>browse-domains=0pointer.de, zeroconf.org</code> should probably be disabled - it's very unlikely these entries will be useful, and it just adds more ways to attack the code (in particular, by a MITM that is not connected to the local network). | ||
Recommendation: Remove browse-domains configured by default. | '''Recommendation''': Remove browse-domains configured by default. | ||
=== Possible Security: nsswitch.conf integration === | === Possible Security: nsswitch.conf integration === | ||
| Line 63: | Line 63: | ||
In addition, if DHCP is used on the network in question (usually the case), then the attacker can simply push another DNS server to the client machine and attack using that vector instead. | In addition, if DHCP is used on the network in question (usually the case), then the attacker can simply push another DNS server to the client machine and attack using that vector instead. | ||
'''Recommendation''': Since this only affects <code>.local</code> domains, which are explicitly provided by zeroconf, this is not a security issue. If specific networks make the risky move of reappropriating <code>.local</code> for other purposes, they can deal with the consequences as appropriate to their situation. | |||
=== Possible Security: High range port === | === Possible Security: High range port === | ||
mDNS is on port 5353 which requires no permissions to bind to. So, any malicious user on the network can advertise they are the printer and intercept any printing and the forward it to the real printer. Doesn't IPP allow discovery? Its on port 631 which means you have a little more trust. Sure, you can still have a mailicious user running his own OS and having root access. But at least you moved the attack from anyone can do it to they have to be in control of their system. -- SteveGrubb | mDNS is on port 5353 which requires no permissions to bind to. So, any malicious user on the network can advertise they are the printer and intercept any printing and the forward it to the real printer. Doesn't IPP allow discovery? Its on port 631 which means you have a little more trust. Sure, you can still have a mailicious user running his own OS and having root access. But at least you moved the attack from anyone can do it to they have to be in control of their system. -- SteveGrubb | ||
Revision as of 16:28, 15 March 2012
Avahi by Default on the Desktop
Note: this is not a place to gather opinions, but please do contribute with actual facts or research.
Use case
- User is in at home or in a print shop (like Kinkos) and wants to print to a printer for the first time.
- Opens "Printers" in System Settings to add a new printer.
- The printer is advertised using MDNS and user sees it displayed, clicks on it to install.
Currently this does not work in Fedora. Avahi is blocked by our firewall by default. Obviously many printers don't use MDNS. This is about MDNS and our implementation: Avahi.
Note that a firewall is orthogonal this use case, even if security "zones" were implemented. We want printers to be discoverable from the "Printers" control panel even on possibly "hostile" networks. The user should not have to type their root or login password for a policy kit prompt to see printers on the network. Neither should they have to disable their firewall or otherwise diddle it.
Goal
If the current implementation of automatic printer discovery using MDNS is not secure, it should be possible to make it secure and make the above use case work. If it is absolutely impossible to make it secure, then we want to discover exactly why.
Privacy and Security Issues
Running Avahi by default, in its current state, causes security and privacy issues.
We would like to enumerate those issues here, so that we can sufficiently neuter Avahi so that it can be run by default without a firewall and not pose any threat to the system. The end goal is to facilitate the above use cases, and others like it.
Privacy: PTR and HINFO records
By default Avahi publishes the following information.
- Host name
- CPU architecture, and system type (HINFO records)
Recommendation: Don't publish anything unless specifically approved by the user.
Privacy: SSH service
Installed by avahi package on Fedora.
Recommendation: Only advertise over Avahi when service is enabled. When service is enabled allow through firewall. Disable service by default.
Privacy: libvirt service
virt-manager can connect to it and show you the VM available on the remote system: http://virt-manager.org/page/LibvirtDiscovery
Recommendation: Disable remote VM access and discovery by default
Privacy: udisks service
Already removed in udisks2
Unnecessary attack vector: browse-domains
From the man page it's just not clear what "browse-domains" actually does, but based on http://0pointer.de/blog/projects/avahi-wide-area.html and some experiments this seems to add more hosts that can be offered automatically by a GUI. The default browse-domains=0pointer.de, zeroconf.org should probably be disabled - it's very unlikely these entries will be useful, and it just adds more ways to attack the code (in particular, by a MITM that is not connected to the local network).
Recommendation: Remove browse-domains configured by default.
Possible Security: nsswitch.conf integration
Unclear if this is a security problem.
With the nsswitch.conf integration, MDNS can affect the resolv lookups on the machine. This is limited to .local domains, and domains explicitly configured in avahi for MDNS.
In theory, changing the results of resolver lookups can be a limited security threat, when running on a hostile network. However this is limited to .local by default.
In addition, if DHCP is used on the network in question (usually the case), then the attacker can simply push another DNS server to the client machine and attack using that vector instead.
Recommendation: Since this only affects .local domains, which are explicitly provided by zeroconf, this is not a security issue. If specific networks make the risky move of reappropriating .local for other purposes, they can deal with the consequences as appropriate to their situation.
Possible Security: High range port
mDNS is on port 5353 which requires no permissions to bind to. So, any malicious user on the network can advertise they are the printer and intercept any printing and the forward it to the real printer. Doesn't IPP allow discovery? Its on port 631 which means you have a little more trust. Sure, you can still have a mailicious user running his own OS and having root access. But at least you moved the attack from anyone can do it to they have to be in control of their system. -- SteveGrubb