Re: Security: auto-loading protocol modules
On Fri, 2010-11-19 at 03:14 +, Ben Hutchings wrote: The AX.25 protocol modules (ax25, netrom, rose) have not had a great security record recently, and are not widely used. What do you think of moving the module aliases into ax25-tools, so systems without that package are not vulnerable to security flaws in the kernel modules? Ben. This seems like a good idea to me. +1 -Kamal signature.asc Description: This is a digitally signed message part
Re: Security: auto-loading protocol modules
On 2010-11-18, Ben Hutchings b...@decadent.org.uk wrote: --=-ukGC3PFRUIR65dSYwt1Z Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Unlike device or filesystem modules, most protocol modules may be auto- loaded on behalf of local users without any special capabilities. This means that security vulnerabilities in such protocol modules may be exploitable by local users even on a system where there is no need for the protocol. What about CAN? It also had one or two privilege escalations in the past and seems to be used only in special purpose embedded setups. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrniei0sk.2er@inutil.org
Re: Security: auto-loading protocol modules
On Sun, 2010-11-21 at 12:33 +0100, Moritz Muehlenhoff wrote: On 2010-11-18, Ben Hutchings b...@decadent.org.uk wrote: --=-ukGC3PFRUIR65dSYwt1Z Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Unlike device or filesystem modules, most protocol modules may be auto- loaded on behalf of local users without any special capabilities. This means that security vulnerabilities in such protocol modules may be exploitable by local users even on a system where there is no need for the protocol. What about CAN? It also had one or two privilege escalations in the past and seems to be used only in special purpose embedded setups. I missed that because it doesn't allow protocol = 0 so my test program failed to create a socket. The valid combinations appear to be: socket(PF_CAN, SOCK_RAW, 1) socket(PF_CAN, SOCK_DGRAM, 2) The applications I see for CAN in Debian are: - Development of automobiles, their components or diagnostic systems - Reverse-engineering and security research into deployed networks (see http://www.autosec.org/pubs/cars-oakland2010.pdf) I would not expect the need to explicitly load the module to be a problem for these users. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Security: auto-loading protocol modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/11/2010 03:08, Ben Hutchings wrote: On Thu, 2010-11-18 at 03:33 +, Ben Hutchings wrote: Unlike device or filesystem modules, most protocol modules may be auto- loaded on behalf of local users without any special capabilities. This means that security vulnerabilities in such protocol modules may be exploitable by local users even on a system where there is no need for the protocol. Protocol modules are requested via module aliases generated from the protocol-family, protocol and type numbers passed to socket(). Administrators can of course blacklist the modules or disable their aliases, but there is an ever-growing list of protocols. There has been some discussion upstream of providing a means to disable or restrict this auto-loading altogether, but this is currently unresolved. [...] It looks like DECnet is not in great shape w.r.t security and is not at all widely used. You appear to be maintaining both kernel (upstream) and userland (in Debian). What do you think of moving the module alias into dnet-common, so systems without that package are not vulnerable to security flaws in the decnet module? Hiya, The Debian DECnet package already modprobes the decnet module in the init script (it avoids some potential auto-loading race conditions), so disabling auto-load will be fine. For info, the kernel module is unmaintained upstream - I orphaned it some time ago as I have neither the time nor expertise to handle it (and never did, to be quite honest). Chrissie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFM5pTPhej7/PCycRMRAkCaAJ0QrI45Em21Ei377xuji14ItVusxQCgpSOx td8bFgVexFnfCC/eXnf04CY= =L0c9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce694cf.4090...@debian.org
Re: Security: auto-loading protocol modules
On Fri, 2010-11-19 at 15:16 +, Christine Caulfield wrote: [...] The Debian DECnet package already modprobes the decnet module in the init script (it avoids some potential auto-loading race conditions), so disabling auto-load will be fine. Thanks for your quick response. I've made this change for the next upload to sid. For info, the kernel module is unmaintained upstream - I orphaned it some time ago as I have neither the time nor expertise to handle it (and never did, to be quite honest). Oh yes, I was looking at the MAINTAINERS file from 2.6.32 and not the latest version. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Security: auto-loading protocol modules
On Thu, 2010-11-18 at 03:33 +, Ben Hutchings wrote: [...] +alias net-pf-36 af_802154 I have no idea of the security state of this. I was able to create AF_IEEE802154 sockets on system with no suitable devices. According to Vince Sanders who works on both Linux and 802.15.4 hardware though not yet together, The guys who submited it did so despite our objections and their reserch project ended there and then. The commit log doesn't show any work by the current maintainers in the last year, though there has been some recent work in their git repository. I think this alias should also be removed for now. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Security: auto-loading protocol modules
On Thu, 2010-11-18 at 03:33 +, Ben Hutchings wrote: Unlike device or filesystem modules, most protocol modules may be auto- loaded on behalf of local users without any special capabilities. This means that security vulnerabilities in such protocol modules may be exploitable by local users even on a system where there is no need for the protocol. Protocol modules are requested via module aliases generated from the protocol-family, protocol and type numbers passed to socket(). Administrators can of course blacklist the modules or disable their aliases, but there is an ever-growing list of protocols. There has been some discussion upstream of providing a means to disable or restrict this auto-loading altogether, but this is currently unresolved. [...] It looks like DECnet is not in great shape w.r.t security and is not at all widely used. You appear to be maintaining both kernel (upstream) and userland (in Debian). What do you think of moving the module alias into dnet-common, so systems without that package are not vulnerable to security flaws in the decnet module? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Security: auto-loading protocol modules
On Thu, 2010-11-18 at 03:33 +, Ben Hutchings wrote: Unlike device or filesystem modules, most protocol modules may be auto- loaded on behalf of local users without any special capabilities. This means that security vulnerabilities in such protocol modules may be exploitable by local users even on a system where there is no need for the protocol. Protocol modules are requested via module aliases generated from the protocol-family, protocol and type numbers passed to socket(). Administrators can of course blacklist the modules or disable their aliases, but there is an ever-growing list of protocols. There has been some discussion upstream of providing a means to disable or restrict this auto-loading altogether, but this is currently unresolved. [...] The AX.25 protocol modules (ax25, netrom, rose) have not had a great security record recently, and are not widely used. What do you think of moving the module aliases into ax25-tools, so systems without that package are not vulnerable to security flaws in the kernel modules? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Security: auto-loading protocol modules
Finally, x25 (*not* ax25) appears to have no applications in Debian. Google Code Search found only 4 hits for AF_X25 or PF_X25 outside of the kernel, header files or language bindings: ean - X.400 message handling software http://www.google.com/codesearch/p?hl=en#C_8T3NZHV74/pub/Apps/ean.tar.Z|yKhWeFXFTsk/ Supports BSD and SunOS 4.x. isode - ISO Development Environment http://www.google.com/codesearch/p?hl=en#Zt3wT8KZVSw/pub/unix/osi/isode-6.8.tar.Z|QdgFXEHCFMY/isode-interim/ Supports BSD and SVR2/3. x25d - replacements for the SUN supplied x29 and ybts.inetd http://www.google.com/codesearch/p?hl=en#yhcp39oOAbE/Comm/x25d.tar.gz|JTz9HiI-i1Q/ Supports SunOS with SunLink. c-kermit - remote terminal and file transfer program http://www.google.com/codesearch/p?hl=en#xjmb5K7Fhaw/kermit/ftp/archives/cku211.tar.Z|IaOxNeZiGO8/ [The above page is very slow in Iceweasel, so try downloading http://www.columbia.edu/kermit/ftp/archives/cku211.tar.Z ] X.25 code only supports SunOS with SunLink. If I've counted correctly, there are 0 applications for Linux X.25. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Security: auto-loading protocol modules
Unlike device or filesystem modules, most protocol modules may be auto- loaded on behalf of local users without any special capabilities. This means that security vulnerabilities in such protocol modules may be exploitable by local users even on a system where there is no need for the protocol. Protocol modules are requested via module aliases generated from the protocol-family, protocol and type numbers passed to socket(). Administrators can of course blacklist the modules or disable their aliases, but there is an ever-growing list of protocols. There has been some discussion upstream of providing a means to disable or restrict this auto-loading altogether, but this is currently unresolved. These are the changes in defined aliases between current stable and unstable kernels: -alias net-pf-10 ipv6 This is now built-in. +alias net-pf-16-proto-13 ip6_queue +alias net-pf-16-proto-3 ip_queue Netlink support for iptables/ip6tables. This is not new code but auto-loading was only enabled in Linux 2.6.30. Most use seems to be dependent on capable(CAP_NET_ADMIN). +alias net-pf-21 rds This has had several recent vulnerabilities. Perhaps we should remove this alias? +alias net-pf-35 phonet +alias net-pf-35-proto-2 pn_pep I was unable to create AF_PHONET sockets, so I assume they can only be created if a suitable device exists. +alias net-pf-36 af_802154 I have no idea of the security state of this. I was able to create AF_IEEE802154 sockets on system with no suitable devices. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Security: auto-loading protocol modules
On Thu, Nov 18, 2010 at 03:33:36AM +, Ben Hutchings wrote: Unlike device or filesystem modules, most protocol modules may be auto- loaded on behalf of local users without any special capabilities. This means that security vulnerabilities in such protocol modules may be exploitable by local users even on a system where there is no need for the protocol. Protocol modules are requested via module aliases generated from the protocol-family, protocol and type numbers passed to socket(). Administrators can of course blacklist the modules or disable their aliases, but there is an ever-growing list of protocols. There has been some discussion upstream of providing a means to disable or restrict this auto-loading altogether, but this is currently unresolved. I've been thinking about this as well, and I'd like to see us come up with something. Its a shame to put so many users at added risk to provide support for protocols used by just a fraction. Removing aliases is certainly one way to do it. One problem with that is that, if an admin intentionally wants to support a protocol, they have to leave the module loaded at all times. Big problem? Probably not. Another way to do this would be to ship a default blacklist. This seems like it takes the same amount of local config (instead of adding to /etc/modules, you'd comment out a line in the blacklist file). Personally, I've even considered adding dpkg filters to machines I admin to just avoid having these modules (and others) installed at all. -dann These are the changes in defined aliases between current stable and unstable kernels: -alias net-pf-10 ipv6 This is now built-in. +alias net-pf-16-proto-13 ip6_queue +alias net-pf-16-proto-3 ip_queue Netlink support for iptables/ip6tables. This is not new code but auto-loading was only enabled in Linux 2.6.30. Most use seems to be dependent on capable(CAP_NET_ADMIN). +alias net-pf-21 rds This has had several recent vulnerabilities. Perhaps we should remove this alias? +alias net-pf-35 phonet +alias net-pf-35-proto-2 pn_pep I was unable to create AF_PHONET sockets, so I assume they can only be created if a suitable device exists. +alias net-pf-36 af_802154 I have no idea of the security state of this. I was able to create AF_IEEE802154 sockets on system with no suitable devices. Ben. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118072049.gt19...@dannf.org
