Giving Linux The Remote Boot

A lot of embedded systems are running Linux on platforms like Raspberry Pi. Since Linux is fully functional from a command line and fully network-capable, it is possible to run servers that you’ve never had physical access to.

There are a few problems, though. Sometimes you really need to reboot the box physically. You also need to be at the console to do things like totally install a new operating system. Or do you? Over on GitHub, user [marcan] has a C program and a shell script that allows you to take over a running system without using any software on the root filesystem. It starts an ssh server and you can remotely unmount the main drive, do any maintenance you want and –presumably–reboot into a new operating system.

Continue reading “Giving Linux The Remote Boot”

Grant Anyone Temporary Permissions To Your Computer With SSH

This is a super cute hack for you Linux users out there. If you have played around with SSH, you know it’s the most amazing thing since sliced bread. For tunneling in, tunneling out, or even just to open up a shell safely, it’s the bees knees. If you work on multiple computers, do you know about ssh-copy-id? We had been using SSH for years before stumbling on that winner.

Anyway, [Felipe Lavratti]’s ssh-allow-friend script is simplicity itself, but the feature it adds is easily worth the cost of admission. All it does is look up your friend’s public key (at the moment only from GitHub) and add it temporarily to your authorized_keys file. When you hit ctrl-C to quit the script, it removes the keys. As long as your friend has the secret key that corresponds to the public key, he or she will be able to log in as your user account.

Continue reading “Grant Anyone Temporary Permissions To Your Computer With SSH”

EEPROM Hack To Fix Autodetection Issues

Autodetection of hardware was a major part of making computers more usable for the average user. The Amiga had AutoConfig on its Zorro bus, Microsoft developed Plug And Play, and Apple used NuBus, developed by MIT. It’s something we’ve come to take for granted in the modern age, but it doesn’t always work correctly. [Evan] ran into just this problem with a video capture card that wouldn’t autodetect properly under Linux.

The video capture card consisted of four PCI capture cards with four inputs each, wired through a PCI to PCI-E bus chip for a total of sixteen inputs. Finding the cause of the problem wasn’t too difficult – the driver was detecting the card as a different model with eight inputs, instead of the sixteen inputs actually present on the card. The driver detects the device plugged in by a unique identifier reported by the card. The code on the card was identical to the code for a different model of card with different hardware, causing the issue.

As a quick test, [Evan] tried fudging the driver selection, forcing the use of a driver for a sixteen-input model. This was successful – all sixteen inputs could now be used. But it wasn’t a portable solution, and [Evan] would have to remember this hack every time the card needed to be reinstalled or moved to a different computer.

Looking further at the hardware, [Evan] discovered the card had four 24c02 EEPROM chips on board – one for each PCI card on board. Dumping the contents, they recognised the unique identifier the driver was using to determine the card’s model. It was then a simple job to change this value to one that corresponded with a sixteen-input card to enable functional autodetection by burning a new value to the EEPROM. [Evan] then published the findings to the LinuxTVWiki page. Continue reading “EEPROM Hack To Fix Autodetection Issues”

Improving Raspberry Pi Disk Performance

Usually, you think of solid state storage as faster than a rotating hard drive. However, in the case of the Raspberry Pi, the solid state “disk drive” is a memory card that uses a serial interface. So while a 7200 RPM SATA drive might get speeds in excess of 100MB/s, the Pi’s performance is significantly less.

[Rusher] uses the Gluster distributed file system and Docker on his Raspberry Pi. He measured write performance to be a sluggish 1MB/s (and the root file system was clocking in at just over 40MB/s).

There are an endless number of settings you could tweak, but [Rusher] heuristically picked a few he thought would have an impact. After some experimentation, he managed 5MB/s on Gluster and increased the normal file system to 46 MB/s.

Continue reading “Improving Raspberry Pi Disk Performance”

Raspberry Pi Software Comes To PC, Mac

The Raspberry Pi Foundation has put a lot of work into their software stack. You need only look at a few of the Allwinnner-based Pi clones for the best evidence of this, but the Pi Foundation’s dedication to a clean and smooth software setup can also be found in Noobs, their support for the Pi Hardware, and to a more limited extent, their open source GPU driver offerings.

Now the Pi Foundation is doing something a bit weird. They’re offering their default Raspberry Pi installation for the Mac and PC. Instead of Flashing an SD card, you can burn a DVD and try out the latest the Pi ecosystem has to offer.

A few months ago, PIXEL became default distribution for the Raspberry Pi. This very lightweight distribution is effectively the Knoppix of 2016 – it doesn’t take up a lot of resources, it provides enough software to do basic productivity tasks, and it’s easy to use.

Now PIXEL is available as a live CD for anything that has i386 written somewhere under the hood. The PC/Mac distribution is the same as the Pi version; Minecraft and Wolfram Mathematica aren’t included due to licensing constraints. Other than that, this is the full Pi experience running on x86 hardware.

One feature that hasn’t been overlooked by a singular decade-old laptop in the Pi Foundation is Pixel’s ability to run on really old hardware. This is, after all, a lightweight distribution for the Raspberry Pi, so you shouldn’t be surprised to see this run on a Pentium II machine. This is great for a school in need of upgrading a lab, but the most interesting thing is that we now have a new standard in Linux live CDs and Flash drives.

Reliably Exploiting Apport In Ubuntu

[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”

Under The (Linux) Hood

We’ve often heard that you don’t need to know how an engine works to drive a car, but you can bet that professional race car drivers know. By analogy, you can build lots of systems with off-the-shelf boards like Raspberry Pis and program that using Python or some other high-level abstraction. The most competent hackers, though, know what’s going on inside that Pi and what Python is doing under the hood down to some low level.

If you’ve been using Linux “under the hood” often means understanding what happens inside the kernel–the heart of the Linux OS that manages and controls everything. It can be a bit daunting; the kernel is simple in concept, but has grown over the years and is now a big chunk of software to approach.

Your first embedded system project probably shouldn’t be a real time 3D gamma ray scanner. A blinking LED is a better start. If you are approaching the kernel, you need a similar entry level project. [Stephen Brennan] has just the project for you: add your own system call to a custom Linux kernel.

Continue reading “Under The (Linux) Hood”