Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Introducing Ruby Support to OSS-Fuzz via Ruzzy #11967

Open
AdvenamTacet opened this issue May 17, 2024 · 3 comments · May be fixed by #12034
Open

[RFC] Introducing Ruby Support to OSS-Fuzz via Ruzzy #11967

AdvenamTacet opened this issue May 17, 2024 · 3 comments · May be fixed by #12034

Comments

@AdvenamTacet
Copy link

I'm creating this issue to discuss the details of adding Ruby support to OSS-Fuzz. Initially, Matt (@mschwager) spoke about it during monthly fuzzing collaboration meetings. If you missed those meetings, the goal is to incorporate Ruby support into OSS-Fuzz via Ruzzy, a Ruby fuzzer developed by Trail of Bits. You can read about Ruzzy in the blog post "Introducing Ruzzy, a coverage-guided Ruby fuzzer". Please note that we already have a working implementation that we use locally. However, some aspects of it need improvement, and we would like to discuss these before putting together a PR.

I will focus on those concerns below first, as the rest will be easier to discuss once we create a PR with the complete code.

Installing Ruby

Ruzzy requires at least version 3.0 of Ruby, meaning we cannot use its apt version (at least on Ubuntu 20.04). As it stands, we are installing RVM and then Ruby within it in the base-builder (it's also required later in the base-runner, so it needs to be copied there).

Does that sound acceptable to you?

Installing RVM

What is the best method for installing RVM? We are currently using their get script, but it should be possible to add a RVM repository and then install from apt using this new repository, if you prefer that way. Regrettably, direct use from apt is not feasible without adding the repo.

Do you have any specific preferences?

Building a project

We are seeking the most efficient method to transfer a project from the build environment to the execution environment, potentially necessitating a custom directory for building. Our working proof of concept copies an excessive amount of data, prompting us to experiment with gem install --install-dir. If you have prior experience with this, we would appreciate your insights on its usage. Additionally, if you have suggestions on how to compile in the build location and relocate the project to the execution docker environemnt, we would like to hear them. This implementation will likely be similar to the Python + Atheris OSS-Fuzz language support, so we may draw inspiration from there.

Overall

If you’d like to have a more concrete discussion, we currently have a functioning Proof of Concept. We can open a PR against this issue any time if you’d like to discuss these implementation details while reviewing the current implementation. We would greatly value your feedback and expertise while we work on the final implementation - we believe the remainder of our implementation is fairly straightforward. If you have any general questions or suggestions, we are more than happy to answer them.

@oliverchang
Copy link
Collaborator

Sorry for the delay in replying! We'd be very happy to have Ruby fuzzing integrated into OSS-Fuzz.

Some responses to your questions:

As it stands, we are installing RVM and then Ruby within it in the base-builder (it's also required later in the base-runner, so it needs to be copied there).

This seems fine.

What is the best method for installing RVM?

The get script they provide is fine, apart from the direct piping into bash. I think we'd want to ideally get a pinned version of the install script saved in the repo so we don't have rely on curling from the internet to get this.

We are seeking the most efficient method to transfer a project from the build environment to the execution environment, potentially necessitating a custom directory for building.

I'm not sure I fully understand this. Would you be able to share a more concrete example for what you mean here?

We can open a PR against this issue any time if you’d like to discuss these implementation details while reviewing the current implementation.

This would be definitely super helpful to help kickstart more concrete technical discussions. Thank you very much for working on this.

@jonathanmetzman
Copy link
Contributor

I support this integration!

AdvenamTacet added a commit to trail-of-forks/oss-fuzz that referenced this issue Jun 6, 2024
This commit brings Ruzzy, a coverage-guided fuzzer developed for pure Ruby code and Ruby C extensions, into the OSS-Fuzz project. This addition effectively integrates Ruby fuzzing support into OSS-Fuzz.

Similar to Atheris, a Python fuzzer, Ruzzy uses libFuzzer for coverage instrumentation and the fuzzing engine. It offers support for AddressSanitizer and UndefinedBehaviorSanitizer, particularly when fuzzing C extensions.

While the current code is functional, additional refinement and bug fixes may be required to ensure reliability.

You can find further discussion about this development in issue:
google#11967
AdvenamTacet added a commit to trail-of-forks/oss-fuzz that referenced this issue Jun 6, 2024
This commit brings Ruzzy, a coverage-guided fuzzer developed for pure Ruby code and Ruby C extensions, into the OSS-Fuzz project. This addition effectively integrates Ruby fuzzing support into OSS-Fuzz.

Similar to Atheris, a Python fuzzer, Ruzzy uses libFuzzer for coverage instrumentation and the fuzzing engine. It offers support for AddressSanitizer and UndefinedBehaviorSanitizer, particularly when fuzzing C extensions.

While the current code is functional, additional refinement and bug fixes may be required to ensure reliability.

You can find further discussion about this development in issue:
google#11967

Co-authored-by: mschwager <mschwager@users.noreply.github.com>
@AdvenamTacet AdvenamTacet linked a pull request Jun 6, 2024 that will close this issue
@AdvenamTacet
Copy link
Author

Hi, I've just opened a corresponding PR. I'd appreciate hearing your thoughts on this.

I'm not sure I fully understand this. Would you be able to share a more concrete example for what you mean here?

I believe I've discovered a solution. Initially, I installed a project in the rvm directory and had to replace that whole directory every time I was starting a harness. However, with the assistance of environment variables, the project and Ruzzy are now installed in separate directories (and nothing has to be moved while starting a harness). Technically, installing Ruzzy in a non-default directory is not essential, but I believe it's nice.

Could you identify any potential downsides to this approach? I hope it to be transparent for users.


In terms of pinning the appropriate version of Ruby and rvm, how should I pin Ruby and rvm?

If there's anything you'd like me to revise, please inform me.

Please note that we've observed intermittent failure of harnesses at start-up time, likely due to a race condition (based on my guess). If you've also encountered this, do let us know. Any suggestions on how to address this issue would be most appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants