Live data from Hacker News

OS X – Safe, yet horribly insecure

allthatiswrong.wordpress.com

21–30 of 134 posts

Re: OS X – Safe, yet horribly insecure

#21
post #13

So, let's review the actual exploits listed here (since, the author says, it isn't just FUD): ASLR & MacDefender... Hmm... hardly a damning criticism.

I was thinking the same thing. A subheading in the article is “Malware for OS X Increasing.” He does a poor job substantiating that claim, IMHO. I don't want to point fingers at Chicken Little, because I agree with the thesis; Apple needs to be more serious about OS X security.

Well in the years prior there were zero and now there is one. This is an increase of infinity percentage!

Okay, beside the snark it is true, Apple should maintain security bugs better and "File Quarantine" looks to me rather rudimentary: http://support.apple.com/kb/HT3662

But as long as the "Trojan Botnets" he mentions are simple PHP scripts which are distributed years ago by pirating Photoshop and are simply killed by deleting the file and a reboot I personally stay feeling pretty secure.

http://blog.notahat.com/posts/28

Re: OS X – Safe, yet horribly insecure

#22
post #19
post #17

Earlier quoted context omitted.

I want an optional feature which only allows the OS to execute MacAppStore programs. This would be "grandparent proof" and would prevent trivial kinds of social engineering used by MacDefender (which targeted clueless users).

If they did this (even as just an option), then there'd be an uproar about how they're incrementally making os x a completely closed system (a walled garden).

One of Apple's competencies is the ability to ignore such an 'uproar'.

Re: OS X – Safe, yet horribly insecure

#23
post #18

[deleted]

The presence of "tl;dr" at the start of parent might give the reader the idea that parent is a summary of the OP, which it definitely is not.

It is also bad practice to not read the submission and instead just jump into comments. (I admit I'm sometimes guilty by it myself.)

Re: OS X – Safe, yet horribly insecure

#25
post #23

Earlier quoted context omitted.

The presence of "tl;dr" at the start of parent might give the reader the idea that parent is a summary of the OP, which it definitely is not.

It is also bad practice to not read the submission and instead just jump into comments. (I admit I'm sometimes guilty by it myself.)

[deleted]

Re: OS X – Safe, yet horribly insecure

#26

So, let's review the actual exploits listed here (since, the author says, it isn't just FUD): ASLR & MacDefender... Hmm... hardly a damning criticism.

Agreed; follow the link the author offers near the top of the article to Secunia. Of a few common OSes I looked at (Red Hat Enterprise 5, Windows XP Pro, Windows 7, OS X), OS X had the fewest advisories for 2009, 2010, and 2011; most vulnerabilities seemed to be of a more benign nature than other OSes.

Perfect? Probably not, but it's still the OS I'm going to recommend to my mom.

Re: OS X – Safe, yet horribly insecure

#27

> The Unix Design is significantly less granular than that of Windows, not even having a basic ACL. The UNIX design came from a time when security was less of an issue and not taken as seriously as it did, and so does the job adequately. Windows NT (and later OSes) were actually designed with security in mind and this shows. This comparison doesn't even make sense, comparing a decades old UNIX design to a comparative…

Whether ACLs are present or not makes little difference. When a user is logged in, he either has access to do something or he doesn't. Only one line of that ACL really matters, and that's the same on a system with permission control but no ACLs (such as traditional Unix).

If the user is able to escalate his privileges (whether with UAC or sudo, the OS doesn't matter) in order to install malware then he loses.

Re: OS X – Safe, yet horribly insecure

#28
"The Unix Design is significantly less granular than Windows..."

That's why it's more secure. Complexity means you don't know what's going on. Complexity means you will forget something. Complexity means there's more likely to be a way to squeeze through, more likely to be a bug, more likely to be a little thing that is forgotten.

This is also a problem with complex cryptographic APIs, overly complicated things like PKCS11 and X.509, etc. It's curious that security-related systems are among the most complex, since complexity is inherently bad for security.

I call it a lack of "situational awareness."

Re: OS X – Safe, yet horribly insecure

#29
Just as a curiosity: yesterday I watched a talk by Thomas Ptacek at some indie Mac dev conference where he showed, en passant, how some kludges used by Apple produced vulnerabilities in Mac OS X. It’s old, fixed stuff by now, but I was like “WTF?” all the same. Because it’s very stupid stuff from Apple.

Here’s the talk, slides (check slide 11), and related blog post:

http://www.viddler.com/explore/rentzsch/videos/31/

http://www.slideshare.net/tqbf/c42-software-security-present...

http://chargen.matasano.com/chargen/2009/9/24/indie-software...

Re: OS X – Safe, yet horribly insecure

#30
post #27

> The Unix Design is significantly less granular than that of Windows, not even having a basic ACL. The UNIX design came from a time when security was less of an issue and not taken as seriously as it did, and so does the job adequately. Windows NT (and later OSes) were actually designed with security in mind and this shows. This comparison doesn't even make sense, comparing a decades old UNIX design to a comparative…

Whether ACLs are present or not makes little difference. When a user is logged in, he either has access to do something or he doesn't. Only one line of that ACL really matters, and that's the same on a system with permission control but no ACLs (such as traditional Unix). If the user is able to escalate his privileges (whether with UAC or sudo, the OS doesn't matter) in order to install malware then he loses.

I completely agree, I was merely refuting the authors point. Not stating that security does or does not rely on ACL's.
Post reply on HN