OpenWrt Affected By Security Issue That Could Have Led To Compromised Build Artifacts

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67184

    OpenWrt Affected By Security Issue That Could Have Led To Compromised Build Artifacts

    Phoronix: OpenWrt Afftected By Security Issue That Could Have Led To Compromised Build Artifacts

    A security issue was reported to the OpenWrt project this week around their Attendedsysupgrade Server (ASU) instances that could have led to compromised firmware images being served...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
  • Jbk0
    Junior Member
    • Jan 2022
    • 26

    #2
    why even strip a sha256 hash in the first place lol

    Comment

    • ahrs
      Senior Member
      • Apr 2021
      • 557

      #3
      Originally posted by Jbk0 View Post
      why even strip a sha256 hash in the first place lol
      Given the fix it sounds like this was an honest mistake:
      The security fixes are to correct user input validation and using full length SHA-256 hashes.
      There must have been some thinking behind it but I don't know what that thinking was. The command injection seems like the bigger issue here:
      1. **Command Injection in Imagebuilder**: During image builds, user-supplied package names are incorporated into `make` commands without proper sanitization. This allows malicious users to inject arbitrary commands into the build process, resulting in the production of malicious firmware images signed with the legitimate build key.
      However unlikely it is for somebody to make a package name called "rm -rf /home", etc, this is still an issue that should never have happened. Part of me wonders if the make build-system tool itself is part of the problem here. Could they switch to something better? If their build-system framework were written in Python, etc, would these same issues occur?

      Comment

      • skeevy420
        Senior Member
        • May 2017
        • 8577

        #4
        Originally posted by ahrs View Post

        Given the fix it sounds like this was an honest mistake:


        There must have been some thinking behind it but I don't know what that thinking was. The command injection seems like the bigger issue here:


        However unlikely it is for somebody to make a package name called "rm -rf /home", etc, this is still an issue that should never have happened. Part of me wonders if the make build-system tool itself is part of the problem here. Could they switch to something better? If their build-system framework were written in Python, etc, would these same issues occur?
        This is written in Python

        This is why the mantra of "Rewrite it in Rust" can be rather funny. Things like this show that it comes down to the developer knowing enough to cover those kinds of edge cases. The language saving you from other kinds of footguns just happens to be helpful, too.

        Comment

        • Nth_man
          Senior Member
          • Nov 2012
          • 1022

          #5
          You can't fix bad programmers with compilers; Java tried...

          Comment

          • ssokolow
            Senior Member
            • Nov 2013
            • 5081

            #6
            Originally posted by skeevy420 View Post

            This is written in Python

            This is why the mantra of "Rewrite it in Rust" can be rather funny. Things like this show that it comes down to the developer knowing enough to cover those kinds of edge cases. The language saving you from other kinds of footguns just happens to be helpful, too.
            As a Python programmer moving things to Rust, I have to say that you're not making as solid an argument as you think you are. Python has just about the weakest type system you can get while still not doing automatic type coercion.

            See, for example, this LWN.net article:

            ""I won't be talking about memory safety"", she said; one of the big mistakes made when people are trying to advocate for Rust is to entirely focus on memory safety. Kernel developers already know that C is unsafe, so pushing hard on the memory-safety point often sounds like the Rust advocates are talking down to the kernel developers. That is one of the reasons that she avoided looking at Rust for years. Instead, she believes that there are more compelling arguments for bringing Rust to the kernel.

            ""Rust can be a kernel maintainer""; a huge part of being a maintainer is to stop bad patterns in the code. That is time-consuming, and requires constantly re-explaining problems, while hoping nothing important was missed. ""It can make you snippy; it can burn through your motivation"".

            Rust can help with that, because it provides a lot of tools to enforce code patterns that would have needed to be corrected over email. It is ""a lot more capable than anything we were really ever able to do in C"". The uses of the typestate pattern are a good example of that; they have little, usually no, run-time cost. There is an upfront cost to Rust, in learning the language and in rethinking how code is written to fit into the new model, but ""the potential for saving time long term is kind of astounding"".​
            Rust can reduce bad coding that has nothing to do with memory safety in two ways:
            1. Reducing the mental burden on people auditing PRs so problems like that are more noticeable.
            2. Dependencies exposing APIs that are harder to "hold wrong"
            Last edited by ssokolow; 08 December 2024, 10:00 AM.

            Comment

            • Weasel
              Senior Member
              • Feb 2017
              • 4455

              #7
              Originally posted by Nth_man View Post
              You can't fix bad programmers with compilers; Java tried...
              Rust is trying and failing too.

              Sadly we'll only keep getting such "quality" programmers over time now because of these languages…

              Comment

              • skeevy420
                Senior Member
                • May 2017
                • 8577

                #8
                Originally posted by ssokolow View Post

                As a Python programmer moving things to Rust, I have to say that you're not making as solid an argument as you think you are. Python has just about the weakest type system you can get while still not doing automatic type coercion.

                See, for example, this LWN.net article:



                Rust can reduce bad coding that has nothing to do with memory safety in two ways:
                1. Reducing the mental burden on people auditing PRs so problems like that are mote noticeable.
                2. Dependencies exposing APIs that are harder to "hold wrong"
                My argument here is that knowledge and experience helps no matter how well a tool works or how many safeties are built-in. Eventually you get to a point where people are experts on using the tools but they might not have any idea how or why the tools work, why the safeties we have are in place, or which safeties need to be considered for which scenario.

                FWIW, I chuckled when I read both "something better" and "written in Python" in the same train of thought. Not that there's anything wrong with Python, but its Pick Two, Not Three out of Fast, Safe, and Easy are Fast and Easy. They trick us, too. Their Fast means Fast to prototype and use, not a fast execution speed like compiled languages. Sneaky bastards
                Last edited by skeevy420; 07 December 2024, 05:25 PM.

                Comment

                • Espionage724
                  Senior Member
                  • Sep 2024
                  • 326

                  #9
                  Lol wtf does an OpenWRT security issue have to do directly-enough with Python vs Rust for something people typically flash to their routers?

                  Can ya'll not have unrelated discourse on X like this? (or Bluesky, or Mastodon, any of the thousands of federated instances based on that or ActivityPub, etc maybe) It's pretty fun, and off-topic can be done freely at any time

                  Comment

                  • Barley9432
                    Phoronix Member
                    • Jun 2022
                    • 102

                    #10
                    > 21.10.0-rc2 release

                    Is this a typo? Think it's 24.10

                    Comment

                    Working...
                    X