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.
Comment removed (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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)
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)
Re: (Score:2)
Rust uses the normal C/C++ linker.
Re: (Score:2)
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?