FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 11-18-2010, 02:33 AM
Ben Hutchings
 
Default 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.
 
Old 11-18-2010, 06:20 AM
dann frazier
 
Default Security: auto-loading protocol modules

On Thu, Nov 18, 2010 at 03:33:36AM +0000, 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101118072049.GT19165@dannf.org">http://lists.debian.org/20101118072049.GT19165@dannf.org
 
Old 11-18-2010, 12:37 PM
Ben Hutchings
 
Default Security: auto-loading protocol modules

On Thu, 2010-11-18 at 03:33 +0000, 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.
 
Old 11-19-2010, 02:08 AM
Ben Hutchings
 
Default Security: auto-loading protocol modules

On Thu, 2010-11-18 at 03:33 +0000, 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.
 
Old 11-19-2010, 02:14 AM
Ben Hutchings
 
Default Security: auto-loading protocol modules

On Thu, 2010-11-18 at 03:33 +0000, 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.
 
Old 11-19-2010, 02:44 AM
Ben Hutchings
 
Default 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.
 
Old 11-19-2010, 02:16 PM
Christine Caulfield
 
Default 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 +0000, 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4CE694CF.4090600@debian.org">http://lists.debian.org/4CE694CF.4090600@debian.org
 
Old 11-20-2010, 03:15 AM
Ben Hutchings
 
Default Security: auto-loading protocol modules

On Fri, 2010-11-19 at 15:16 +0000, 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.
 
Old 11-21-2010, 10:33 AM
Moritz Muehlenhoff
 
Default Security: auto-loading protocol modules

On 2010-11-18, Ben Hutchings <ben@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrniei0sk.2er.jmm@inutil.org">http://lists.debian.org/slrniei0sk.2er.jmm@inutil.org
 
Old 11-22-2010, 03:16 AM
Ben Hutchings
 
Default Security: auto-loading protocol modules

On Sun, 2010-11-21 at 12:33 +0100, Moritz Muehlenhoff wrote:
> On 2010-11-18, Ben Hutchings <ben@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.
 

Thread Tools




All times are GMT. The time now is 09:38 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org