Announcement

Collapse
No announcement yet.

F2FS Hit By Three Security Vulnerabilities: Memory Corruption, Possible Code Execution

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • F2FS Hit By Three Security Vulnerabilities: Memory Corruption, Possible Code Execution

    Phoronix: F2FS Hit By Three Security Vulnerabilities: Memory Corruption, Possible Code Execution

    Btrfs isn't the only Linux file-system taking some heat but the Flash-Friendly File-System (F2FS) is now having a tough week with three CVEs going public...

    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

  • #2
    I have Google phone, so that means it has original and long support. Thanks to that I have actual brand new 3.0 kernel. Thank you Google, you are the best.

    Comment


    • #3
      *Inserts comment about how those CVEs could have been avoided with Rust instead of C* Though that'd require a kernel written in Rust I think like Redox?

      Curious...there are projects to convert C to Rust(well they kickstart the conversion, still quite a bit to do manually), what are the chances of going the other way and outputting C(that'd supposedly be as safe as the Rust code was but usable for the kernel?

      Comment


      • #4
        Now, could these vulnerabilities be used to 'root' older android phones whithout unlocked bootloaders to maybe free them up a bit?

        secure boot loader->signed kernel->F2FS reads /data or something->vulnerability runs unsigned code->unsigned code loads new kernel->other magic

        Comment


        • #5
          Son of a bitch. I wanted to say Rust first. But yeah. Rust would prevent this. Cue in for all the butthurt C grandpas who want the pretend that C is perfect.
          Last edited by garegin; 08 August 2017, 08:13 AM.

          Comment


          • #6
            Originally posted by polarathene View Post
            *Inserts comment about how those CVEs could have been avoided with Rust instead of C* Though that'd require a kernel written in Rust I think like Redox?

            Curious...there are projects to convert C to Rust(well they kickstart the conversion, still quite a bit to do manually), what are the chances of going the other way and outputting C(that'd supposedly be as safe as the Rust code was but usable for the kernel?
            In case you haven’t heard, another serious OpenSSL vulnerability will be announced this Thursday. It reminded me of about a year ago, when Heartbleed was announced: In December 2014 I gave a talk at Mozilla about cryptography in Rust (slides... | Tony Arcieri | Hi there. These days I dabble in Rust and cryptography, but in the past made the Celluloid actor framework for Ruby and the Reia programming language


            This is interesting right. Rust will prevent some errors but not them all. Even with rust we will need static analysis tools.

            These 3 CVE could have been avoided by running http://cppcheck.sourceforge.net/ as part of the general kernel building and repairing what it reported. This is why a standard to plug static analysis tools into gcc and possible other c and c++ compliers using standard interfaces recently was so interesting.

            A minimal Linux kernel module written in rust. Contribute to tsgates/rust.ko development by creating an account on GitHub.


            Rust runs into nightmares with C header files. This makes it very hard to migrate Linux kernel piece by piece. Once you have something like the Linux kernel in the millions of lines migrating to rust is a up hill battle.

            Better chance is to make C language allowed to be uses stricter so preventing the same issues as rust does. Linux kernel complier plugins and the like.


            So the Linux kernel is taking another path to stop these problems. Of course none of this happens quickly.

            Comment


            • #7
              Again, this vulnerabilities did not hit F2FS, but F2FS Linux drivers.
              A file system vulnerability would be something in the storage layout itself which could be exploited to corrupt data (e.g. if you could, with a conformant implementation make inode metadata spill over user data).

              Comment


              • #8
                So why didn't they. And heartbleed could've been prevented with fuzz testing. History has shown that "real men know how to be careful" shtick that C devs say is not true. It's been 40 years and they make mistakes every day. Better to be safe upfront.

                Comment


                • #9
                  Originally posted by polarathene View Post
                  *Inserts comment about how those CVEs could have been avoided with Rust instead of C* Though that'd require a kernel written in Rust I think like Redox?

                  Curious...there are projects to convert C to Rust(well they kickstart the conversion, still quite a bit to do manually), what are the chances of going the other way and outputting C(that'd supposedly be as safe as the Rust code was but usable for the kernel?
                  no. The answer is make decent automated testing suites and running them very often and fix up the shit that crops up.

                  Rust is better than C but you need automated testing anyway.

                  Comment


                  • #10
                    I used to rely on Mudflaps, catches it happening.

                    Comment

                    Working...
                    X