[False Positive] Fileless Execution Alert for runc 1.1.15+ memfd on Bottlerocket 1.30.0

[ytsssun]

Describe the bug

Falco is generating false positive Critical Fileless execution via memfd_create alerts for legitimate runc operations when running on Bottlerocket OS 1.30.0. This occurs because runc 1.1.15 (included in Bottlerocket 1.30.0) now uses memfd cloning instead of bind mounts for performance optimization, which triggers Falco's fileless execution detection. The change was introduced in runc 1.1.15 to address namespace_sem lock contention issues during high container churn. This is a known behavior change that has already affected other security tools - AWS GuardDuty encountered a similar issue (see bottlerocket-os/bottlerocket#4352).

For more details about the memfd cloning in runc, see the CHANGELOG in 1.1.15 and the relevant PR #4392.

How to reproduce it

1. Use eksctl to create an EKS cluster with Bottlerocket AMI (you can get the AMI ID using aws ssm get-parameter --name /aws/service/bottlerocket/aws-k8s-1.29/x86_64/1.30.0/image_id --region us-west-2 --query 'Parameter.Value' --output text):

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
  region: us-west-2
  version: '1.29'
nodeGroups:
  - name: my-ng-bottlerocket
    instanceType: m5.large
    minSize: 0
    desiredCapacity: 1
    maxSize: 2
    amiFamily: Bottlerocket
    ami: ami-0ddad9af8c29ade8b

2. Install Falco:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install --replace falco --namespace falco --create-namespace --set tty=true falcosecurity/falco

3. Deploy any pod (example using nginx):

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

4. Check Falco logs:

kubectl logs -n falco <falco-pod-name>

Expected behaviour

No alerts should be generated for legitimate runc operations using memfd_create.

Screenshots

Example of the false positive alert:

03:45:21.111017749: Critical Fileless execution via memfd_create (container_start_ts=<NA> proc_cwd=/run/containerd/io.containerd.runtime.v2.task/k8s.io/2d19dce0c83a5ad67674fea28f51dcf4bd343bac30f7fc357394b4fb34d25edf/rootfs/ evt_res=SUCCESS proc_sname=containerd gparent=oci-add-hooks evt_type=execve user=root user_uid=0 user_loginuid=-1 process=5 proc_exepath=memfd:runc_cloned:/proc/self/exe parent=runc command=5 init terminal=0 exe_flags=EXE_WRITABLE|EXE_FROM_MEMFD container_id=host container_image=<NA> container_image_tag=<NA> container_name=host k8s_ns=<NA> k8s_pod_name=<NA>)

Environment

• Falco version: 0.39.2
• System info: Linux version 6.1.119 (builder@buildkitsandbox) (x86_64-bottlerocket-linux-gnu-gcc (Buildroot 2024.02.8) 11.4.0, GNU ld (GNU Binutils) 2.41) #1 SMP PREEMPT_DYNAMIC Fri Dec 20 22:32:32 UTC 2024
• Cloud provider: AWS EKS
• OS: Bottlerocket OS 1.30.0
• Kernel: 6.1.119
• Installation method: Helm chart

Additional context

This issue affects all users of runc 1.1.15+ where Falco is deployed for security monitoring, not just Bottlerocket users. However, Bottlerocket 1.30.0's inclusion of runc 1.1.15 makes this particularly relevant for AWS EKS users.

The issue can be temporarily mitigated by adding runc to the known_memfd_execution_binaries list:

customRules:
  rules-allow-runc-memfd.yaml: |-
    - list: known_memfd_execution_binaries
      items: [runc]
      override:
        items: append

Apply using:

helm upgrade falco falcosecurity/falco -f custom-rules.yaml -n falco

Consider adding runc to the default known_memfd_execution_binaries list in Falco's default ruleset, as this is now expected behavior for runc 1.1.15 and possibly newer versions.

[Alwin-Stockinger]

The issue can be temporarily mitigated by adding runc to the known_memfd_execution_binaries list:

customRules:
  rules-allow-runc-memfd.yaml: |-
    - list: known_memfd_execution_binaries
      items: [runc]
      override:
        items: append

This did not work for me, the proc.name is "5" or "6" for me so I had to add:

customRules:
  rules-allow-runc-memfd.yaml: |-
    - list: known_memfd_execution_binaries
      items: ["5", "6"]
      override:
        items: append

[ytsssun]

This did not work for me, the proc.name is "5" or "6" for me so I had to add:

customRules:
  rules-allow-runc-memfd.yaml: |-
    - list: known_memfd_execution_binaries
      items: ["5", "6"]
      override:
        items: append

@Alwin-Stockinger Can you share your alert output? You may be able to cover that by overwriting the known_memfd_execution_processes macro by checking the proc.exepath against memfd:runc_cloned:/proc/self/exe.

customRules:
  rules-allow-runc-memfd.yaml: |-
    # Add runc to known binaries
    - list: known_memfd_execution_binaries
      items: [runc]
      override:
        items: append

    # Add specific path conditions to existing macro
    - macro: known_memfd_execution_processes
      condition: or (proc.exepath = "memfd:runc_cloned:/proc/self/exe") or (proc.exe = "memfd:runc_cloned:/proc/self/exe")
      override:
        condition: append

[Alwin-Stockinger]

This did not work for me, the proc.name is "5" or "6" for me so I had to add:
customRules:
rules-allow-runc-memfd.yaml: |-
- list: known_memfd_execution_binaries
items: ["5", "6"]
override:
items: append

@Alwin-Stockinger Can you share your alert output?

This is a log from one of the alerts:

{
  "hostname": "ip-10-128-39-155.eu-central-1.compute.internal",
  "priority": "Critical",
  "rule": "Fileless execution via memfd_create",
  "source": "syscall",
  "tags": ["T1620", "container", "host", "maturity_stable", "mitre_defense_evasion", "process"],
  "time": "2025-01-10T09:59:58.767753707Z",
  "output_fields": {
    "container.id": "host",
    "container.image.repository": null,
    "container.image.tag": null,
    "container.name": "host",
    "container.start_ts": null,
    "evt.arg.flags": "EXE_WRITABLE|EXE_FROM_MEMFD",
    "evt.res": "SUCCESS",
    "evt.time": 1736503198767753707,
    "evt.type": "execve",
    "k8s.ns.name": null,
    "k8s.pod.name": null,
    "proc.aname[2]": "oci-add-hooks",
    "proc.cmdline": "5 init",
    "proc.cwd": "/run/containerd/io.containerd.runtime.v2.task/k8s.io/4cc4da328699e90894a115026bc07808a853fc0379fdb85e5ffc1aca7f1ec9fd/rootfs/",
    "proc.exepath": "memfd:runc_cloned:/proc/self/exe",
    "proc.name": "5",
    "proc.pname": "runc",
    "proc.sname": "containerd",
    "proc.tty": 0,
    "user.loginuid": -1,
    "user.name": "root",
    "user.uid": 0
  }
}

You may be able to cover that by overwriting the known_memfd_execution_processes macro by checking the proc.exepath against memfd:runc_cloned:/proc/self/exe.

customRules:
  rules-allow-runc-memfd.yaml: |-
    # Add runc to known binaries
    - list: known_memfd_execution_binaries
      items: [runc]
      override:
        items: append

    # Add specific path conditions to existing macro
    - macro: known_memfd_execution_processes
      condition: or (proc.exepath = "memfd:runc_cloned:/proc/self/exe") or (proc.exe = "memfd:runc_cloned:/proc/self/exe")
      override:
        condition: append

This worked, thank you 👍

[FedeDP]

Thanks for opening this detailed issue!
Tagging our rules expert @loresuso .
/milestone 0.41.0

[loresuso]

Yep, thanks for reporting this!
We are aware that runc introduced memfd-based execution also to mitigate this CVE https://unit42.paloaltonetworks.com/breaking-docker-via-runc-explaining-cve-2019-5736/

We need to update known_memfd_execution_binaries as you are suggesting. I would appreciate your contribution to falcosecurity/rules! https://github.com/falcosecurity/rules/blob/main/rules/falco_rules.yaml#L1232

[ytsssun]

Thanks, I opened a PR here - falcosecurity/rules#268