• BB_C@lemm.ee
    link
    fedilink
    arrow-up
    6
    ·
    1 year ago

    Public Availability of “Painter” Tool

    We are proud to announce the first publicly-available tool in our Security Toolkit: Painter! Painter is an open source project that creates a complete call graph across the entire crates ecosystem to reveal how crates relate to each other. When a vulnerability exists in one crate, Painter allows users to more easily assess potential or active risks to other crates.

    The tool is aimed at addressing issues and determining risks when using other tools (such as Cargo Audit). This allows users to not only determine if a vulnerable dependency exists but if the attack path is realized. Painter was created by Rust Foundation Security Engineer Walter Pearce and released for public usage in July 2023.

    ^ This is new(ish) info.

  • gedhrel@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Given the existence of macros, doesn’t this let package maintainers run arbitrary code in the painter sandbox?

    • BB_C@lemm.ee
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      I’m afraid this question doesn’t make a lot of sense. You seem to be confused about the purpose of the painter tool, or how macros work, probably both.

      Neither is painter a sandbox tool, nor do macros have the ability to “run code”, arbitrary or otherwise, anywhere.

      painter is just a call graph analysis tool for the crates.io ecosystem. It does the analysis based on generated LLVM IR code (which is not “runnable” as is) from all versions of all crates.

      It’s security application is to reliably find what crate releases are vulnerable if a vulnerability is found in releases of crate Foo.

      Note that we already have cargo-audit and advisory-db. painter’s goal is to confirm via call graph analysis that “Yes, your crate is vulnerable. This part of your crate calls this vulnerable part of crate Foo”.

      No crate code is actually run by or in painter, except the code written to run the tool itself, of course ;)

      As for Rust macros, they get expanded in the parsing stage after lexing. You can see what’s literally expanded with cargo expand. Macros are long gone by the time you get to code generation.

      Incidentally, painter has this current limitation listed in the README:

      • LTO and optimizers are disabled to prevent inlining, but many cases exist in which the invocation is lost at a bytecode level. Source analysis can improve this. Examples of cases where an invoke is likely lost:
        • Dynamic function calls (pointers, vtables, etc.)
        • Inlining

      That’s real source/expanded code lost by the time we got to the generated IR code stage. For macros to “run arbitrary code” at that stage would be quite something ;)

      • kornel@lemmyrs.org
        link
        fedilink
        English
        arrow-up
        3
        ·
        1 year ago

        To generate the LLVM code correctly you need to run build.rs if there is any, and run proc macros which are natively compiled compiler plugins, currently running without any sandbox.

        The final code isn’t run, but the build process of Cargo crates can involve running of arbitrary code.

        The compilation process can be sandboxed as a whole, but if it runs arbitrary code, a malicious crate could take over the build process and falsify the LLVM output.

        • BB_C@lemm.ee
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          1 year ago

          Hello there. Now I feel uncomfortable. Who am I to talk in the presence of experts.

          To generate the LLVM code correctly you need to run build.rs if there is any

          Good point.

          and run proc macros which are natively compiled compiler plugins

          Hmm. When I read “Given the existence of macros”, I didn’t really think of compiler plugins. If that’s what was meant, then I apologize for what looks now like an ELI5 comment.

          The compilation process can be sandboxed as a whole, but if it runs arbitrary code, a malicious crate could take over the build process and falsify the LLVM output.

          Given that crater not only builds crates, but also runs tests, one would hope that such things wouldn’t sneak to painter unnoticed!

          • gedhrel@lemmy.ml
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            1 year ago

            Apology appreciated, but unnecessary.

            I don’t want to derail a useful tool. It’s worth going a bit beyond “hope” as a strategy, however, and thinking about if (how) this might be exploited.

            I doubt anyone will be mining crypto in your sandbox. But perhaps you should think about detection; might it be possible to mask a malicious crate with a second that attempts to detect sandboxed compilation, for instance?

            In any case, I think this still looks exceedingly interesting in the typical case, which is of detecting the impact of bugs from non-malicious actors.

            • gedhrel@lemmy.ml
              link
              fedilink
              arrow-up
              1
              ·
              1 year ago

              Given the widespread existence of wasm sandboxing, rustc itself might want to think about alternative strategies for running compiler plugins. I suspect there’d be a performance hit with such an approach, but wasm tooling is getting really good; perhaps it is minor.

        • RunAwayFrog@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          Hello kornel.

          Assuming you have the data, do you mind sharing how many crates in their latest version use compiler plugins?