Comment 5 for bug 1990570

I reviewed ruby-ffi 1.15.4+dfsg-2 as checked into kinetic. This shouldn't be considered a full audit but rather a quick gauge of maintainability.

> Ruby-FFI is a gem for programmatically loading dynamically-linked native libraries, binding functions within them, and calling those functions from Ruby code.

- CVE History:
  - CVE-2018-1000201
    - windows specific - DLL hijacking
  - open security issues in GitHub bug tracker
  - some merged PRs not closed
- Build-Depends?
  - lunar main
     - debhelper-compat (debhelper)
     - rake
     - libffi-dev (libffi)
  - lunar universe
     - gem2deb
     - ruby-rspec
- pre/post inst/rm scripts?
  - none
- init scripts?
  - none
- systemd units?
  - none
- dbus services?
  - none
- setuid binaries?
  - none
- binaries in PATH?
  - none
- sudo fragments?
  - none
- polkit files?
  - none
- udev rules?
  - none
- unit tests / autopkgtests?
  - contains build tests from upstream
  - has autopkgtests
    - failing on focal/i386 due to dependency resolution
- cron jobs?
  - none
- Build logs:
  - W: ruby-ffi source: unknown-field Ruby-Versions
  - W: ruby-ffi source: unnecessary-testsuite-autopkgtest-field [debian/control:17]

- Processes spawned?
  - benchmark, example, and spec files are not a concern
  - FFI::FfiGemHelper is okay
  - ./lib/ffi/tools/*_generator.rb files contain sharp code, downstream code may not apply it safely
    - downstream projects using this library with untrusted input or environment variables likely allow executing arbitrary code
    - this library should only be used in a closed system
- Memory management?
  - "FFI::MemoryPointer - allows for Ruby code to allocate native memory and pass it to non-Ruby libraries."
  - ruby-ffi does not work if PAX_MPROTECT is enabled
    - generally PaX is not for us
- File IO?
  - see temp file section below
  - benchmark, rakelib, debian, and spec files are not a concern
  - File.open() and File.binread() calls appear okay
- Logging?
  - *_generator.rb files redirect standard error from compiling C code to standard output
- Environment variable usage?
  - if an attacker can set the env variable CC, they might be able to run arbitrary commands with *_generator.rb functions
    - setuid use in dowstream projects requires scrutiny
  - ./ext/ffi_c/extconf.rb checks if RUBY_CC_VERSION is set
  - Rakefile, benchmark, and spec files are not a concern
- Use of privileged functions?
  - no, only in benchmarks
- Use of cryptography / random number sources etc?
  - none
- Use of temp files?
  - sample files are not a concern
  - *_generator.rb use tempfile to create C compiled code
- Use of networking?
  - none
- Use of WebKit?
  - none
- Use of PolicyKit?
  - none

- Any significant cppcheck results?
  - spec file results not relevant to MIR
- Any significant Coverity results?
  - Coverity results for build dependencies are not relevant to MIR, but will receive separate Security followup
  - Other results are spec files
- Any significant shellcheck results?
  - ./nbproject/Package-x86_64-Linux.bash results not relevant to MIR
- Any significant bandit results?
  - none

Examples in ./samples/ call shell.

It is unsafe to use this library, and likely downstream projects, with untrusted input or untrusted environmental variables.

There might be a version conflict between ruby-ffi (1.15.4) and libffi (3.4.2-4) on Kinetic. ./samples/pty.rb cannot load a function from ffi properly.

Security team ACK for promoting ruby-ffi to main.

ruby-ffi effectively provides a C compiler at runtime. It would be great if this feature was not needed.