Have you ever thought about all the complexities of a Single Sign On (SSO) implementation? A lot of engineering effort has gone into hardened against cross-site attacks — you wouldn’t want every site you visit to be able to hijack your Google or Facebook account. At the same time, SSO is the useful ability to use your authentication on one service to authenticate with an unrelated site. Does SSO ever compromise that hardening? If mistakes are made, absolutely, as [Zemnmez] discovered while looking at the Apple ID SSO system.
A modern car still drives in the same way as the one you would have bought thirty years ago, it still has a steering wheel and all the other controls. What has changed in the cabin lies mostly beneath the dash, where enough computing power to launch several Moon shots takes care of everything from air-conditioning to entertainment. As you might expect these systems attract the curiosity of security researchers, and through their work we gain an insight into their operation.
[Scott Gayou] has a Subaru, a car that has an all-in-one entertainment system head unit that is typical of what you’d find across a host of manufacturers. His account of jailbreaking it is a lengthy essay and a fascinating read for anyone. He starts with a serial port, then an SSH prompt for a root password, and a bit of searching to find it was made by Harman and that it runs the closed-source realtime OS QNX. From there he finds an official Subaru update, from which he can slowly peel away the layers and deduce the security mechanism. The write-up lays bare his techniques, for example at one point isolating the ARM assembler for a particular function and transplanting it bodily into his own code for investigation.
Eventually he could penetrate the filesystem of the update, and from there he could find that while the root user had a password there were two other accounts that while heavily locked down, had none. The discovery came that files on USB drives plugged into the system were given user-level execute permissions, at which point under the locked-down user he could execute arbitrary code from USB drives. He could then create and modify copies of the device’s filesystem which he could flash onto it, and thus place a modified password validation function into it and gain root access.
Some Hackaday readers will be accomplished in security work such as this, but many of us are hardware specialists for whom it remains something of a dark art. A comprehensive and accessible write-up such as this one is therefore invaluable, because it gives us an insight into the techniques used and perhaps more importantly, into some of the security pitfalls a hardware engineer might unwittingly introduce into their creations.
QNX is a real-time operating system with a long history of appearances in industrial and automotive applications. Readers with long memories may recall their demo floppies from the 1990s which packed a fully functional GUI, Internet connectivity, and modern (for the time) web browser onto a single 1.44Mb floppy disk. We’ve talked about it in the past in a little detail, as when someone made a desktop OS using it.
QNX has a long checkered history as an embedded operating system. QNX was always famous for being a real time operating system with a microkernel architecture. That is, kernel functions run as a set of coordinated tasks instead of as a single piece of code. A recent release of QNX 7 (see video, below) allows it to run on 64-bit desktop computers and [elahav] decided to tackle turning this embedded RTOS into a desktop operating system.
That might sound far-fetched, but QNX is a POSIX-compliant system and has all the features you’d expect in a system like Linux or BSD. It just isn’t aimed at the desktop market and therefore doesn’t have a lot of tools for running the desktop. QNX isn’t the kind of RTOS you’ll find on an Arduino. It is more common in things like automobile systems (for example, it runs General Motor’s OnStar system).
He started with a mini ITX board and installed QNX. Usually, you develop for an embedded system on a workstation and then just ship the code over to the target system, but [elahav] took the time to get a build system working on the target. There was one problem. The built-in vi editor was primitive by modern standards. He is usually an emacs user, but even vim would be better than the “stock” vi. While an emacs port would be possible, it would also require porting over a lot of libraries, so his first project was to get the vim source code to compile.
Turned out not to be as easy as he had hoped. The build system expected certain GNU tools that didn’t exist yet (although standard versions of the tools, like grep, did exist). So he had to figure out how to cross compile vim. In retrospect, [elahav] decided he should have just ported the GNU tools first. He did have to remove some old code from vim that was aimed at an older version of QNX.