« Open Source: A hackers dream, a vendor's worst nightmare | Main | Vegas plans, ruby. »

Attack the source

The Mac has started to become a "supported" platform at work, so a few months back I put in a request to get my own Mac. If I'm expected to help protect them, I figured I might as well know what I'm getting in to. Late last week and a few hours over the weekend I took some time to get more familiar with my new silver-clad friend.

The Mac was, at least from the network point of view, locked down right out of the box. There were plenty of things for me to do in the UI to tighten the screws. Most of it was obvious and found within minutes of poking around in the preferences. The rest can be had from the bounty that is the Internet. As it turns out, Pete has some of the same information that I used.

In short order I started to get the feeling that something was not quite right. This dirty feeling is one that I've felt before.

I'll explain my uneasiness with a question. What do the following have in common?

The answer may be obvious to some, but it is important to point out that the result of the above actions is that you'll be installing software on your system from a source that is untrusted in one way or another. I look at this particular security-oriented trust issue in a few ways.

Is the host holding the software secured against attack? In far too many cases, I'd say no -- the most popular ssh-agent for the Mac is hosted in a user's home directory at the University of Utrecht. I've worked in a University setting, and I can tell you that while it is one of the most diverse environments, from a security point of view it is a complete nightmare. Picture the worst shared-hosting facility situation that is chock-full of politics and pet projects, add a heaping scoop of financial problems, and you've got an environment that is ripe for hacking. The software hasn't been updated since 2005 and there are no MD5s, so my guess is that modification of that file would probably go unnoticed. Compromise that source and, within hours, you'd have a backdoor on machines that are otherwise fairly secure.

Is there any reason for the source itself to be malicious? I'd love for the answer to be "no", but there is a considerable market in shady business like this. If you are a singular entity distributing software, there are rarely any checks and balances in place to ensure that you play nice. Whats to prevent the person who distributes the software from tacking on other malicious software to the installer, or somehow putting a backdoor in the program itself? Considering the fact that ~90% of Windows users are either using the Administrator account for day-to-day acitivities, or have a user account who has equivalent privileges, I'd say that the chance for profit is quite good. Even if the user isn't running with elevated privileges, the chances that the installer will required them for installation are quite good. This isn't a Windows specific problem either, as much as many people in the security space like to bash it. Something similar can be said for system "administrators" rushing to get a system installed so that the latest whiz-bang Web 2.5 startup can profit. Because of the rush or because of his sloppy practices, he tromps around on his RedHat system as root and then downloads a binary RPM for one of the dozens of pieces of software that RedHat proper doesn't support. If the backdoor doesn't kill him, the lack of pre/post installation scripts or dependency tracking will.

The distribution for many pieces of software that fall outside the realm of "supported" is quite different. In the open source world, if you are an uber paranoid and don't trust the packages that come from Debian (why should you? ;)), the ports from FreeBSd, etc, you can download the source and perform your own checks. The code used to do the installation is an easy read, and if you are so inclined, you can read the source to the software itself and do a 5-minute sanity check. Foolproof? Hell no, but the piece of mind goes a long way. In many other circles, you don't get the source to the installer or the program itself. Instead, it is bundled as a single binary package and its up to you to trust that the stand-alone executable that you just downloaded from a host in the Czech Rebulic isn't going to turn your poor Windows machine into swiss cheese.

When I'm on the dirty streets of Hollywood, I don't put my ATM card into just anything that says "ATM" on it. I don't put my personal information, especially my credit card number of god forbid my SSN, into any website unless it uses SSL from a "trusted" CA and looks reasonably well put together. I don't discuss personal matters when I get a phone call from a number a don't recognize and the voice on the other end identifies itself with simply a name. For the same reasons, I don't install or use software from untrusted sources unless appropriate precautionary measures are taken on my part.

Comments (6)

Pete:

In my experience the mac platform has many issues like this. Just have a look at version tracker most of the packages don't give you md5's / sha1 hashes nor do they check upon installation.

Additionally I don't like their take on clientside issues for example Safari's automatically run trusted extensions. Or the fact that the firewall doesn't block any udp if you're src port is 67 or 5353. *sigh*

First a slightly off topic note: I've always wondered why apple didn't release an ssh-agent that integrates into their keychain.

Second: As for searching for third party apps... you could restrict yourself to software signed by sources that can be verified by a web of people (ideally a web that includes someone you have been able to verify) debian developers have a very large web... so if you download unofffical binaries from them or people they have verified you at least should be able to track down the source of the package (should it later found to be bad).

This wasn't meant to be a Mac specific article, but it simply drummed up thoughts I've had in the past with respect to trusted/untrusted sources. Thats a good note about the source port fixation trick. As others have noted elsewhere, I'm betting that the next Apple remote will be in Rendezvouz or whatever its called nowadays, and I'm sure mdns will pay a part in that.

I've actually found Debian to be among the best when it comes to trusting packages. There is an endless supply of packages for just about every piece of software you could ever imagine needing. They come from a trusted (or at least one that is more trusted than some random .edu site), go through some sort of minimal QA before they are accepted, are seen and used by thousands of people, and can be signed and checksummed if needed. One complaint, though -- no xroach!

In this case I don't think running as Administrator or root really makes a difference. If you download source for the purpose of installing it, the typical install procedure is, "make; sudo make install".

On the subject of distribution package managers, Gentoo makes it easy to fetch the source before compiling it for that five-minute sanity check you talk about above.

When it comes to source-based installations, its the 'sudo make install' of your example that could burn you. I'm a fan of stow for this reason, because you can do the entire build and installation as an unprivileged user, and then the linking into your live directory structure can be done as a privileged user. Not foolproof, but it will defeat many common shenanigans.

Dave:

Hey Jon, awesome to see you got your blog back up and running.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

About

Jon Hart
Name: Jon Hart

Location: Hiding between the smog and the Pacific

Occupation: Security Ninja, Thrill Seeker.

Categories