Security
WiFi routers: from lockdown to lock-open
There has been a lot of concern recently that a new set of rules [PDF] from the US Federal Communications Commission (FCC) could lead to locking-down of home router devices. It appears that the worst-case scenario feared by many will not come to pass, but that has not stopped a large, high-profile group of developers from putting together a detailed counter-proposal to the FCC that could change the game entirely. Not content with fending off the lockdown threat, this group seeks to push the pendulum the other way by forcing router software to be open. The result, it is said, would be an Internet that performs better and which is much more secure.
Lockdown worries
The FCC's concern in this area relates to spectrum use, of course. WiFi routers are radio transmitters, so they must abide by the rules on how they can transmit; these include limits on allowable frequencies, maximum power, and more. To gain the required FCC certification, a vendor must demonstrate that a router cannot be operated in ways that violate those rules. Regulatory compliance was used as an excuse for years by WiFi chipset manufacturers that did not want to release drivers or hardware documentation. That excuse has broken down over the years, but, for a while recently, it seemed that the FCC was contemplating a required lockdown of router firmware as a way of ensuring compliance. By some readings of the proposed rules, the installation of distributions like OpenWrt on home routers would no longer be allowed.
Blocking third-party firmware installation would be a clear step backward for a number of reasons. Routers as shipped by vendors are often insecure from the outset and, given that almost none of them ever receive software updates, they all become more insecure over time. Independent router distributions, instead, can be updated to fix security problems; they can also enable all kinds of functionality that was not envisioned or enabled by the original vendor. And free-software distributions, in particular, have been the platform on which a great deal of networking development has been done. Improvements in IPv6 functionality, bufferbloat reduction, and more have been implemented by the free-software community on open routers.
In an attempt to head off a router lockdown, a group of influential developers has filed a letter to the FCC [PDF] calling for the proposed rules to not be implemented. Since the filing of the letter, the FCC has stated that it does not intend to block third-party firmware installation. But the letter goes far beyond simply asking the FCC not to lock down routers; indeed, the FCC has been asked to open them up radically.
New mandates requested
The letter asks the FCC to change its certification requirements for WiFi
routers and add a new set of mandates. The first of those is that the
source code for the router's "device driver and radio
firmware
" must be made freely available in a
"buildable
" form so that this code could be reviewed by
outsiders. There is no mention of requiring that this code be made
available under a free license, though the rest of the document makes it
clear that this is what the authors would prefer. It also does not require
that users be able to install modified versions of the software; this was,
your editor has been informed, an oversight during the drafting process.
Requiring the release of this code would clearly change the situation for router developers and users. It would bring about an end to binary-blob WiFi drivers, which would be a welcome change indeed. Even if a given driver were to be made available under an incompatible license, clean-room techniques could be used by others to develop a free driver. Opening up the radio software would shine a light into a dark corner of these systems, teaching us a lot about how they work, even if the software could not be replaced. A crucial piece of consumer-level infrastructure would become more open.
The advantages of this openness would be many, starting with the ability to audit the software for security issues and to fix them when they are found. Given the record of vendors in this area, improving the community's ability to provide security support can only be a good thing. The letter, though, asks the FCC to go further and to require the provision of security updates. In particular, any vulnerability with a CVE number that affects a router must be fixed by an update within 45 days of disclosure during the warranted lifetime of the router.
Finally, the FCC is asked to make it clear that lockdown of router devices is not required by its regulations:
The letter appears over a large number of well-known names, including Dave Täht and Vint Cerf (the principal authors) along with Jim Gettys, David P. Reed, Bruce Schneier, Daniel Geer, Kathleen Nichols, David Farber, Steven Bellovin, Linus Torvalds, Paul Vixie, and many more, including an obscure LWN editor. As a whole, it makes an impassioned case for free-software development as the best path toward high-quality and secure networking software.
Toward a better Internet
As a defense against further lockdown-oriented rules, it is likely to be effective, especially since the FCC is claiming that it does not intend to impose such rules. The mandates may find a more difficult reception, though. There seems to be no doubt that there would be fierce resistance from vendors and manufacturers; overcoming such resistance could be hard in the absence of wider public understanding of the nature of the problem.
To some, an open-routers mandate might actually look like a step backward for security, and for the security of the wireless spectrum in particular. But most users have no desire to run their routers out of compliance; there does not appear to be anything resembling a widespread interference problem caused by modified devices. On the other hand, routers with security vulnerabilities and even deliberate back doors are widespread indeed. Rules that address the latter problem will do far more to ensure that our routers behave themselves than anything aimed at locking down access to the radio hardware.
It would be surprising if this letter to the FCC were to convince them of that point on its own. But one has to start somewhere, and this is a strong start with a lot of big names behind it. With luck, it may just push us toward a world where our networks work better, our hardware is more secure, and routers serve the interests of their owners. That seems like an outcome worth going for.
Brief items
Security quotes of the week
The OpenSSL response? The code... that in 11 years had never been used... for a deprecated cipher... was *fixed* on Saturday, retaining the #ifdefs
Now eat your greens; your phone says you haven't been getting your five a day this week and if you keep it up we're going to have to dock you a point.
EFF: One Year Later, Hundreds of Tor Challenge Relays Still Active
The Electronic Frontier Foundation reports that 567 relays from the 2014 Tor Challenge are still up and running—"more than were established during the entire inaugural Tor Challenge back in 2011. To put that number in perspective, these nodes represent more than 8.5% of the roughly 6,500 public relays currently active on the entire Tor network, a system that supports more than 2-million directly connecting clients worldwide."
New vulnerabilities
389-ds-base: cipher downgrade
| Package(s): | 389-ds-base | CVE #(s): | CVE-2015-3230 | ||||||||
| Created: | October 9, 2015 | Updated: | October 16, 2015 | ||||||||
| Description: | From the Red Hat bugzilla entry:
It was reported that nsSSL3Ciphers preference is not enforced server side, this allows for a potential downgrade attack to take place. Upstream bug report: https://fedorahosted.org/389/ticket/48194 | ||||||||||
| Alerts: |
| ||||||||||
bugzilla: privilege escalation
| Package(s): | bugzilla | CVE #(s): | CVE-2015-4499 | ||||||||||||||||
| Created: | October 8, 2015 | Updated: | October 14, 2015 | ||||||||||||||||
| Description: | From the Arch Linux advisory:
Login names (usually an email address) longer than 127 characters are silently truncated in MySQL which could cause the domain name of the email address to be corrupted. An attacker could use this vulnerability to create an account with an email address different from the one originally requested. The login name could then be automatically added to groups based on the group's regular expression setting. This vulnerability has been demonstrated by truncation of an @mozilla.com.example.com address to an @mozilla.com address that resulted in an unauthorized account creation with the default privileges of the mozilla group. A remote attacker is able to obtain default privileges for an arbitrary domain name by placing that name in a substring of an address resulting in unauthorized account creation. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
chromium: multiple vulnerabilities
| Package(s): | chromium | CVE #(s): | CVE-2015-6755 CVE-2015-6756 CVE-2015-6757 CVE-2015-6758 CVE-2015-6759 CVE-2015-6760 CVE-2015-6761 CVE-2015-6762 CVE-2015-6763 | ||||||||||||||||||||||||||||||||||||||||
| Created: | October 14, 2015 | Updated: | October 26, 2015 | ||||||||||||||||||||||||||||||||||||||||
| Description: | From the Arch Linux advisory:
- CVE-2015-6755 (cross-origin bypass): Cross-origin bypass in Blink. Credit to Mariusz Mlynski. - CVE-2015-6756 (use-after-free): Use-after-free in PDFium. - CVE-2015-6757 (use-after-free): Use-after-free in ServiceWorker. Credit to Collin Payne. - CVE-2015-6758: Bad-cast in PDFium. Credit to Atte Kettunen of OUSPG. - CVE-2015-6759 (information leakage): Information leakage in LocalStorage. Credit to Muneaki Nishimura (nishimunea). - CVE-2015-6760 (improper error handling): Improper error handling in libANGLE. Credit to lastland.net. - CVE-2015-6761 (memory corruption): Memory corruption in FFMpeg. Credit to Aki Helin of OUSPG and anonymous. - CVE-2015-6762 (cross-origin resource sharing bypass): CORS bypass via CSS fonts. Credit to Muneaki Nishimura (nishimunea). - CVE-2015-6763: Various fixes from internal audits, fuzzing and other initiatives. | ||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||
git: multiple vulnerabilities
| Package(s): | git | CVE #(s): | CVE-2015-7545 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | October 14, 2015 | Updated: | May 3, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Mageia advisory:
The git package has been updated to version 2.3.10, fixing a few security issues. These include buffer and integer overflow issues with long file path names and large files, as well as a remote code execution flaw with some protocols like git-remote-ext and specially crafted URLs. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
isodumper: command execution
| Package(s): | isodumper | CVE #(s): | |||||
| Created: | October 12, 2015 | Updated: | October 14, 2015 | ||||
| Description: | From the Mageia advisory:
The volume label text could be injected and executed as a shell command in raw_format.py from isodumper. | ||||||
| Alerts: |
| ||||||
kernel: denial of service
| Package(s): | kernel | CVE #(s): | CVE-2015-5257 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | October 9, 2015 | Updated: | November 11, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Fedora advisory:
A vulnerability in WhiteHEAT USB Serial Driver in "whiteheat_attach" function in drivers/usb/serial/whiteheat.c was found. In the driver, the “COMMAND_PORT” variable is hard coded and is set to “4” (5th element). The driver assumes that the number of ports will always be 5 and takes the port number 5 as the command port. But using a specially made USB device in which the number of ports is set to a number less than 5 (e.g. 3), it triggers kernel NULL pointer dereference causing the system to freeze. Disclosure post (including crash report logs): http://seclists.org/oss-sec/2015/q3/629 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
kernel: denial of service
| Package(s): | kernel | CVE #(s): | CVE-2015-5283 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | October 13, 2015 | Updated: | December 6, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
Marcelo Ricardo Leitner discovered that creating multiple SCTP sockets at the same time could cause a denial of service (crash) if the sctp module had not previously been loaded. This issue only affects jessie. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
kernel-linus: multiple vulnerabilities
| Package(s): | kernel | CVE #(s): | CVE-2015-4176 CVE-2015-4177 CVE-2015-4178 | ||||||||
| Created: | October 12, 2015 | Updated: | October 14, 2015 | ||||||||
| Description: | From the Mageia advisory:
A flaw was found in the Linux kernel where the deletion of a file or directory could trigger an unmount and reveal data under a mount point. This flaw was inadvertently introduced with the new feature of being able to lazily unmount a mount tree when using file system user namespaces. (CVE-2015-4176) A flaw was discovered in the kernel's collect_mounts function. If the kernel audit subsystem called collect_mounts to audit an unmounted path, it could panic the system. With this flaw, an unprivileged user could call umount (MNT_DETACH) to launch a denial-of-service attack. (CVE-2015-4177) A flaw was found in the Linux kernel which is related to the user namespace lazily unmounting file systems. The fs_pin struct has two members (m_list and s_list) which are usually initialized on use in the pin_insert_group function. However, these members might go unmodified; in this case, the system panics when it attempts to destroy or free them. This flaw could be used to launch a denial-of-service attack. (CVE-2015-4178) | ||||||||||
| Alerts: |
| ||||||||||
opensmtpd: multiple vulnerabilities
| Package(s): | opensmtpd | CVE #(s): | CVE-2015-7687 | ||||||||
| Created: | October 9, 2015 | Updated: | October 20, 2015 | ||||||||
| Description: | From the Arch Linux advisory:
- an oversight in the portable version of fgetln() that allows attackers to read and write out-of-bounds memory - multiple denial-of-service vulnerabilities that allow local users to kill or hang OpenSMTPD - a stack-based buffer overflow that allows local users to crash OpenSMTPD, or execute arbitrary code as the non-chrooted _smtpd user - a hardlink attack (or race-conditioned symlink attack) that allows local users to unset the chflags() of arbitrary files - a hardlink attack that allows local users to read the first line of arbitrary files (for example, root's hash from /etc/master.passwd) - a denial-of-service vulnerability that allows remote attackers to fill OpenSMTPD's queue or mailbox hard-disk partition - an out-of-bounds memory read that allows remote attackers to crash OpenSMTPD, or leak information and defeat the ASLR protection - a use-after-free vulnerability that allows remote attackers to crash OpenSMTPD, or execute arbitrary code as the non-chrooted _smtpd user - fix an mda buffer truncation bug which allows a user to create forward files that pass session checks but fail delivery later down the chain, within the user mda - fix remote buffer overflow in unprivileged pony process - reworked offline enqueue to better protect against hardlink attacks A remote attacker is able to execute arbitrary code, crash the process to perform a denial of service attack, read arbitrary memory to disclose information and defeat ASLR or have other unspecified impact via various vectors. | ||||||||||
| Alerts: |
| ||||||||||
OpenStack director: authentication bypass
| Package(s): | OpenStack director | CVE #(s): | CVE-2015-5271 | ||||
| Created: | October 9, 2015 | Updated: | October 14, 2015 | ||||
| Description: | From the Red Hat advisory:
A flaw was discovered in the pipeline ordering of OpenStack Object Storage's staticweb middleware in the swiftproxy configuration generated from the openstack-tripleo-heat-templates package (OpenStack director). The staticweb middleware was incorrectly configured before the Identity Service, and under some conditions an attacker could use this flaw to gain unauthenticated access to private data. (CVE-2015-5271) | ||||||
| Alerts: |
| ||||||
php: multiple vulnerabilities
| Package(s): | php php-timezonedb | CVE #(s): | CVE-2015-7803 CVE-2015-7804 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | October 12, 2015 | Updated: | October 28, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Mageia advisory:
The php package has been updated to version 5.6.14, which fixes two security issues in phar and several other bugs. See the upstream ChangeLog for more details. From the CVE assignment:
> Null pointer dereference in phar_get_fp_offset() Use CVE-2015-7803.
> Uninitialized pointer in phar_make_dirstream when zip entry filename is "/" Use CVE-2015-7804. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
qemu: denial of service
| Package(s): | qemu | CVE #(s): | CVE-2015-7295 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | October 14, 2015 | Updated: | December 3, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Mageia advisory:
A flaw has been discovered in the QEMU emulator built with Virtual Network Device(virtio-net) support. If the guest's virtio-net driver did not support big or mergeable receive buffers, an issue could occur while receiving large packets over the tuntap/ macvtap interfaces. An attacker on the local network could use this flaw to disable the guest's networking; the user could send a large number of jumbo frames to the guest, which could exhaust all receive buffers, and lead to a denial of service. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>