There should also be an add-apt-repository statement for each repo documentation.
E. g. for https://launchpad.net/~docker-maint/+archive/ubuntu/testing there should be an _additional_ line sudo add-apt-repository ppa:docker-maint/testing which the user can can copy-paste. Reason: - This is ways easier than manually dealing with keys and having to use multiple commands (which btw. also is not documented per repo) - It's ways more secure and error-proof for average users - The Link "(Read about installing)" just contains a generic repo but not the one the users wants to install. Plus, the correct string is not easy to find for beginners. - Plus, choosing the distribution version is obsolete. Personally, I always use add-apt-repository but just because I know how and why. I think adding this line should be super easy, as the ppa name is already shown on that page. ** Description changed: - Oftenly, a http URL is used in documentation to download apt keys, e.g. - "wget -q http://download.opensuse.org/repositories/home:/some- + HTTP URLs are frequently used in documentation to download apt keys, + e.g. "wget -q http://download.opensuse.org/repositories/home:/some- project:/release/xUbuntu_12.04/Release.key -O- | sudo apt-key add -" Basically, this means that neither integrity nor origin of the key is checked. Users will usually copy&paste the code and never check integrity and origin of the keys. This allows man-in-the-middle attacks. For example, the user's router could be compromised, and this is a problem which becomes more and more important. As a result, an attacker could offer a compromised apt-key as well as a compromised package which is signed with the corresponding key. The package will be installed with root permissions and allows anything the attacker wants, even compromising firmwares of the user's system. The latter can never be detected or removed with tools we know of today. I suggest several steps: - Suggest Maintainers to use https instead of http for the URL of the apt-key-file (the package itself can still have a https-URL). Make a clear statement at a frequented place on the ubuntu website. - Inform build services that they should offer https downloads for apt-key-files. E. g. I can't find an https alternative URL for the opensuse build service. - Update documentation, inform the corresponding maintainers directly - Eventually host trusted keys mentioned in the documentation via https on launchpad. This would even work if maintainers don't cooperate or maintain. It could be done for all the URLs AS LONG AS the downloaded keys can be TRUSTED (double check via email address etc.). - Eventually set a deadline at some point, when http-URLs for apt-keys are no more tolerated in documentation - Encourage the use of DNSSEC in the future - Directly implement the download of apt-keys in a secure manner in apt (with the URL as a parameter, avoiding downgrade attacks and insecure https server implementation, offering DNSSEC) - Check if there are similar ways users could get untrusted apt keys. Keep in mind that this is NOT a security vulnerability in a program. But I think it's as bad as if apt was not checking the integrity of packages (which would be VERY bad). Feel free to make this bug public if you see no reason for keeping it secret. ** Description changed: HTTP URLs are frequently used in documentation to download apt keys, e.g. "wget -q http://download.opensuse.org/repositories/home:/some- project:/release/xUbuntu_12.04/Release.key -O- | sudo apt-key add -" Basically, this means that neither integrity nor origin of the key is checked. Users will usually copy&paste the code and never check integrity and origin of the keys. This allows man-in-the-middle attacks. For example, the user's router could be compromised, and this is a problem which becomes more and more important. As a result, an attacker could offer a compromised apt-key as well as a compromised package which is signed with the corresponding key. The package will be installed with root permissions and allows anything the attacker wants, even compromising firmwares of the user's system. The latter can never be detected or removed with tools we know of today. I suggest several steps: - - Suggest Maintainers to use https instead of http for the URL of the apt-key-file (the package itself can still have a https-URL). Make a clear statement at a frequented place on the ubuntu website. + - Suggest Maintainers to use https instead of http for the URL of the apt-key-file (the package itself can still have a http-URL). Make a clear statement at a frequented place on the ubuntu website. - Inform build services that they should offer https downloads for apt-key-files. E. g. I can't find an https alternative URL for the opensuse build service. - Update documentation, inform the corresponding maintainers directly - Eventually host trusted keys mentioned in the documentation via https on launchpad. This would even work if maintainers don't cooperate or maintain. It could be done for all the URLs AS LONG AS the downloaded keys can be TRUSTED (double check via email address etc.). - Eventually set a deadline at some point, when http-URLs for apt-keys are no more tolerated in documentation - Encourage the use of DNSSEC in the future - Directly implement the download of apt-keys in a secure manner in apt (with the URL as a parameter, avoiding downgrade attacks and insecure https server implementation, offering DNSSEC) - Check if there are similar ways users could get untrusted apt keys. Keep in mind that this is NOT a security vulnerability in a program. But I think it's as bad as if apt was not checking the integrity of packages (which would be VERY bad). Feel free to make this bug public if you see no reason for keeping it secret. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1460242 Title: documentation: apt-keys via http allows man-in-the-middle-attacks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/add-apt-key/+bug/1460242/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
