[workerbee]

Here are 2 links to security papers from Angelo Laub, presented at the 21st Chaos Communication Congress, that I found interesting.
Angelo's conclusion: �Despite all these vulnerabilities, Mac OS X is still much more secure than Windows, because in Windows you are practically always root.�

[yukon]

Augh, I don't want to look through presentation slides....3 points per page, a couple seconds changing each page on my old machine, not for me.

Are these insecurities real? I haven't heard of them anywhere else. Is the paper prescriptive (does it tell me how to fix things)? That conclusion of his is somewhat lame, you don't practically run root all the time in Windows (are you running as administrator in OS X?), but though some people say Windows is actually quite secure, it remains a security nightmare.

Ahh, I'll download it. Hopefully it doesn't talk about single user mode or something.

edit: it was pretty lame. "Disguised Executables" is a good example of that. System Prefs was useless (check the box in "Security" te require passwords, mine was already checked). You need administrator rights to write to the /library/StartupItems unless it's created with the wrong permissions, yay. if you have root access, you can find your password in the swap file, meh. Service allows access when turned on, meh, any user can fill the drive with crap, it would be nice to see disk quotas though. Code injecting, a known problem, but a number of companies/groups now rely on this as their business model, I say Apple should break them now but perhaps it isn't as simple as that.

[mcsjgs]

Originally posted by yukon:
Code injecting, a known problem, but a number of companies/groups now rely on this as their business model, I say Apple should break them now but perhaps it isn't as simple as that.

Could you elaborate on this a bit. I don't mean name names, but the concept? Thanks.

[TETENAL]

The concept is "Haxies".

[msuper69]

Haxies = bad.

[Millennium]

From the first paper:

• System Preferences - Easily fixable with one quick permissions change. This permissions change should be the default, however, so he does have a valid point as far as this one goes. The fix is trivial, and there is no excuse for Apple not to have done it.
• Bad Installers and Root Permissions - Another valid point, and another trivial fix that Apple should be doing anyway: create the /Library/StartupItems folder by default, and give it proper permissions.
• Clear Text Passwords in Swap File - Another valid point. This one's not so simple to fix, but as he notes, Apple has fixed it in Tiger. I have not yet tried the fix mentioned for Panther, but I don't like the bit about destabilizing the system: this is one that Apple should fix as far back as 10.2.8. That said, now we're getting into tougher stuff, because this one actually requires nontrivial code changes.
• Personal Filesharing Denial of Service - Again, a real possibility for trouble. He provides a band-aid fix by disabling the Guest user, but it would be better to put a size quota on the drop box. Not trivial, but still no need for major code changes.
• Mach Injection - A very real possibility for trouble. Not quite as bad as ActiveX, since the code cannot be automatically made to run over a network, but it makes most kinds of spyware very possible. This said, a fix will not only be very difficult, but it will break all known Haxies at such a fundamental level that they may be impossible to rebuild. Whether this is any great loss is left as an exercise for the reader. For that matter, this may require major code changes in order to truly fix properly.
  
  An alternate solution might be doable if Apple were to introduce something like the POSIX Capabilities draft standard, and extend it with a special capability listing so that only certain users/apps would be able to use Mach injection. Extending this standard is no big deal; the standard was never finished and widely regarded as incomplete, and so every OS which implements it has had to extend it in some way or another. However, this particular capability would need to be very strictly monitored and controlled.
• Disguised Executables - Known, but again, not terribly easy to fix. This might be another case where POSIX-esque capabilities might be a good idea, such that before any given app runs its code for the first time it must be given permission to do so from an admin.

In short: the first paper really does present six very real problems, though I was shocked to see a proof-of-concept worm already out there. Fortunately, three of them are easily plugged, and one of the remaining three has a fix coming soon.

The other two problems, however, are going to be extremely difficult to fix, and the best solution may require implementing a major new feature (the POSIX-esque capabilities I mentioned). That would have to wait until 10.5 at the absolute least, and until it happens we're vulnerable.

By the way, it's worth noting that Windows actually has a pretty good capabilities model, but it's configured so badly by default that it's worse than useless: it lulls Windows aficionados into a false sense of security.

The second paper goes into all of these vulnerabilities in more detail, so I won't discuss them again. It lists two other vulnerabilities, however:

• Open Firmware and Firewire - I list these together because Open Firmware isn't listed so much as a security issue as a discussion of how to fix the FireWire hole. This could be considered an issue, but it's worth noting that this one requires physical access to the machine. Still, a preference to disable FireWire DMA without setting an OF password would be nice. Fixing the OF password mechanism so that firmware updates don't mangle it would also be a Good Thing, but this may well require not just code but hardware changes.
• Single User Mode - This one is pretty lame as things go, since it requires physical access. Still, it brings up the interesting point that we're dealing with a chicken/egg solution: if you set SUM to require authentication, you must enable root login, and this is a Bad Thing too. Which is the lesser evil? I don't claim to know.

In short, the second paper is both better and worse than the presentation: it covers real issues in better detail, but also goes into some relative non-issues.

[mcsjgs]

I asked a question, and I got an answer. Ain't MacNN great? Thanks a lot. You should publish that (and I guess you just did).

Edited: One thing he did not discuss is intrusive program alert or window pop-ups during user id and password typing online resulting in clear text transmission. Does anyone know if this is or has been fixed?

[Millennium]

One thing I forgot to mention: the closed-source status of Admin.framework. It's true that this could be a problem, given that closed source can't be examined. It could, however, be resolved without Open-Sourcing the framework through a formal security audit, preferably by an independent firm. However Apple chooses to resolve this issue, it should be done.

[Chuckit]

Originally posted by TETENAL:
The concept is "Haxies".

The concept goes beyond haxies. Besides APE, there are many apps that use code injection (via mach_inject) that you might not even suspect � CodeTek's Virtual Desktop, Desktop Manager, QuickKeys, (I think) Suitcase.