Severe Flaws Found In Libarchive Open Source Library (talosintel.com) 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.
Goddammit, people! We need to use Rust NOW! (Score:1, Funny)
For crying out loud! How long must this continue? We need to start using the Rust programming language [rust-lang.org] 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
Re: (Score:1)
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.
Re:Goddammit, people! We need to use Rust NOW! (Score:5, Interesting)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
Java isn't slow (although library creep quickly makes big programs slow as molasses) but it's still a magnitude slower than C/C++. In recent benchmarks Rust performs as good (or bad) as Java, Haskell and Go and the programs also compile to much (two times) larger binaries. Although that's "okay" for most desktop software (is it?) to be significantly slower, imagine Google, Apple or Amazon suddenly requiring 10-20% more data centers worldwide or instead of the 64k chip, having to purchase the 128k chip for a
Re: (Score:2)
the Rust community is a safe space free of intolerance and prejudice, too
As evidenced by how their shills start off with "Goddammit, people..."
Re:Goddammit, people! We need to use Rust NOW! (Score:5, Insightful)
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: https://crates.io/crates/libar... [crates.io]
Re:Would a Mozilla Rust-only OS have prevented thi (Score:4, Funny)
It is Rust top to bottom.
It probably wouldn't be very good on mobile machines because, as we know, Rust never sleeps.
Re: (Score:2)
There are classes of bugs that would not show up in Rust programs. But most languages can make the same claim (for different classes of bugs). The only exception I can think of is (non-macro) assembler.
Probably the safest reasonable language is SparkAda, which is a subset of Ada. But it's not really convenient to use it.
And, honestly, a complete language is going to have entire classes of bugs that cannot be detected. This is sort of a corollary to the halting problem.
That said, Rust claims to be immune
Fad of the day vs D language (Score:1)
Re: (Score:1, Troll)
Re: (Score:2)
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.
Re: (Score:2)
And now D has missed the "type" wave that is the big hype right now.
Re: (Score:2)
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.......
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
While there's a certain amount of justice in that position, I'd be more open to it if C++ was less of a cluster-fuck. It works, sort of, but UGLY!!
That said D is putting a lot of effort into developing template level stuff which is NOT where my interest is. I understand that it helps make efficient code that you can specify at compile time, but I'm more interested in efficient code that you can adapt at run time. Objective-C would be reasonable, I think, if development hadn't stopped on anything except
Re: (Score:2)
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.
Re: (Score:1)
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.
Re: (Score:3)
That's why its linker should be called Duck Tape.
Re: (Score:2)
Rust uses the normal C/C++ linker.
Re: (Score:2)
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.
Re: (Score:2)
Windows is closed source, so you can't find out.
Re: (Score:2)
Fuck all this (Score:2, Funny)
I'm going back to DOS 2.11 on my bone stock original IBM XT.
HACK THAT! HA!
CVE-2016-4300 (Score:2)
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' ?
Re: (Score:1)
There is no shortage of CVEs for libarchive. Really.
"the libarchive maintainers have released patches" (Score:3)
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.
Re:"the libarchive maintainers have released patch (Score:4, Informative)
They are in git, indeed:
CVE-2016-4300: https://github.com/libarchive/... [github.com]
CVE-2016-4301: https://github.com/libarchive/... [github.com]
CVE-2016-4302: https://github.com/libarchive/... [github.com]
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.
Re: (Score:2)
Because when your program crashes / errors / doesn't work because someone updated the library that it depends on, it looks like you're the idiot.
Because when your program does that because the library isn't installed, or the dependencies were wrongly specified, or API changed (because the old one was declared unfixable without a change of API because of, say, a security issue?), or whatever reason, you get the blame. Have you seen the vitriol you can get as a developer on, say, Steam, because your program
Re: (Score:2, Insightful)
Basically, your post boils down to "I don't understand something, therefore it cannot possibly exist"
Now, I honestly can't tell if you're being serious or just trolling, but for your benefit, in short:
1. Shared libraries have extensive versioning information embedded into them, which is why you can hold a couple of versions of the same library. The real point of versioning is to signal ABI changes, and not marketing as you may assume.
2. If you upgrade a library, you don't crash an existing program due to AB
Re: (Score:2)
1) Yes. They do. And point versions are normally fine. When they are updated. But take OpenSSL as an example - numerous programs broke when they had to change the way the library worked. And if something breaks the ABI, the shared library stops and the program needs a rewrite. This does happen all the time.
2) No, maybe not "crash" in the programmer sense. But it will refuse to load, error out, the function won't be found by dlopen or similar. To the user, that's all pretty much the same thing. Take
Re: (Score:2)
Worst-case scenario in that setup, would be at most a single duplication of a given library version - that you already have installed in your system.
Then ALL "snaps" could run a compatibility-check when updating the snaps shared-libraries before linking to the new version, as well as ea
Re: (Score:2)
Indeed, but shared libraries have their own problems, which have the general name "central point of failure" and include things like the interface being updated in a way incompatible with your application, but also the central repository being hacked, and many other cases. I would hesitate to say that either approach is, in general, better than the other, but each approach avoids many of the problems inherent in the other.
Good luck (Score:3)
Good luck updating all your vulnerable software, Windows users!
Re: (Score:2)
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.
Re: Good luck (Score:2)
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.
Re: (Score:2)
And if they only use a part of it? That's where the real update problem comes in if it's open source.
Re: (Score:2)
Why would Free software projects include statically-compiled libraries and not update them?