Security
Fedora and secure release upgrades
As 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 blockers
But 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 trust
FESCo 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:
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
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 Btrfs
Pascal 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 phones
Here'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 released
Version 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
| Package(s): | apport | CVE #(s): | |||||
| Created: | December 18, 2012 | Updated: | December 19, 2012 | ||||
| Description: | From the Ubuntu advisory:
Dan Rosenberg discovered that an application running under an AppArmor profile that allowed unconfined execution of apport-bug could escape confinement by calling apport-bug with a crafted environment. While not a vulnerability in apport itself, this update mitigates the issue by sanitizing certain variables in the apport-bug shell script. | ||||||
| Alerts: |
| ||||||
apt: information disclosure
| Package(s): | apt | CVE #(s): | CVE-2012-0961 | ||||
| Created: | December 19, 2012 | Updated: | December 19, 2012 | ||||
| Description: | From the Ubuntu advisory: It was discovered that APT set inappropriate permissions on the term.log file. A local attacker could use this flaw to possibly obtain sensitive information. | ||||||
| Alerts: |
| ||||||
aptdaemon: man-in-the-middle attack
| Package(s): | aptdaemon | CVE #(s): | CVE-2012-0962 | ||||
| Created: | December 17, 2012 | Updated: | December 19, 2012 | ||||
| Description: | From the Ubuntu advisory:
It was discovered that Aptdaemon incorrectly validated PPA GPG keys when importing from a keyserver. If a remote attacker were able to perform a man-in-the-middle attack, this flaw could be exploited to install altered package repository GPG keys. | ||||||
| Alerts: |
| ||||||
drupal6-ctools: cross-site scripting
| Package(s): | drupal6-ctools | CVE #(s): | CVE-2012-5559 | ||||||||
| Created: | December 19, 2012 | Updated: | December 19, 2012 | ||||||||
| Description: | From the Red Hat bugzilla entry: The Chaos tool suite is primarily a set of APIs and tools to improve the developer experience. The page manager node view task does not sufficiently escape node titles when setting the page title, allowing XSS. This vulnerability is partially [mitigated] by the node task being disabled by default and limited to users that have the ability to submit or edit nodes. | ||||||||||
| Alerts: |
| ||||||||||
kernel: denial of service
| Package(s): | kernel | CVE #(s): | CVE-2012-5517 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 19, 2012 | Updated: | December 20, 2012 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory:
A NULL pointer dereference flaw was found in the way a new node's hot added memory was propagated to other nodes' zonelists. By utilizing this newly added memory from one of the remaining nodes, a local, unprivileged user could use this flaw to cause a denial of service. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
librdmacm: bogus address resolution
| Package(s): | librdmacm | CVE #(s): | CVE-2012-4516 | ||||||||||||||||
| Created: | December 17, 2012 | Updated: | November 21, 2013 | ||||||||||||||||
| Description: | From the Red Hat bugzilla:
A security flaw was found in the way librdmacm, a userspace RDMA Communication Managment API allowing to specify connections using TCP/IP addresses even though it opens RDMA specific connections, performed binding to the underlying ib_acm service (librdmacm used default port value of 6125 to bind to ib_acm service). An attacker able to run a rogue ib_acm service could use this flaw to make librdmacm applications to use potentially bogus address resolution information. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
mate-settings-daemon: insecure timezones
| Package(s): | mate-settings-daemon | CVE #(s): | CVE-2012-5560 | ||||||||||||
| Created: | December 17, 2012 | Updated: | March 4, 2013 | ||||||||||||
| Description: | From the Red Hat bugzilla:
mate-settings-daemon's datetime mechanism provides a D-Bus method to set the timezone, which is guarded by polkit's action org.mate.settingsdaemon.datetimemechanism.settimezone; this has the default policy "auth_self_keep", which allows any local user to perform the operation with only knowing their own password. This seems not to be currently exposed in the mate UI, but it is available through manual D-Bus calls, e.g. > dbus-send --system --print-reply --type=method_call --dest=org.mate.SettingsDaemon.DateTimeMechanism / org.mate.SettingsDaemon.DateTimeMechanism.SetTimezone string:/usr/share/zoneinfo/Cuba Because the time zone setting is a global resource, it should be restricted to system administrators (== root or users in the "wheel" group), by having a policy auth_admin_*. That's also what the other timezone setting mechanisms (in systemd and control-center) do. | ||||||||||||||
| Alerts: |
| ||||||||||||||
nova: information disclosure
| Package(s): | nova | CVE #(s): | CVE-2012-5625 | ||||||||
| Created: | December 19, 2012 | Updated: | December 19, 2012 | ||||||||
| Description: | From the Ubuntu advisory: Eric Windisch discovered that Nova did not properly clear LVM-backed images before they were reallocated which could potentially lead to an information leak. This issue only affected setups using libvirt LVM-backed instances. | ||||||||||
| Alerts: |
| ||||||||||
pki-core: cross-site scripting
| Package(s): | pki-core | CVE #(s): | CVE-2012-4543 | ||||||||||||||||||||||||
| Created: | December 17, 2012 | Updated: | March 11, 2013 | ||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
Multiple cross-site scripting (XSS) flaws were found in the way: 1) 'displayCRL' script of Certificate System sanitized content of 'pageStart' and 'pageSize' variables provided in the query string, 2) 'profileProcess' script of Certificate System sanitized content of 'nonce' variable provided in the query string. A remote attacker could provide a specially-crafted web page that, when visited by an unsuspecting Certificate System user would lead to arbitrary HTML or web script execution in the context of Certificate System user session. | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
qt: information disclosure
| Package(s): | qt | CVE #(s): | CVE-2012-5624 | ||||||||||||||||||||||||||||
| Created: | December 19, 2012 | Updated: | January 23, 2013 | ||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla entry: An information disclosure flaw was found in the way XMLHttpRequest object implementation in Qt, a software toolkit for developing applications, performed management of certain HTTP responses. Previous implementation allowed redirection from HTTP protocol to file schemas. Also the redirection handling was performed automatically by QML application and could not be disabled. A remote attacker could use this flaw to cause QML application in an unauthorized way to read local file content by causing the HTTP response for the application to be a redirect to a file: URL (file scheme). | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
squashfs-tools: two code execution flaws
| Package(s): | squashfs-tools | CVE #(s): | CVE-2012-4024 CVE-2012-4025 | ||||||||||||||||||||
| Created: | December 19, 2012 | Updated: | December 13, 2016 | ||||||||||||||||||||
| Description: | From the Red Hat bugzilla entries [1, 2]: CVE-2012-4024: Stack-based buffer overflow in the get_component function in unsquashfs.c in unsquashfs in Squashfs 4.2 and earlier allows remote attackers to execute arbitrary code via a crafted list file (aka a crafted file for the -ef option). NOTE: probably in most cases, the list file is a trusted file constructed by the program's user; however, there are some realistic situations in which a list file would be obtained from an untrusted remote source. CVE-2012-4025: Integer overflow in the queue_init function in unsquashfs.c in unsquashfs in Squashfs 4.2 and earlier allows remote attackers to execute arbitrary code via a crafted block_log field in the superblock of a .sqsh file, leading to a heap-based buffer overflow. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
tomcat: multiple vulnerabilities
| Package(s): | tomcat | CVE #(s): | CVE-2012-4534 CVE-2012-4431 CVE-2012-3546 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 19, 2012 | Updated: | January 24, 2013 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the CVE entries:
org/apache/tomcat/util/net/NioEndpoint.java in Apache Tomcat 6.x before 6.0.36 and 7.x before 7.0.28, when the NIO connector is used in conjunction with sendfile and HTTPS, allows remote attackers to cause a denial of service (infinite loop) by terminating the connection during the reading of a response. (CVE-2012-4534) org/apache/catalina/filters/CsrfPreventionFilter.java in Apache Tomcat 6.x before 6.0.36 and 7.x before 7.0.32 allows remote attackers to bypass the cross-site request forgery (CSRF) protection mechanism via a request that lacks a session identifier. (CVE-2012-4431) org/apache/catalina/realm/RealmBase.java in Apache Tomcat 6.x before 6.0.36 and 7.x before 7.0.30, when FORM authentication is used, allows remote attackers to bypass security-constraint checks by leveraging a previous setUserPrincipal call and then placing /j_security_check at the end of a URI. (CVE-2012-3546) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
unity-firefox-extension: information disclosure
| Package(s): | unity-firefox-extension | CVE #(s): | CVE-2012-0958 | ||||
| Created: | December 19, 2012 | Updated: | December 19, 2012 | ||||
| Description: | From the Ubuntu advisory: It was discovered that unity-firefox-extension bypassed the same origin policy checks in certain circumstances. If a user were tricked into opening a malicious page, an attacker could exploit this to steal confidential data or perform other security-sensitive operations. | ||||||
| Alerts: |
| ||||||
Page editor: Jake Edge
Next page:
Kernel development>>