Look for ruby binary library evidence over executable

[witchcraze]

What happened:

At first, this is very rare case, and ruby image side bug

I noticed syft can not detect ruby in these images.
rubylang/ruby:3.2.1-jammy-amd64-7a04a2654b938d96a521d2f8eff3439e19b8fa60
rubylang/ruby:3.2.1-jammy-arm64-7a04a2654b938d96a521d2f8eff3439e19b8fa60
rubylang/ruby:3.2.1-focal-amd64-7a04a2654b938d96a521d2f8eff3439e19b8fa60
rubylang/ruby:3.2.1-focal-arm64-7a04a2654b938d96a521d2f8eff3439e19b8fa60
rubylang/ruby:3.2.1-focal-arm64-43f3e1222e5df987e7adc637cf0ee17b45525bda
rubylang/ruby:3.2.1-focal-amd64-43f3e1222e5df987e7adc637cf0ee17b45525bda
rubylang/ruby:3.2.1-jammy-arm64-43f3e1222e5df987e7adc637cf0ee17b45525bda
rubylang/ruby:3.2.1-jammy-amd64-43f3e1222e5df987e7adc637cf0ee17b45525bda
rubylang/ruby:3.2.1-jammy-arm64-424ef1bccb4b1631c2a3a769656e2e01b6fceff4
rubylang/ruby:3.2.1-jammy-amd64-424ef1bccb4b1631c2a3a769656e2e01b6fceff4

What you expected to happen:

ruby is detected
Maybe, need to check libruby.so.3.2.1 directry...

Steps to reproduce the issue:

$ syft -q rubylang/ruby:3.2.1-jammy-amd64-7a04a2654b938d96a521d2f8eff3439e19b8fa60 | grep ruby
ruby2_keywords       0.0.5                                    gem

Anything else we need to know?:

As libruby.so.3.2 is nothing in initial status, ruby version is not shown.

$ docker run -it --rm rubylang/ruby:3.2.1-jammy-amd64-7a04a2654b938d96a521d2f8eff3439e19b8fa60
# which ruby
/usr/local/bin/ruby
# /usr/local/bin/ruby -v
/usr/local/bin/ruby: error while loading shared libraries: libruby.so.3.2: cannot open shared object file: No such file or directory
# ldd /usr/local/bin/ruby | grep libruby
        libruby.so.3.2 => not found
# ls -al /usr/local/lib/
total 19208
drwxr-xr-x 1 root root     4096 Feb 13  2023 .
drwxr-xr-x 1 root root     4096 Jan 26  2023 ..
lrwxrwxrwx 1 root root       16 Feb 13  2023 libruby.so -> libruby.so.3.2.1
lrwxrwxrwx 1 root root       16 Feb 13  2023 libruby.so. -> libruby.so.3.2.1
-rwxr-xr-x 1 root root 19648592 Feb 13  2023 libruby.so.3.2.1
drwxr-xr-x 2 root root     4096 Feb 13  2023 pkgconfig
drwxr-xr-x 6 root root     4096 Feb 13  2023 ruby

I noticed by chance, after installing bin-utils, ruby version is shown.

# apt install binutils
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  binutils-common binutils-x86-64-linux-gnu libbinutils libctf-nobfd0 libctf0
Suggested packages:
  binutils-doc
The following NEW packages will be installed:
  binutils binutils-common binutils-x86-64-linux-gnu libbinutils libctf-nobfd0 libctf0

# /usr/local/bin/ruby -v
ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]
# ldd /usr/local/bin/ruby | grep libruby
        libruby.so.3.2 => /usr/local/lib/libruby.so.3.2 (0x000071e7dac1c000)
# ls -al /usr/local/lib/
total 19212
drwxr-xr-x 1 root root     4096 Nov  7 07:29 .
drwxr-xr-x 1 root root     4096 Jan 26  2023 ..
lrwxrwxrwx 1 root root       16 Feb 13  2023 libruby.so -> libruby.so.3.2.1
lrwxrwxrwx 1 root root       16 Feb 13  2023 libruby.so. -> libruby.so.3.2.1
lrwxrwxrwx 1 root root       16 Nov  7 07:29 libruby.so.3.2 -> libruby.so.3.2.1
-rwxr-xr-x 1 root root 19648592 Feb 13  2023 libruby.so.3.2.1
drwxr-xr-x 2 root root     4096 Feb 13  2023 pkgconfig
drwxr-xr-x 6 root root     4096 Feb 13  2023 ruby

[kzantow]

For what it's worth, we are doing something sorta like this for libpython -- if it finds a python* binary, then also looks for a libpython to get the version, then separately libpython is scanned again, and deduplicated to only retain the python binary as the main record.

[witchcraze]

Thank you for your advice.

Yes, ruby also use sharedLibraryLookup.
But in this case, shared library - libruby.so.3.2 - is missing...

# ldd /usr/local/bin/ruby | grep libruby
        libruby.so.3.2 => not found

I think checking libruby.so.* (in this case, libruby.so.3.2.1) directly will be required, like "python-binary-lib".
But I feel checking libruby.so.* for very rare case with unproper ruby is too much action...

So, I have no good idea for this.

[kzantow]

Hey @witchcraze -- it looks like the Python binary matcher does the shared library lookup first, whereas the ruby does it second -- I wonder if there's some issue that the first evidence matcher is returning garbage and preventing the shared library lookup from running? It looks like the pattern should pick up libruby.so.3.2.1, which seems like it would work, if I'm understanding the problem right.

Here's the problematic spot: https://github.com/anchore/syft/blob/main/syft/pkg/cataloger/binary/classifiers.go#L386C5-L390C19 -- note the rubyMatcher is first:

				rubyMatcher,
				sharedLibraryLookup(
					// try to find version information from libruby shared libraries
					`^libruby\.so.*$`,
					rubyMatcher),