Slashdot Mirror
Severe Flaws Found In Libarchive Open Source Library (talosintel.com)
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.
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 its code of conduct the Rust community is a safe space free of intolerance and prejudice, too.
Essentially, Rust is what C and C++ should have been all along. This submission shows that we badly need what Rust offers. We need the safety of Rust, and we need it now! I don't think we really have any choice. We need to start using Rust for everything! It's the only way we can be sure that the software we're writing is safe and secure.
I'm going back to DOS 2.11 on my bone stock original IBM XT.
HACK THAT! HA!
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.
C|N>K
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' ?
Windows is closed source, so you can't find out.
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.
They are in git, indeed:
CVE-2016-4300: https://github.com/libarchive/...
CVE-2016-4301: https://github.com/libarchive/...
CVE-2016-4302: https://github.com/libarchive/...
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.
It is Rust top to bottom.
It probably wouldn't be very good on mobile machines because, as we know, Rust never sleeps.
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 needs a certain DirectX DLL and the user has to run the "official" DirectX installer all over again like they did for hundreds of other games. Or .NET. Or even audio DLL's.
And if you upgrade the library, it can break other programs on the same machine and if you don't upgrade, you can break the expectations of new programs or propagate security flaws.
Sure, it's a lovely idea that we get a perfect static API and shared libraries the same on every machine and architecture, but it's a pipe dream. And when you include certain OS into the mix, shared libraries quickly become a nightmare (e.g. Windows DLL hell such as Cygwin still has, etc.). Or are we supposed to compile against a shared library on Linux and a static on Windows?
In the end, sometimes the only way to do these things without getting 500 users on the first day of software release all complaining about install the Visual C++ DLL's yet again, or not working on a fresh system because it needs all the dependencies installing, etc. is to statically compile. Which, for 99% of programs which aren't security critical (Games? Are you going to open a "malicious" savegame?), is the only sensible way to go.
The problem is that shared libraries have no sense of versioning or backwards compatibility and little auto-resolution of dependencies without someone, somewhere literally writing out a list. And, even then, the list of dependencies sucked in might be far too much just because you include support for, say, OGG, MP3 and whatever where most people only care about MP3 but - bam - "apt-get install" automatically brings in dozens of libraries that aren't necessary, potentially giving you more problems than you started with.
The program is that the developer gets the blame for the distribution, installer, third-parties or even just lack of user common sense when it comes to shared libraries.
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 ABI changes because of 1. versioning, and also because of copy on run semantics.
3. Versioning and dependencies have been a pretty much solved problem for many years now. In fact, we're spoilt for choice with ways to manage this.
4. You don't want to hold a single copy of a library that something you installed depends on, but you'd rather hold multiple copies of the every library for every single thing you've installed? I don't understand why you can't see that this is far worse.
So I'll leave you to your security nightmare, and when you get hacked and your bank account emptied, remember to tell your bank that you were warned but failed to take sensible precautions!
Good luck updating all your vulnerable software, Windows users!
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 easily fall back to the old-library-version if necessary.
Of course you can find out. You can test against this vulnerability and see if you can exploit it on Windows, if you can't then obviously it isn't vulnerable to it.
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 to classes of bugs that make concurrent execution difficult. I prefer message passing, though.
I think we've pushed this "anyone can grow up to be president" thing too far.
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.
I think we've pushed this "anyone can grow up to be president" thing too far.
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 a Windows game and upgrade the library to a non-compatible version. It just stops working, errors out, or falls over itself into an error handler that only the developer can fix.
3) Nope. You think that. It's just not that simple. Manage a network or similar and see. Windows will bodge it by keeping old copies of DLL's around in a cache for particular programs but still be using them (insecure much?) and they can be a bitch to discover which particular version it's decided to use for a particular program. Linux et al pretty much have a "get the updated library" mentality (which is correct, but just breaks "working" programs from the user point of view). If you really want to prove this to yourself, install multiple copies of Cygwin and then see what happens to your programs that use it.
4) I don't WANT to do any of those things. Nobody does. But the reason those kinds of things occur, the reason that hundreds of games in my library have their own copies of SDL libraries and similar or are statically compiled is not because those people want to. It's because that's how you get things to work for your users with the least amount of hassle.
It's not MY security nightmare. It's OURS until we learn to deal with it differently. Our bodge at the moment is to keep old copies of libraries around silently and not tell anyone (happens even on Linux if the shared library is in use, even if only for a limited period of time until certain applications restart). That's not secure. The alternative is break existing user programs in ways that users cannot fix (Sorry, no, you can't do your banking / gaming / browsing until we release a new version). That's not acceptable either, but it is why many developers of non-security-critical programs choose not to do that.
The solution is not as clear cut as you make out, especially when new versions of libraries do anything more than just add features and put in compatibility layers for older functions. The second you deprecate, you've broken userspace. The second you introduce an element to a structure, you've broken userspace. The second you write a new way of doing things without providing a 100% backwards compatible legacy function emulation, you've broken userspace.
That might be acceptable on a closed system with on-hand developers. It's not out there in the real world, especially where people do business or are charging customers for it.
I'm not saying there's a solution. In fact, I'm saying you're blinkered to think that either way is a real-world viable solution. The problem is that we have no alternative and have to choose between "Program may be insecure" or "Program won't work next week without warning".