Prisma Cloud Compute: Alert - <path> launched and is detected as an altered or corrupted package binary

An alert similar to the ones shown below is seen on the Prisma Cloud Compute Console:

/usr/bin/ls launched and is detected as an altered or corrupted package binary. The file metadata doesn't match what's reported by the package manager.

/usr/bin/sudo launched and is detected as an altered or corrupted package binary. The file metadata doesn't match what's reported by the package manager. Full command: sudo cp -Rf /susr/bin /susr/include

• Prisma Cloud Compute Edition
• Prisma Cloud Enterprise Edition (SaaS)
• Prisma Cloud Runtime Security

1. When the image is scanned, the size of the binary files reported by the package manager of the image is then compared to the actual sizes of the binary files. 
2. If a discrepancy in the size is found, then the file is marked with the boolean field "altered=true".
3. When the binary is executed, and if the boolean field shown above is set to true, then the alert is generated.

The same can be found on the binaries section of HAR file collected when accessing the vulnerability report of the particular image..

4. If the boolean field "altered=true" is not found, but the incident is still getting created, then this usually means that the binary was replaced/updated with a different version during or after the container is started. 

For example : 

In the below case, the altered flag is not found in the HAR extract of the scan report.

{

"name": "sudo", 

"path": "/usr/bin/sudo",

"md5": "88ba4e2d726d7483f71a833f1970e1e1",

"cveCount": 0,

"fileMode": 8388681

}

However, the below Incident is still generated.

/usr/bin/sudo launched and is detected as an altered or corrupted package binary. The file metadata doesn't match what's reported by the package manager. Full command: sudo cp -Rf /susr/bin 

This is because, the entrypoint in the docker layer copies /susr/* to /usr.

"Entrypoint": [ "bin/bash", "-c", "sudo cp -Rf /susr/* /usr;"]"

But this action happens only one runtime as the entrypoint is executed when the container is run.

When the Defender scans the image, the "sudo" binary it finds and scans is the actual sudo that is present in the image which is of the below md5. (Taken from scan results har file export) 

"md5": "88ba4e2d726d7483f71a833f1970e1e1",

When the sudo binary is exported from a running container and from both locations /susr/bin/sudo and /usr/bin/sudo, the files have the below md5.

$ md5sum susr_sudo

5fd8b0ec9ac2ac0d0e0c48cdba0a7a2e susr_sudo

$ md5sum usr_sudo

5fd8b0ec9ac2ac0d0e0c48cdba0a7a2e usr_sudo

Since these two md5 checksum match and the one in the scan report is different, when sudo is executed during container runtime, defender is rightly classifying the binary as altered. Thus it generates the Incident.

1. The binary reported will have to be investigated to see if the binary is actually malicious.
2. Check if the binary is being altered during the image build process and ask the image development team to confirm if the change has been validated to be correct and trusted.
3. The path can then be allow-listed on the Runtime rule to ignore as needed by customer.

Note: Palo Alto Networks does not recommend allow-listing and it is important that the binary file is investigated before deciding to allow-list it.