|
func findContainerForPID(pid int32, s *state.State) (instance.Container, error) { |
|
/* |
|
* Try and figure out which container a pid is in. There is probably a |
|
* better way to do this. Based on rharper's initial performance |
|
* metrics, looping over every container and calling newLxdContainer is |
|
* expensive, so I wanted to avoid that if possible, so this happens in |
|
* a two step process: |
|
* |
|
* 1. Walk up the process tree until you see something that looks like |
|
* an lxc monitor process and extract its name from there. |
|
* |
|
* 2. If this fails, it may be that someone did an `lxc exec foo -- bash`, |
|
* so the process isn't actually a descendant of the container's |
|
* init. In this case we just look through all the containers until |
|
* we find an init with a matching pid namespace. This is probably |
|
* uncommon, so hopefully the slowness won't hurt us. |
|
*/ |
|
|
|
origpid := pid |
|
|
|
for pid > 1 { |
|
procPID := "/proc/" + strconv.Itoa(int(pid)) |
|
cmdline, err := os.ReadFile(procPID + "/cmdline") |
|
if err != nil { |
|
return nil, err |
|
} |
|
|
|
if strings.HasPrefix(string(cmdline), "[lxc monitor]") { |
|
// container names can't have spaces |
|
parts := strings.Split(string(cmdline), " ") |
|
name := strings.TrimSuffix(parts[len(parts)-1], "\x00") |
|
|
|
projectName := api.ProjectDefaultName |
|
if strings.Contains(name, "_") { |
|
projectName, name, _ = strings.Cut(name, "_") |
|
} |
|
|
|
inst, err := instance.LoadByProjectAndName(s, projectName, name) |
|
if err != nil { |
|
return nil, err |
|
} |
|
|
|
if inst.Type() != instancetype.Container { |
|
return nil, errors.New("Instance is not container type") |
|
} |
|
|
|
// Explicitly ignore type assertion check. We've just checked that it's a container. |
|
c, _ := inst.(instance.Container) |
|
return c, nil |
|
} |
|
|
|
status, err := os.ReadFile(procPID + "/status") |
|
if err != nil { |
|
return nil, err |
|
} |
|
|
|
for line := range strings.SplitSeq(string(status), "\n") { |
|
ppidStr, found := strings.CutPrefix(line, "PPid:") |
|
if !found { |
|
continue |
|
} |
|
|
|
// ParseUint avoid scanning for `-` sign. |
|
ppid, err := strconv.ParseUint(strings.TrimSpace(ppidStr), 10, 32) |
|
if err != nil { |
|
return nil, err |
|
} |
|
|
|
if ppid > math.MaxInt32 { |
|
return nil, errors.New("PPid value too large: Upper bound exceeded") |
|
} |
|
|
|
pid = int32(ppid) |
|
break |
|
} |
|
} |
|
|
|
origPidNs, err := os.Readlink(fmt.Sprintf("/proc/%d/ns/pid", origpid)) |
|
if err != nil { |
|
return nil, err |
|
} |
|
|
|
instances, err := instance.LoadNodeAll(s, instancetype.Container) |
|
if err != nil { |
|
return nil, err |
|
} |
|
|
|
for _, inst := range instances { |
|
if inst.Type() != instancetype.Container { |
|
continue |
|
} |
|
|
|
if !inst.IsRunning() { |
|
continue |
|
} |
|
|
|
initpid := inst.InitPID() |
|
pidNs, err := os.Readlink(fmt.Sprintf("/proc/%d/ns/pid", initpid)) |
|
if err != nil { |
|
return nil, err |
|
} |
|
|
|
if origPidNs == pidNs { |
|
// Explicitly ignore type assertion check. The instance must be a container if we've found it via the process ID. |
|
c, _ := inst.(instance.Container) |
|
return c, nil |
|
} |
|
} |
|
|
|
return nil, errPIDNotInContainer |
|
} |
Impact
In LXD's devLXD server, the source container identification process uses process cmdline (command line) information, allowing attackers to impersonate other containers by spoofing process names.
The core issue lies in the findContainerForPID function in
lxd/api_devlxd.go.This function identifies senders through two steps as shown below:
[lxc monitor], extract the project name and container name from that process name in the format projectName_containerName.lxd/lxd/api_devlxd.go
Lines 166 to 276 in 43d5189
Attackers can exploit Step 1 processing to impersonate arbitrary containers across projects by spoofing process names.
Reproduction Steps
This attack successfully obtains metadata (instance-id, local-hostname) of another container
DDDD from within container EEEE.
Risk
This vulnerability allows attackers to perform the following actions:
Theft of other containers' metadata information
Obtaining other containers' information via devLXD API's /1.0/meta-data endpoint:
lxd/lxd/devlxd.go
Lines 295 to 304 in 43d5189
Obtaining other containers' configuration information via devLXD API's /1.0/config and /1.0/config/{key} endpoints:
lxd/lxd/devlxd.go
Lines 175 to 221 in 43d5189
lxd/lxd/devlxd.go
Lines 228 to 267 in 43d5189
Obtaining other containers' device information via devLXD API's /1.0/devices endpoint:
lxd/lxd/devlxd.go
Lines 377 to 395 in 43d5189
Particularly in environments where multiple projects run containers on the same LXD host,
inter-project information leakage may occur. The attack prerequisite is root privileges within
any container.
Countermeasures
While containers basically run in separate PID namespaces, based on investigation, the
[lxc monitor]process runs in the same PID namespace as the LXD execution process. Therefore, the problem can be resolved by modifying the implementation to use cmdline information only when the PID namespace of the target process matches the PID namespace of the process running LXD.Patches
References
Reported by GMO Flatt Security Inc.