Please create an account to participate in the Slashdot moderation system


Forgot your password?
Operating Systems Security BSD Linux

Severe Flaws Found In Libarchive Open Source Library ( 82

Reader itwbennett writes: Researchers from Cisco Systems' Talos group have found three memory corruption errors in the widely used open-source library libarchive that can result in arbitrary code execution and can be exploited by passing specially crafted files to applications that contain the vulnerable code. "The library is used by file and package managers included in many Linux and BSD systems, as well as by components and tools in OS X and Chrome OS," writes Lucian Constantin. "Developers can also include the library's code in their own projects, so it's hard to know how many other applications or firmware packages contain it." (Original blog post) So, while the libarchive maintainers have released patches for the flaws, it will likely take a long time for them to trickle down through all the affected projects.
This discussion has been archived. No new comments can be posted.

Severe Flaws Found In Libarchive Open Source Library

Comments Filter:
  • by Anonymous Coward

    For crying out loud! How long must this continue? We need to start using the Rust programming language [] and we need to start using it now! If you don't know what Rust is, let me inform you. The Rust web site describes it as "a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety." It has "guaranteed memory safety" and it has "threads without data races" and you get all of this with "zero-cost abstractions"! Rust doesn't just make programming safe. Thanks to

    • What he said, only substitute "Fortran" for "C and C++" and "C" for "Rust".

      Or "C" for "C and C++" and "C++" for "Rust".

      Or "$CommandName" for "C and C++" and "$CommandName_safe" for "Rust".

      Or "Rust" for "C and C++" and "IronOxide2019" for "Rust".

      Repeat as needed.

      • by Darinbob ( 1142669 ) on Wednesday June 22, 2016 @03:18PM (#52368467)

        Generally it's "please use this new language that has minimal support and is single sourced and apply it to your critical systems now!" It's nice to have new languages, but if we all rushed to the latest one then we'd just be repeating the same mistakes of having a monoculture.

        Remember when Java was the perfect language, designed from the ground up to make sure you can't do anything unsafe with it and it runs in a perfect sandbox that won't harm your computer.

        Now Rust is a nice language. But it'll take a whole lot more than "goddammit people!" to get projects to switch.

        • by guruevi ( 827432 )

          The problem with Rust and Java, even though they are safer they are also a lot slower. If you want something to be successful, you need to be able to take existing code and compile it with all the checks and balances of Rust/Java checked during compilation, not runtime. Testing is useful but not quite broad enough, on the other hand, I don't want to insert or be forced to insert a number of runtime range checks when I'm dealing with realtime code on a closed platform.

          • This is why I liked the concept in Eiffel. Basically pepper your code with lots of easy to use pre-condititions and post-conditions and develop that way, but in production you can disable those checks so that you don't have abysmal performance. Of course you need training for this, you can't just plop down any old Java programmer and have them do it right. I see code today where people just toss in asserts left and right for things that could be easily handled, so you end up with customers having regular

    • the Rust community is a safe space free of intolerance and prejudice, too

      As evidenced by how their shills start off with "Goddammit, people..."

    • by NotInHere ( 3654617 ) on Wednesday June 22, 2016 @02:20PM (#52367999)

      Its just so funny. Most rust applications as of now only work because they use rust wrappers to native libraries. So even if you wrote your program in rust, if you used this crate, you'd have exactly the same problems as all those c/c++ writers: []

      • What really amazes me is how people seem completely oblivious to D. The D programming language [] was the logical heir and successor to C, fixing many of its flaws and extending it in relevant ways.
        • Re: (Score:1, Troll)

          by BronsCon ( 927697 )
          So, what you're saying is you want the D, and you think everyone else should want the D, too?
        • It's a nice language too. It seemed to hit a peak popularity though. Mozilla could have used it but I suspect there's a lot of thinking about how to do even better, better implementation, better tuned to their local needs, etc.

        • I always thought of D (and also now, Rust) as replacements for C++, not for C. Totally different purposes.

          And now D has missed the "type" wave that is the big hype right now.
          • by haruchai ( 17472 )

            I wonder if Google Go aka golang is ready for prime time.
            I don't know who Robert Griesemer is but Rob Pike & Ken Thompson? If systems programmers had gods.......

            • Reports are that Go works great in production. The biggest reason I see that people use Rust instead is that Go is a garbage-collection based language. Also some people are turned off by the lack of inheritance, but those people probably aren't C programmers.
              • by haruchai ( 17472 )

                Just how popular is Rust? It's not been around for very long and I'm surprised that it would quickly win out over more established ones like D, Eiffel, Scala, Erlang or Ruby

                • I don't know how popular it is in terms of numbers, but in terms of hype it's the top of the heap.
                  The Rust team has an organization (Mozilla) behind them helping to drive things forward. I haven't heard of many companies adopting it (except maybe on a side/experimental project by one developer) but people are talking about replacing the entire unix-land with it because it's presumably safer.
        • by HiThere ( 15173 )

          D is a truly terrible name to search for on the web. I understand the rationale behind it, but search engines needed more consideration. Asking everyone referring to it to use the phrase "the D programming language" isn't an optimal solution. Even dlang (analogous to golang) would have been better.

        • by Anonymous Coward

          Rust is not another D. D is garbage collected, so C++ programmers would never consider it a real alternative.

          Rust is also much more modern and includes a lot of important lessons about programming languages from recent decades that D ignored.

    • What's the guarantee say? Perfect safety or your money back?

      All magic bullets are essentially myths. You fix some errors more easily but then get lulled into a false sense of security instead of always being on guard.

  • by Anonymous Coward

    I'm going back to DOS 2.11 on my bone stock original IBM XT.

  • Is not publicly available yet, why is Talos posting a public blog (and howto) for a vulnerability without proper time for the fix to trickle out to major distributions ?

    Isn't that a no-no? Especially if you claim to be a 'security specialist' ?

    • by Anonymous Coward

      There is no shortage of CVEs for libarchive. Really.

  • by volkerdi ( 9854 ) on Wednesday June 22, 2016 @02:58PM (#52368291)

    Really? I've not been able to find anything other than a new release. The patches might be in git, but they are not easily found.

    • by NotInHere ( 3654617 ) on Wednesday June 22, 2016 @03:18PM (#52368471)

      They are in git, indeed:

      CVE-2016-4300: []
      CVE-2016-4301: []
      CVE-2016-4302: []

      append .patch to the url in order to get an apply-able patch.

      But better update the whole library, usually there is lots of security related fixing going on when a security researcher takes a look at the code. Also, the git commit log may lie, and in fact some other commits fixed the issue, its just not marked this prominently.

      The best policy is always to not copy the whole library into your source tree, but making downloading the library part of the build process. If you have to modify the library some way, its best to upstream those changes, but if you don't want to do it for some reason, or can't do it, then you can create patch files, and apply the patches as part of the build process as well. Updating the library then gets as easy as changing an url and rebuilding + checking that all the patches applied + retesting.

  • by JThundley ( 631154 ) on Wednesday June 22, 2016 @06:03PM (#52369817) Homepage

    Good luck updating all your vulnerable software, Windows users!

    • by HiThere ( 15173 )

      Good luck updating all your vulnerable software, whatever your OS. It is quite legal for this code to be embedded within other code, so there's no guarantee that FOSS programs haven't done so...or done so for portions of the code, which would make an update problematical.

      • Except in most distributions, if upstream software is found to ship private copies of libraries, the packager/maintainer will either ensure the software is built against a system version if the software natively supports that or patch it to if it doesn't.

        • by HiThere ( 15173 )

          And if they only use a part of it? That's where the real update problem comes in if it's open source.

      • Why would Free software projects include statically-compiled libraries and not update them?

You are always doing something marginal when the boss drops by your desk.