6 ms·

Fish in a Barrel Memory Safety Bounty Program

52 points by Titanous 6y ago

kingkilr 6y ago
One of the folks behind the bounty here. Happy to answer questions.
- stevekemp 6y ago
  I can think of ten security-critical applications/services off the top of my head which are will never accept patches/changes to rewrite some/all of them in memory-safe languages. I appreciate the goal of using languages better suited to memory-safety, but when I look at CVE lists including the same recurring projects I can't help thinking that the bounties here are not going to help. (For example imagemagick/graphicmagic, the linux kernel, even wordpress/jenkins plugins, and similar things are regular candidates for security issues - and they're not going to get rewritten/modified-in-place to use rust/golang any time soon.)
  - kingkilr 6y ago
    The kernel maintainers have actively expressed interest in having upstream support for writing kernel modules in Rust!
    - saagarjha 6y ago
      Which might be eligible for a bounty under this program, but I doubt the kernel itself will have parts of it written in a memory-safe language anytime soon.
      - kingkilr 6y ago
        Lots of drivers, network protocols, etc. in the kernel, and they're most of the attack surface -- not the scheduler :-) We have to approach this as a question of how, not if. When we do that, we can change computer security.
  - philipkglass 6y ago
    WordPress is written in PHP and Jenkins is written in Java. These are already memory-safe languages. Security problems in their plugins rarely if ever derive from memory safety issues.
    - stevekemp 6y ago
      Bad examples, yes. Sorry! Pretend I wrote gstreamer, wireshark, or similar.
- deleted 6y ago
  [deleted]
hackcasual 6y ago
> Q: What if the maintainers won't accept the patch? > A: The Fish in a Barrel Memory Safety Bounty only rewards contributions that are merged upstream. We strongly encourage people interested in pursuing a bounty to work with, not against, open source maintainers and to behave respectfully. It's good to see this called out specifically, but I can't help but think this is attaching a monetary incentive to badger a project to accept a patch that at the very least requires changes to the project build system
- kingkilr 6y ago
  Those of us who organized this both have a long history of involvement in open source. If we have even an iota of this becoming a problem, we will a) be incredibly saddened, b) figure out how to restructure the rules to address the behavior we see.
  - Arnavion 6y ago
    Maybe make it a requirement that the contribution PR / email has to mention https://github.com/fishinabarrel/bounty https://github.com/fishinabarrel/bounty so that maintainers know who to give feedback to.
- jentist_retol 6y ago
  It's $100-$500, that's not even a moderate amount of money for the amount of work required. It seems to me to be more of an incentive, and a nice reward for doing good work that helps people.
- Arnavion 6y ago
  >Partially (or completely) migrate the project to a memory-safe language (e.g., convert one of the decoder/encoders in an image parsing library to Rust) For this kind of contribution, I'm not sure there'll be too much spam. Eg most of the "Rewrite It In Rust"-kind of spam like [1] is people making suggestions, not actual PRs, because it does actually take effort. But... >Add bindings making the library usable from Rust or Swift (e.g., adding official Swift bindings to an image parsing library) ... I'm not sure about this one. It could be as mindless as "just run bindgen on the C header, wrap it in a -sys crate" and send a PR. I don't actually understand why that kind of contribution is being awarded though, since having safe bindings doesn't make the actual library any safer. Furthermore, bindings don't need to be contributed to upstream, just like all the Rust bindings libraries today are mostly third-party. [1]: https://www.postgresql.org/message-id/CAASwCXdQUiuUnhycdRvrUmHuzk5PsaGxr54U4t34teQjcjb%3DAQ%40mail.gmail.com https://www.postgresql.org/message-id/CAASwCXdQUiuUnhycdRvrU...
f00zz 6y ago
Sorry, but I'm not seeing how this will help. If I take e.g. libpng and rewrite it in Rust, then it's basically a new project. I don't understand how a patch replacing all existing code will be accepted upstream, or how the many projects using libpng will be convinced to use my new library.
- kingkilr 6y ago
  It's a great question! a) It being acceptable to upstream is mandatory to receive a bounty, so a starting point might be: pick projects whose maintainers are sick of dealing with ASAN reports! b) A huge number of people get their libpng or anything else via a package manager like Debian. Debian packages libpng from upstream. If libpng changes something about it's implementation, that'll be reflected in a future debian release. This is going to be a long process, but we firmly believe the question has to be "how" not "if". If you've got better ideas for how we can promote the transition to memory safe languages, please let us know!
- ploxiln 6y ago
  One example: librsvg was rewritten from C into Rust, gradually, while retaining the C API: https://gitlab.gnome.org/GNOME/librsvg https://gitlab.gnome.org/GNOME/librsvg https://people.gnome.org/~federico/news-2016-10.html https://people.gnome.org/~federico/news-2016-10.html (I do not necessarily endorse this, as I find the dependency on a Rust compiler of very recent vintage, to be much more annoying than depending on any decent C compiler from the last 7 years or so.)
  - tialaramex 6y ago
    But the vastly many more users don't need that compiler right? If you merely write a program to render SVG you don't care, your program just got safer "magically" ? If you run such a program you aren't even aware anything happened, the updated version is apparently safer.
    - NullPrefix 6y ago
      Except for all the corner cases that were covered by the original and are not by the rewrite.
rurban 6y ago
Rewriting stuff in memory safe languages would be a worthwhile goal, but then they go on by providing bounties to write Linux Kernel drivers in Rust. Rust is memory safe only in documentation but not in practise.[1] Rather provide bounties for real memory safe languages. Rust is also neither type safe[2] nor concurrency safe[3]. 1: eg https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+stack+overflow https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao... but this is just the surface. alloca is not only unsafe but also security critical. Rust stack allocates too much unchecked. 2. https://doc.rust-lang.org/reference/unsafe-blocks.html https://doc.rust-lang.org/reference/unsafe-blocks.html 3. Races as eg with https://doc.rust-lang.org/reference/items/static-items.html?highlight=Concurrency#mutable-statics https://doc.rust-lang.org/reference/items/static-items.html?... requiring manual mutexes

52 points by Titanous 6y ago

kingkilr 6y ago

One of the folks behind the bounty here. Happy to answer questions.

stevekemp 6y ago
I can think of ten security-critical applications/services off the top of my head which are will never accept patches/changes to rewrite some/all of them in memory-safe languages. I appreciate the goal of using languages better suited to memory-safety, but when I look at CVE lists including the same recurring projects I can't help thinking that the bounties here are not going to help. (For example imagemagick/graphicmagic, the linux kernel, even wordpress/jenkins plugins, and similar things are regular candidates for security issues - and they're not going to get rewritten/modified-in-place to use rust/golang any time soon.)
- kingkilr 6y ago
  The kernel maintainers have actively expressed interest in having upstream support for writing kernel modules in Rust!
  - saagarjha 6y ago
    Which might be eligible for a bounty under this program, but I doubt the kernel itself will have parts of it written in a memory-safe language anytime soon.
    - kingkilr 6y ago
      Lots of drivers, network protocols, etc. in the kernel, and they're most of the attack surface -- not the scheduler :-) We have to approach this as a question of how, not if. When we do that, we can change computer security.
- philipkglass 6y ago
  WordPress is written in PHP and Jenkins is written in Java. These are already memory-safe languages. Security problems in their plugins rarely if ever derive from memory safety issues.
  - stevekemp 6y ago
    Bad examples, yes. Sorry! Pretend I wrote gstreamer, wireshark, or similar.
deleted 6y ago
[deleted]

hackcasual 6y ago

> Q: What if the maintainers won't accept the patch? > A: The Fish in a Barrel Memory Safety Bounty only rewards contributions that are merged upstream. We strongly encourage people interested in pursuing a bounty to work with, not against, open source maintainers and to behave respectfully. It's good to see this called out specifically, but I can't help but think this is attaching a monetary incentive to badger a project to accept a patch that at the very least requires changes to the project build system

kingkilr 6y ago
Those of us who organized this both have a long history of involvement in open source. If we have even an iota of this becoming a problem, we will a) be incredibly saddened, b) figure out how to restructure the rules to address the behavior we see.
- Arnavion 6y ago
  Maybe make it a requirement that the contribution PR / email has to mention https://github.com/fishinabarrel/bounty https://github.com/fishinabarrel/bounty so that maintainers know who to give feedback to.
jentist_retol 6y ago
It's $100-$500, that's not even a moderate amount of money for the amount of work required. It seems to me to be more of an incentive, and a nice reward for doing good work that helps people.
Arnavion 6y ago
>Partially (or completely) migrate the project to a memory-safe language (e.g., convert one of the decoder/encoders in an image parsing library to Rust) For this kind of contribution, I'm not sure there'll be too much spam. Eg most of the "Rewrite It In Rust"-kind of spam like [1] is people making suggestions, not actual PRs, because it does actually take effort. But... >Add bindings making the library usable from Rust or Swift (e.g., adding official Swift bindings to an image parsing library) ... I'm not sure about this one. It could be as mindless as "just run bindgen on the C header, wrap it in a -sys crate" and send a PR. I don't actually understand why that kind of contribution is being awarded though, since having safe bindings doesn't make the actual library any safer. Furthermore, bindings don't need to be contributed to upstream, just like all the Rust bindings libraries today are mostly third-party. [1]: https://www.postgresql.org/message-id/CAASwCXdQUiuUnhycdRvrUmHuzk5PsaGxr54U4t34teQjcjb%3DAQ%40mail.gmail.com https://www.postgresql.org/message-id/CAASwCXdQUiuUnhycdRvrU...

f00zz 6y ago

Sorry, but I'm not seeing how this will help. If I take e.g. libpng and rewrite it in Rust, then it's basically a new project. I don't understand how a patch replacing all existing code will be accepted upstream, or how the many projects using libpng will be convinced to use my new library.

kingkilr 6y ago
It's a great question! a) It being acceptable to upstream is mandatory to receive a bounty, so a starting point might be: pick projects whose maintainers are sick of dealing with ASAN reports! b) A huge number of people get their libpng or anything else via a package manager like Debian. Debian packages libpng from upstream. If libpng changes something about it's implementation, that'll be reflected in a future debian release. This is going to be a long process, but we firmly believe the question has to be "how" not "if". If you've got better ideas for how we can promote the transition to memory safe languages, please let us know!
ploxiln 6y ago
One example: librsvg was rewritten from C into Rust, gradually, while retaining the C API: https://gitlab.gnome.org/GNOME/librsvg https://gitlab.gnome.org/GNOME/librsvg https://people.gnome.org/~federico/news-2016-10.html https://people.gnome.org/~federico/news-2016-10.html (I do not necessarily endorse this, as I find the dependency on a Rust compiler of very recent vintage, to be much more annoying than depending on any decent C compiler from the last 7 years or so.)
- tialaramex 6y ago
  But the vastly many more users don't need that compiler right? If you merely write a program to render SVG you don't care, your program just got safer "magically" ? If you run such a program you aren't even aware anything happened, the updated version is apparently safer.
  - NullPrefix 6y ago
    Except for all the corner cases that were covered by the original and are not by the rewrite.

rurban 6y ago

Rewriting stuff in memory safe languages would be a worthwhile goal, but then they go on by providing bounties to write Linux Kernel drivers in Rust. Rust is memory safe only in documentation but not in practise.[1] Rather provide bounties for real memory safe languages. Rust is also neither type safe[2] nor concurrency safe[3]. 1: eg https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+stack+overflow https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao... but this is just the surface. alloca is not only unsafe but also security critical. Rust stack allocates too much unchecked. 2. https://doc.rust-lang.org/reference/unsafe-blocks.html https://doc.rust-lang.org/reference/unsafe-blocks.html 3. Races as eg with https://doc.rust-lang.org/reference/items/static-items.html?highlight=Concurrency#mutable-statics https://doc.rust-lang.org/reference/items/static-items.html?... requiring manual mutexes