network redirection has been enabled

Bug #712662 reported by Kees Cook on 2011-02-03
262
This bug affects 1 person
Affects Status Importance Assigned to Milestone
bash (Ubuntu)
High
Unassigned
Karmic
High
Unassigned
Lucid
High
Unassigned
Maverick
High
Unassigned
Natty
High
Kees Cook

Bug Description

Binary package hint: bash

Fixing bug 215034 caused bash to gain the network redirection capabilities, which is generally considered an unsafe extension to bash. This should be disabled and stay disabled.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: bash 4.1-2ubuntu5
ProcVersionSignature: Ubuntu 2.6.37-12.26-generic 2.6.37
Uname: Linux 2.6.37-12-generic x86_64
Architecture: amd64
Date: Thu Feb 3 10:30:25 2011
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.UTF-8
 LC_MESSAGES=en_US.utf8
 SHELL=/bin/bash
SourcePackage: bash

Kees Cook (kees) wrote :
security vulnerability: no → yes
Marc Deslauriers (mdeslaur) wrote :

This makes AppArmor confinement of services that have bash scripts hard, as the /dev/* devices are emulated by bash, and are not actually in the filesystem.

Changed in bash (Ubuntu):
status: New → Confirmed
Jamie Strandboge (jdstrand) wrote :

To elaborate based on discussions amont the ubuntu-security team:

It is more than just confinement by AppArmor, it is any LSM. The kernel doesn't have an implementation for mediating /dev/tcp or /dev/udp.

As a hypothetical example, consider an application confined by AppArmor, which has this rule:
  /bin/bash ixr,

This means that bash can only execute anything that the application can, with the same confinement as the application ('i' stands for 'inherit'). In practical terms, this allows all shell BUILTINS, but not access to things such as wget or netcat.

Now consider there is a vulnerability in a networked application that allows writing out a file and arbitrary execution of code. Assuming AppArmor allows the write operation (a valid assumption as there is usually somewhere an application is allowed to write to), the attacker can create a reverse shell using the network redirections present in bash by sourcing the attacker written file in bash. This is like adding '/usr/bin/nc ixr,' to the profile. Furthermore, these network redirections typically will allow access to network services on the localhost, even if the host is otherwise protected be firewalls, etc.

This is but one hypothetical example and there are certainly others. While on the surface there doesn't seem to be a big difference between allowing network redirections and using nc or wget, when you consider the system as a whole (ie, one which uses LSMs to confine applications), this feature weakens the security stance of the system.

Kees Cook (kees) on 2011-02-03
Changed in bash (Ubuntu):
importance: Undecided → High
Changed in bash (Ubuntu Maverick):
importance: Undecided → High
status: New → Confirmed
Changed in bash (Ubuntu Lucid):
importance: Undecided → High
status: New → Confirmed
Changed in bash (Ubuntu Karmic):
status: New → Confirmed
importance: Undecided → High
Changed in bash (Ubuntu Natty):
milestone: none → natty-alpha-3
Kees Cook (kees) on 2011-02-07
Changed in bash (Ubuntu Natty):
assignee: nobody → Matthias Klose (doko)
Philipp Kern (pkern) wrote :

Shouldn't you instead add an ability to confine network access instead of deleting support for network access from an interpreter? Don't you have the same issue with other interpreters?

Jamie Strandboge (jdstrand) wrote :

To Phillip,

AppArmor mediates networking (albeit in a coarse-grained fashion). For an application that doesn't require network access, there is no issue with profiling, because the profile for the application wouldn't allow network access, so any attempt to use bash' network redirection would be blocked. The problem is that every profiled application that uses networking in any way (eg, the nameservice abstraction) will have network access. This means that if we had something like this before:

/usr/bin/foo {
  #include <abstractions/nameservice>
  /bin/bash ixr,
  /usr/bin/wget ix, # called via bash
  ...
}

We now have to have:
/usr/bin/foo {
  #include <abstractions/nameservice> # allows networking
  /bin/bash Cx -> bash,
  ...
  bash {
    ... (no networking here)
    /usr/bin/wget Cx -> wget,
    ...

    wget {
      #include <abstractions/nameservice> # allows networking again
      ...
    }
  }
}

All of those '...'s theoretically are duplicated rules across the various parent, child and grandchild profiles. While possible, removing network access from bash in this manner makes the profile very difficult to create, audit and maintain. The same should be true of any LSM, not just AppArmor.

Regarding other shells, dash does not suffer from the network redirection feature. I don't know about other shells, but my understanding is this is a bashism.

Martin Pitt (pitti) on 2011-03-01
Changed in bash (Ubuntu Natty):
milestone: natty-alpha-3 → ubuntu-11.04-beta-1
Kees Cook (kees) on 2011-03-22
Changed in bash (Ubuntu Natty):
assignee: Matthias Klose (doko) → Kees Cook (kees)
status: Confirmed → In Progress
Kees Cook (kees) wrote :

Well, as much as the shell is a separate class of execution environment, it seems the trouble is mostly with strict AppArmor profile writing. Metacharacter vulnerabilities would allow the execution of other tools that do allow networking (nc, perl, python, awk). The only kind of attack that would be exclusively solved would be when "$(`" are filtered, but not "<>". This seems like too small an attack surface to justifying a delta from Debian, much less a delta from every other distribution.

Changed in bash (Ubuntu Karmic):
status: Confirmed → Won't Fix
Changed in bash (Ubuntu Maverick):
status: Confirmed → Won't Fix
Changed in bash (Ubuntu Lucid):
status: Confirmed → Won't Fix
Changed in bash (Ubuntu Natty):
status: In Progress → Won't Fix
Changed in bash (Ubuntu Natty):
milestone: ubuntu-11.04-beta-1 → none
Changed in bash (Ubuntu):
milestone: ubuntu-11.04-beta-1 → later
Changed in bash (Ubuntu):
milestone: later → none
status: In Progress → Won't Fix
assignee: Kees Cook (kees) → nobody
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers