LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityFedora and secure release upgradesAs Fedora 18 nears its final release, some project members are concerned that churn in the update tools has placed users in a risky position by eliminating secure paths to update an existing installation from Fedora 17. Although it looks like workarounds will be available, the resulting choice will pit convenience against security, which is rarely a trade-off that ends up in security's favor. But as the whole debate nicely illustrates, when it comes to verifying the authenticity of software acquired over the network, no matter how many steps are involved, eventually the chain of trust must start somewhere — because users always make a leap of trust when first clicking on the download option. The root of the issue is FedUp, the brand-new updater currently being developed for deployment with F18, which does not check the cryptographic signatures of the RPM packages it downloads over the network (although FedUp also downloads initramfs and vmlinuz files at the start of an upgrade; it does verify the integrity of these by checking their SHA256 checksums). A bug highlighting that deficiency was filed in November, noting that fetching and installing unverified binaries over the network leaves the system vulnerable to man-in-the-middle attacks and to trojaned packages on compromised mirrors. Fedora's RPM packages are signed, and various package installer tools do verify the signatures; it is only the FedUp release-upgrading tool that does not check the signatures before installing them. The Fedora Engineering Steering Committee (FESCo) discussed the subject in its December 5 meeting and decided that the absence of network verification would not block the release of F18. Rahul Sundaram raised the importance of the issue on the fedora-devel list a week and a half later, arguing that the lack of a secure method to update from F17 to F18 was irresponsible. Part of Sundaram's initial concern was that the still-unfinished FedUp did not yet support updating from an optical disc, which would provide some measure of protection against attack because Fedora's downloadable ISO images are provided with checksums. That concern turned out to be partly unfounded; as Red Hat's Tim Flink explained in a different thread, FedUp does support extracting packages from optical media — it just does not support booting from an optical disc to upgrade an existing installation, or pulling packages from an ISO file. Upgrades and release blockersBut the optical disc upgrade option is not the default behavior for FedUp; the user must know to employ it with the --device switch. FedUp's default is still to fetch packages from a remote repository. At the moment, FedUp is also fetching these pre-release packages over an unencrypted HTTP connection, although that could change when the final F18 is released. One can always argue that users in the know will seek out the secure means to update their machines, but it is far less risky to make the default behavior secure. After all, "users in the know" are not the ones most in need of protection. On that point, Sundaram noted in his original email that FedUp's lack of package verification is not a regression, since the update tool that it replaces, PreUpgrade, did not check package signatures either. Neither does Anaconda, the Fedora installer. The only release-upgrade path that ever has verified remote repository package signatures was that of upgrading via the yum package manager, which is an unsupported option that non-advanced users are steered away from — and with good reason. Yum is a lower-level package installation utility; it can be used to manually upgrade the entire system to a new release, but the procedure is not recommended because a release upgrade involves more than simple package installation. Dedicated upgrade tools like PreUpgrade and FedUp are designed to handle large or complicated system changes between releases, such as the merging of /bin and other directories into the /usr hierarchy. Some of these changes require a reboot, which PreUpgrade and FedUp are built to manage, but yum is not. Sundaram opened a FESCo ticket asking FESCo to classify the FedUp signature-verification issue as a blocker — although he later closed it after determining that the local-media option does offer a secure upgrade path for those that seek it out. But the issue is also tangled up with the question of whether or not FedUp is ready for release on other grounds. It still lacks a GUI front-end, logging, and progress indication. The GUI in particular is a limitation that some see as critical in its own right (Sundaram called it "a severe regression"). The fedora of trustFESCo decided to defer the FedUp GUI feature until F19, and the question of providing any secure way to upgrade an F17 machine to F18 appears, for the moment, to be settled. The deeper question of making such a secure upgrade the default, however, remains unanswered. Fedora's distribution upgrade tools have never baked signature verification into the upgrade process, and the project knows it. The discussion dates all the way back to the infamous bug 998, first opened in 1999 and filled with mysterious references to forgotten technologies like floppy disks (hint for younger readers: imagine a really thin SSD). But securely checking package signatures requires a secure method for the user to acquire the right public key (with which to check said signatures) in the first place. Even yum, which was raised during the FedUp discussion as the secure upgrade option, needs the user to manually find and import the correct GPG key for the new release. That is a weak link even in the manual case, as Fedora QA team member Adam Williamson observed:
If you're doing things Properly, you should somehow verify you're
importing the correct key and not just blindly typing what a wiki page
tells you to, but of course what most people do is blindly type what
the wiki page tells them to...
Finding a way for the Fedora N release upgrade tool to securely fetch and install the correct key for release N+1 automatically is a tricky problem indeed. For example, Will Woods proposed a plan to add GPG signatures for the initramfs and vmlinuz files FedUp fetches at the beginning of the upgrade. As mentioned above, currently only a SHA256 checksum is used to verify the integrity of these files — courtesy of checksums found in the repository's .treeinfo file. Woods proposed adding GPG signatures to the repository at .treeinfo.signed, but noted that there still needs to be a way to get the F18 key onto F17 systems, and some way for the user to decide if the F18 key is trustworthy. If we consider the contents of /etc/pki/rpm-gpg trusted, the F18 key(s) could be packaged for F17. The package would be signed with the F17 key, which sort of establishes a chain of trust from F17 to F18. This won't work for completely offline systems, though. But if the F18 public key *itself* was signed with the F17 key, the F18 key could be included on the install media, and tools could use that to get the F18 key into the F17 keyring. Another option is to sign .treeinfo with both the F17 and F18 keys, but this would require using a detached signature and tweaking things to accept the file if *any* signature can be verified. And so on. There's a lot of options. This is a distro-wide policy decision about establishing trust between versions of Fedora, so I'm guessing it's going to require a bunch of meetings and discussions and voting. Establishing a chain of trust can be a bit of a chicken-and-egg problem: eventually one has to place one's trust in something on which the subsequent links build. Till Maas suggested to Woods that the F18 key could be securely fetched from the Fedora project from a well-known location over HTTPS. Of course, that relies on the security of HTTPS and the DNS system, which relies on the security of the certificate authorities, and so on. For most mortals, however, some security — however limited — is still better than no security, which is what FedUp's default usage provides now. As recently as the end of November, users were still writing to the list confused about how best to upgrade their machines. There are clearly many more discussions ahead; even if Fedora establishes a workable plan for its main releases, also problematic is how downstream distributions (including Fedora "spins") and customized ISOs are handled. Whatever solution develops, one thing is for certain: it will not arrive until the F19 release cycle at the earliest.
Brief items Security quotes of the week
In short, given everything known today about the possible potential of
quantum computers, it is already possible to do all the sorts of things
we do with cryptography today in a way that is secure against future
adversaries with quantum computers. Unfortunately, "Quantum Computing
Not Really A Big Deal For Security" doesn't make for a very good
magazine article.
-- Matt Mackall
Overall, we've been doing a pretty good job at teaching US-based law
enforcement about Tor. At the end of the conference, one of the FBI agents
took me aside and asked "surely you have *some* sort of way of tracking
your users?" When I pointed at various of his FBI colleagues in the room
who had told me they use Tor every day for their work, and asked if he'd be
comfortable if we had a way of tracing *them*, I think he got it.
-- Roger Dingledine
The whole idea that we're now allowing countries with horrid human rights records, and with little to no experience in supporting innovation-enabling technologies, to control direction of these discussions suggests that the entire ITU process is broken beyond belief.
-- Mike Masnick
Governments around the world continue to eye the Internet and the open communications it fosters to be primarily a threat, with its technology ripe for surveillance, and its users to be controlled, censored, flogged, imprisoned, and even worse. The ITU's newfound fetish for DPI -- Deep Packet Inspection -- makes the wet dreams of tyrants and others in this sphere all the more explicit.
-- Lauren Weinstein
These dynamics are continuing going forward. The risks of Internet censorship, fragmentation, and other severe damage to the Internet we've worked so hard to build will continue to be exacerbated, despite our holding the ITU pretty much at bay this time around.
A hash-based DoS attack on BtrfsPascal Junod has disclosed a pair of denial-of-service attacks against the Btrfs filesystem based on hash collisions. "I have created several files with random names in a directory (around 500). The time required to remove them is negligible. Then, I have created the same number of files, but giving them only 55 different crc32c values. The time required to remove them is so large that I was not able to figure it out and killed the process after 220 minutes (!)." This is a local attack only, but administrators of Btrfs-using sites with untrusted users may want to pay attention.
World-writable memory on Samsung Android phonesHere's a report on the xda-developers site stating that Samsung Android phones have an interesting feature added to the kernel: a /dev/exynos-mem device, world-writable, that gives access to all physical memory on the handset. "The good news is we can easily obtain root on these devices and the bad is there is no control over it." Owners of such phones might want to be especially careful about which software they install for a little while.
Suricata 1.4 releasedVersion 1.4 of the Suricata intrusion detection/prevention system is available. "The biggest new features of this release are the Unix Socket support, IP Reputation support and the addition of the Luajit keyword. Each of these new features are still in active development, and should be approached with some care." There's a lot of other new features and a number of performance improvements as well.
New vulnerabilities apport: AppArmor policy is too lenient
apt: information disclosure
aptdaemon: man-in-the-middle attack
drupal6-ctools: cross-site scripting
kernel: denial of service
librdmacm: bogus address resolution
mate-settings-daemon: insecure timezones
nova: information disclosure
pki-core: cross-site scripting
qt: information disclosure
squashfs-tools: two code execution flaws
tomcat: multiple vulnerabilities
unity-firefox-extension: information disclosure
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||