The story of Linux so far, as short as it may be in the grand scheme of things, is one of constant forward momentum. There’s always another feature to implement, an optimization to make, and of course, another device to support. With developer’s eyes always on the horizon ahead of them, it should come as no surprise to find that support for older hardware or protocols occasionally falls to the wayside. When maintaining antiquated code monopolizes developer time, or even directly conflicts with new code, a difficult decision needs to be made.
Of course, some decisions are easier to make than others. Back in 2012 when Linus Torvalds officially ended kernel support for legacy 386 processors, he famously closed the commit message with “Good riddance.” Maintaining support for such old hardware had been complicating things behind the scenes for years while offering very little practical benefit, so removing all that legacy code was like taking a weight off the developer’s shoulders.
The rationale was the same a few years ago when distributions like Arch Linux decided to drop support for 32-bit hardware entirely. Maintainers had noticed the drop-off in downloads for the 32-bit versions of their distributions and decided it didn’t make sense to keep producing them. In an era where even budget smartphones are shipping with 64-bit processors, many Linux distributions have at this point decided 32-bit CPUs weren’t worth their time.
Given this trend, you’d think Ubuntu announcing last month that they’d no longer be providing 32-bit versions of packages in their repository would hardly be newsworthy. But as it turns out, the threat of ending 32-bit packages caused the sort of uproar that we don’t traditionally see in the Linux community. But why?
Continue reading “The Saga Of 32-Bit Linux: Why Going 64-Bit Raises Concerns Over Multilib”
If you started using GNU/Linux in the last 10 years or so, there’s a very good chance your first distribution was Ubuntu. But despite what you may have heard on some of the elitist Linux message boards and communities out there, there’s nothing wrong with that. The most important thing is simply that you’re using Free and Open Source Software (FOSS). The how and why is less critical, and in the end really boils down to personal preference. If you would rather take the “easy” route, who is anyone else to judge?
Having said that, such options have not always been available. When I first started using Linux full time, the big news was that the kernel was about to get support for USB Mass Storage devices. I don’t mean like a particular Mass Storage device either, I mean the actual concept of it. Before that point, USB on Linux was mainly just used for mice and keyboards. So while I might not be able to claim the same Linux Greybeard status as the folks who installed via floppies on an i386, it’s safe to say I missed the era of “easy” Linux by a wide margin.
But I don’t envy those who made the switch under slightly rosier circumstances. Quite the opposite. I believe my understanding of the core Unix/Linux philosophy is much stronger because I had to “tough it” through the early days. When pursuits such as mastering your init system and compiling a vanilla kernel from source weren’t considered nerdy extravagance but necessary aspects of running a reliable system.
So what should you do if you’re looking for the “classic” Linux experience? Where automatic configuration is a dirty word, and every aspect of your system can be manipulated with nothing more exotic than a text editor? It just so happens there is a distribution of Linux that has largely gone unchanged for the last couple of decades: Slackware. Let’s take a look at its origins, and what I think is a very bright future.
Continue reading “Making The Case For Slackware In 2018”
[Donncha O’Cearbhaill] has successfully exploited two flaws in Apport, the crash report mechanism in Ubuntu. Apport is installed by default in all Ubuntu Desktop installations >= 12.10 (Quantal). Inspired by [Chris Evan] work on exploiting 6502 processor opcodes on the NES, [Donncha] describes the whole process of finding and exploiting a 0-day on a modern linux system.
One of the flaws, tracked as CVE-2016-9949, relies on a python code injection in the crash file. Apport blindly uses the python eval() function on an unsanitized field (CrashDB) inside the .crash file. This leads directly to arbitrary python code execution. The other flaw, tracked as CVE-2016-9950, takes advantage of a path traversal attack and the execution of arbitrary Python scripts outside the system hook_dirs. The problem arises when another field (Package) from the crash report file is used without sanitizing when building a path to the package hook files.
CVE-2016-9949 is easily exploitable, if an attacker can trick a user into opening a specially crafted file (apport .crash file), the attacker can execute the python code of his/her choice. Two details make it a very interesting exploit.
The first thing to note is the exploit’s reliability. Given that it is pure python code execution, an attacker doesn’t have to worry about ASLR, Non-Exec Memory, Stack Canaries and other security features that Ubuntu ships by default. As the author notes:
“There are lots of bugs out there which don’t need hardcore memory corruption exploitation skills. Logic bugs can be much more reliable than any ROP chain.”
Another interesting detail is that the exploit file doesn’t need to have the .crash extension, as long as its content starts with the string “ProblemType: ” and the file extension is not associated already with other software, Ubuntu considers it being of mime-type type=”text/x-apport” (for example, .ZlP or .0DF). This significantly improves the chances of an unsuspecting user being fooled into open the file.
Continue reading “Reliably Exploiting Apport In Ubuntu”
With ubiquitous desktop computing now several decades old, anyone creating an operating system distribution now faces a backwards compatibility problem. Each upgrade brings its own set of new features, but it must maintain compatibility with the features of the previous versions or risk alienating users. If you are a critic of Microsoft products for their bloat, this is one of the factors behind that particular issue.
As well as a problem of compatibility, this extra software overhead creates one of security. A piece of code descended from a DOS word processor of the 1980s for example was not originally created with any idea that it might one day be hiding in a library on a machine visible to the entire world by the Internet. Our subject today is a good example, just such a vulnerability hiding in an old piece of code whose purpose is to maintain an obscure piece of backward compatibility. [Chris Evans] has demonstrated a vulnerability in an Ubuntu version by playing an NES music file that contains exploit code emulated by the player on a virtual 6502 processor.
The NES Sound Format is a music file standard that packages Nintendo game music for playback. It contains a scripting language, and it is this that is used to trigger the vulnerability. When you open an NSF file on the affected Ubuntu system it finds its way via your music player and the gstreamer multimedia framework to libgstnsf.so, a gstreamer plugin for playing NSF files.
Rather unbelievably, his plugin works by emulating a real 6502 as found in a NES to derive the musical output, and it is somewhere here that the vulnerability exists. So not only do we have layer upon layer of backward compatibility to play an obscure music file format, there is also a software emulation of some 8-bit silicon from the 1970s. [Chris] comments “Is that cool or what?“, and while we agree that a 6502 emulator buried in a modern distro is cool, we can’t help thinking something’s been lost along the way.
A proof-of-concept is provided for Ubuntu 12.04. It’s an older version, but he points out that while he thinks the most recent releases should not contain exactly the same vulnerability, it certainly exists in more than one still-supported version. There’s also a worrying twist in that due to the vagaries of Ubuntu’s file manager it auto-opens when its folder is accessed from the GUI. The year 2000 called, they want their auto-opening Windows ME worms back.
Sadly we suspect the 6502 lurking in this music player can’t be put to more general-purpose use. If you manage it, please do share it with us! But if emulated 6502s are your thing, take a look at this 150MHz 6502 co-processor for an Acorn BBC Micro that someone made using a Raspberry Pi.
6502 image, Dirk Oppelt, (CC BY-SA 3.0) via Wikimedia Commons.
The de facto standard for Raspberry Pi operating systems is Raspbian–a Debian based distribution specifically for the diminutive computer. Of course, you have multiple choices and there might not be one best choice for every situation. It did catch our eye, however, that the RaspEX project released a workable Ubunutu 16.10 release for the Raspberry Pi 2 and 3.
RaspEX is a full Linux Desktop system with LXDE (a lightweight desktop environment) and many other useful programs. Firefox, Samba, and VNC4Server are present. You can use the Ubuntu repositories to install anything else you want. The system uses kernel 4.4.21. You can see a review of a much older version of RaspEX in the video below.
Continue reading “A Slice Of Ubuntu”
Ubuntu just came out with the new long-term support version of their desktop Linux operating system. It’s got a few newish features, including incorporating the “snap” package management format. One of the claims about “snaps” is that they’re more secure — being installed read-only and essentially self-contained makes them harder to hack across applications. In principle.
[mjg59] took issue with their claims of increased cross-application security. And rather than just moan, he patched together an exploit that’s disguised as a lovable teddy bear. The central flaw is something like twenty years old now; X11 has no sense of permissions and any X11 application can listen in on the keyboard and mouse at any time, regardless of which application the user thinks they’re providing input to. This makes writing keylogging and command-insertion trojans effortless, which is just what [mjg59] did. You can download a harmless version of the demo at [mjg59]’s GitHub.
This flaw in X11 is well-known. In some sense, there’s nothing new here. It’s only in light of Ubuntu’s claim of cross-application security that it’s interesting to bring this up again.
And the teddy bear in question? Xteddy dates back from when it was cool to display a static image in a window on a workstation computer. It’s like a warmer, cuddlier version of Xeyes. Except it just sits there. Or, in [mjg59]’s version, it records your keystrokes and uploads your passwords to shady underground characters or TLAs.
We discussed Snappy Core for IoT devices previously, and we think it’s a step in the right direction towards building a system where all the moving parts are only loosely connected to each other, which makes upgrading part of your system possible without upgrading (or downgrading) the whole thing. It probably does enhance security when coupled with a newer display manager like Mir or Wayland. But as [mjg59] pointed out, “snaps” alone don’t patch up X11’s security holes.
For the last ten years or so, computing has been divided into two camps: Windows, and everything else with a *nix suffix. Want a computing paradigm where everything is a file? That’s Linux. Want easy shell scripting that makes the command line easy? Linux. Want a baroque registry with random percent signs and dollar symbols? That would be Windows. Want to run the most professional productivity apps for design and engineering? Sadly, that’s Windows as well.
*nix runs nearly the entire Internet, the top 500 supercomputers in the world, and is the build environment for every non-Windows developer. Yet Windows is the most popular operating system. The divide between Windows and *nix isn’t so much a rivalry, as much as people who still spell Microsoft with a dollar sign would tell you. It’s just the way personal computing evolved by way of legacy apps and IT directors.
Now, this great divide in the world of computing is slowly closing. At Microsoft’s Build 2016 developer’s conference, Microsoft and Canonical, Ubuntu’s parent company, announced a partnership that will allow Ubuntu to run using native Windows libraries.
In short, this announcement means bash and the Linux command line is coming to Windows 10. The command line is great, but userland is where it’s at, and here this partnership really shines. Unlike Cygwin, the current way to get *nix stuff running in a Windows environment, Windows’ bash will allow unmodified Linux programs to run unmodified on Windows 10.
It is not an understatement to say this is the most important development in operating systems in the last 10 years. For the last decade, every developer who is not purely a Windows developer has picked up a MacBook for the sole reason of having BSD under the hood. If you’re looking for a reason Apple is popular with devs, it’s *nix under the hood. This announcement changes all of that.