Linkstew

While reading this Windows Server 2003 kernel guru Q and A I came across this absolutely fantastic quote:

[M]ost of the time, if the application is following the rules then it will run [on Windows Server 2003]. But I must admit the rules haven't been well publicised.

Heh.

When I was in Bakersfield the other weekend, I installed all the latest security and OS updates on my parents' Macs, bringing them up to OS X 10.2.4. The thing was, they both independently got very confused by this dialog:

That dialog pops up whenever the the program that's trying to access the keychain entry has changed since it was granted permission to access the keychain. This is intended to keep a trojaned program, for example, from getting at the passwords you have stored in your keychain.

However, that both of my parents didn't know what to make of it strikes me as a pretty bad sign. I think the dialog's perfectly clear to someone who understands the keychain, but the dialog will lose someone who doesn't know what's going on at the word "decrypt." I filed feedback suggesting that they improve the usability of this dialog, and you should, too.

And actually, I think the keychain in general is an immensely under-advertised feature. Sure, they plugged it when they first introduced it in OS 9.0, and it's used pretty pervasively in OS X, but they ought to have a little tutorial or something that explains the keychain's security features, and convinces the user to trust the keychain. Sure, the keychain help files are pretty good, but if the user doesn't go to look for them, she'll never see them.

And as long as I'm on the subject of the keychain, one thing I'd like to see in an upcoming release is the ability to iSync my keychain, too. I guess that's not so much a keychain feature as it's an iSync issue, but it's still something I'd love to see.

Today while mucking around in NetInfo on the OS X machine at work, my jaw fell open when I noticed a more problematic local security problem than this nonsense. I immediately started composing my post about this problem in my head, and after mailing myself a few notes, I returned to configuring OS X.

But while searching for something else on google later today, I found that someone had beaten me to the punch, and had already written up this OS X security issue much better than I could have ever hoped to:

In brief, Mac OS X's NetInfo database stores crypted passwords that can be read by anyone with an account on the machine. Once the malicious user has the crypted passwords, all he has to do is sic a brute force cracking program on the hash until it finds a match.

To be fair, there is a way to secure your OS X box while still taking advantage of NetInfo as your primary configuration agent: You just need to make sure that your non-trusted users don't have permission to run tools like NetInfo Manager or nidump.

I've been eagerly reading previews of Mac OS X 10.1, and reading comments in forums by users who "acquired" a copy of a beta build, and I've noticed this really annoying bit of security folk wisdom that has now engrained itself in the mac community. (I'd link to examples, but it's not worth it -- if you read Mac news sites at all, you've seen what I'm talking about)

The story goes something like this: "The new login screen, which optionally displays a list of users on the system, reduces the security of the system by an exponential factor, because instead of having to guess a login and password, a cracker only has to guess a password thanks to this list of user names."

Hooey! For starters, <deadpan>Microsoft is doing the same sort of login welcome screen in Windows XP, and Microsoft knows how to make a secure operating system.<deadpan>

But seriously, this isn't a "gaping security flaw that must be addressed before 10.1 ships," as so many wanna-be security experts like to tell naive readers to make themselves sound smarter in the eyes of untrained Mac users. The first reason is simply that it's a necessarilly optional feature, as it would be inefficient for a computer lab with hundreds or thousands of users to have an list of users. So if you're that worried about it, turn it off, and then nothing I say below applies anyway.

In such a multi-user lab environment is exactly where a list of logins might be a security problem. But in that environment, most would-be attackers will already have an account, and a would be attacker will have one of two targets -- either the system, or another user's private files. Taking the system automatically gets him another user's data, but it's also more likely to be noticed, and will probably be harder. So as far as getting private data (or gaining access to another account as the launching point of another attack, or what have you) -- well, if he's got an account on the system, it's trivially easy for the attacker to find out the names other accounts on the system. Further, if he's after someone's private files, he probably has a specific target in mind, in which case he already knows the target login.

And so the one case in which an attacker might use the login list (aka, the "security hole") to crack a system is when the attacker does not already have an account. And in that case, trying to brute force passwords is not the most effective way of gaining access, mainly because brute forcing passwords will almost certainly be noticed (assuming attentive admins). A determined attacker in a multi-user lab environment is going to be able to get access to an account with a trivial amount of social hacking, because users are dumb.

Admittedly, if users weren't stupid, the social hacking wouldn't procure an account as easilly. But of course, if users weren't stupid, they would have better passwords in the first place, and brute forcing a password would be harder, and the utility of a list of logins would go back down just as quickly as it went up.

Why did I focus so much on the case of the multi-user lab environment? Because to see the list of logins, an attacker will need to physically see the machine. And it's mostly beside the point, but most remote system exploits don't even need to know about any particular user other than root, or otherwise default logins, and so the login-screen serves no utility to a remote-attacker.

So the more subtle reason that the login screen listing account names isn't actually a showstopping security flaw is becuase to see the list of logins, an attacker need to be physically in front of the machine, and once an attacker has got physical access to a machine, the show's over and the monkey's dead.

The GIA ran this story today about the security of Phantasy Star Online. It's a shame that PSO's been tampered with, but it seems like the architecture could have been easilly designed to make this sort of thing impossible. Hopefully they designed it extensibly enough that they'll be able to fix it.

What I found more interesting in the article, though, was the mention of the security measures in place to protect accounts from being stolen. While I respect the desire to protect the time investment of the players, the restriction that a character must be played on the Dreamcast it was created on strikes me as troublesome. What if my Dreamcast dies (as mine seems to be threatening to do)? What if I want to take my VMU to a friends to show off my character? What if my VMU dies? And there are so many possible solutions, it's a shame they didn't implement any of them.

The easiest is to allow the user to select what level of security they want for a newly created character. This way people who will only play from their cushy couch and broadband connection can feel safe, while wanderers will be able to play wherever they land. Still more complex systems could employ something based on RSA key pairs (which would also help prevent server spoofing). They could have even added a controller code pass phrase to a key-pair system (with the option of a zero length pass phrase) to allow even more security. It seems like limiting the security based on the particular Dreamcast is a big waste of the portability of the VMU. Well, I guess that as long as I can back up my character on to another VMU they didn't mess things up too badly.

I know everyone out there desires to write secure code. Someone put together this list of links that will help you write secure code, so go get reading before you write another line.