search

chainguard-dev / melange

build APKs from source code
Apache License 2.0
426 stars 109 forks source link

SCA Bug with libcap #920

Closed jonjohnsonjr closed 10 months ago

jonjohnsonjr commented 10 months ago

See https://apk.dag.dev/https/packages.wolfi.dev/os/aarch64/libcap-2.69-r1.apk@sha1:770a2cb5273333ca8122f08b0b65db1aab9dd689/.PKGINFO?all=true

We have a depend = so:libpsx.so.2 line, but if you look at the package contents: https://apk.dag.dev/https/packages.wolfi.dev/os/aarch64/libcap-2.69-r1.apk@sha1:770a2cb5273333ca8122f08b0b65db1aab9dd689/?all=true

We should have a provides line instead.

jonjohnsonjr commented 10 months ago

New info. These both have PT_INTERP set to /lib/ld-linux-aarch64.so.1:

ℹ️  aarch64   | interpreter for libcap.so.2.69 => /lib/ld-linux-aarch64.so.1
ℹ️  aarch64   | interpreter for libpsx.so.2.69 => /lib/ld-linux-aarch64.so.1

Because libcap starts with libc, the libcap.so.2.69 is treated as a provides, whereas the libpsx is not:

https://github.com/chainguard-dev/melange/blob/4e4e3588b8be1af6e31a6f8be931ae990c3fc1a3/pkg/sca/sca.go#L321

kaniini commented 10 months ago

Oh, that is a nasty one. We can probably search for "libc-" and "libc." instead.

jonjohnsonjr commented 10 months ago

That would leave us with 2 problematic shared objects instead of just the 1 since they should both be provided. I am not sure what kind of heuristic we can apply to know if an and ELF file with a non-empty interpreter is actually not an executable?

kaniini commented 10 months ago

I think the current heuristic is the best we can do. But we could probably use objcopy or patchelf to strip the interpreter header.