Mac OS X, Horriby Insecure?

Discussion in 'macOS' started by wesleyh, Jun 25, 2011.

  1. wesleyh macrumors 6502

    Mar 23, 2007
  2. GGJstudios macrumors Westmere


    May 16, 2008
    Without reading the entire article, the quote, "It isn’t like no OS X viruses exist.", links to a site which doesn't list a single Mac OS X virus, since it is quite true that none exist in the wild. Only trojans exist that run on OS X. Such quotes in articles like these reduce the writer's credibility and gives me the impression that they're trying to build a case against Mac OS X, rather than simply reporting facts.

    There is no question that no OS, including Mac OS X, is 100% secure or immune to malware. The fact that articles keep popping up like this really makes me think there's an anti-Apple campaign, rather than balanced, factual reporting of unbiased facts.
  3. miles01110 macrumors Core


    Jul 24, 2006
    The Ivory Tower (I'm not coming down)
    The average Mac user is just as vulnerable to attack as the average Windows user. Technical exploits aren't in fashion anymore.
  4. maflynn Moderator


    Staff Member

    May 3, 2009
    I think its more of an urban myth that Macs are invulnerable to viruses, to which people further exacerbate the situation by confusing viruses and malware.
  5. munkery, Jun 25, 2011
    Last edited: Jul 12, 2011

    munkery macrumors 68020


    Dec 18, 2006

    1) Until Vista, the admin account in Windows did not implement DAC in a way to prevent malware by default. Also, Windows has a far greater number of privilege escalation vulnerabilities that allow bypassing DAC restrictions even if DAC is enabled in Windows.

    Much of the ability to turn these vulnerabilities into exploits is due to the insecurity of the Windows registry. Also, more easily being able to link remote exploits to local privilege escalation exploits in Windows is due to the Windows registry.

    Mac OS X does not use an exposed monolithic structure, such as the Windows registry, to store system settings. Also, exposed configuration files in OS X do not exert as much influence over associated processes as the registry does in Windows.

    Mac OS X Snow Leopard has contained only 2 elevation of privilege vulnerabilities since it was released; obviously, neither of these were used in malware. -> guide to develop exploits to bypass UAC by manipulating registry entries for kernel mode driver vulnerabilities. -> more complete documentation about Windows kernel exploitation. -> list of incidences of kernel mode driver vulnerabilities. -> article about the TDL-4 botnet which uses a UAC bypass exploit when infecting Windows 7.

    2) Windows has the potential to have full ASLR but most software does not fully implement the feature. Most software in Windows has some DLLs (dynamic link libraries = Windows equivalent to dyld) which are not randomized.

    Mac OS X is criticized for only having partial ASLR but the ASLR in OS X is equivalent to the actual implementation of ASLR in Windows. -> article overviewing the issues with ASLR and DEP implementation in Windows.

    Also, methods have been found to bypass ASLR in Windows 7. -> article describing bypassing ASLR in Windows 7.

    3) Mac OS X SL does not have DEP on heap for 32-bit processes. But, most of OS X is 64-bit. Also, 32-bit implementations of security mitigations, such as ASLR and DEP, are defeated using brute force in all OSs so do not provide much protection anyway.

    Also, not all software in Windows uses DEP; this includes 64-bit software. See article linked in #2.

    4) Mac OS X implements canaries using ProPolice, the same mitigation used in Linux. ProPolice is considered the most thorough implementation of canaries. It is known to be much more effective than the similar system used in Windows. -> article comparing ProPolice to stack canary implementation in Windows.

    5) Application sandboxing and mandatory access controls (MAC) in OS X are the same thing. More specifically, applications are sandboxed in OS X via MAC. Mac OS X uses the TrustedBSD MAC framework, which is a derivative of MAC from SE-Linux. This system is mandatory because it does not rely on inherited permissions. It has been implemented in OS X since Leopard but only on mandatorily exposed services, such as mDSNresponder.

    Windows does not have MAC. The system that provides sandboxing in Windows, called mandatory integrity controls (MIC), does not function like MAC because it is not actually mandatory. MIC functions based on inherited permissions so it is essentially an extension of DAC (see #1). If UAC is set with less restrictions or disabled in Windows, then MIC has less restrictions or is disabled. -> article about Mac sandbox. -> MS documentation about MIC.

    6) In relation to DAC and interprocess sandboxing in OS X in comparison with some functionality of MIC in Windows 7 (see #5), the XNU kernel used in OS X has always had more secure interprocess communication (IPC) since the initial release of OS X.

    Mac OS X, via being based on Mach and BSD (UNIX foundation), facilitates IPC using mach messages secured using port rights that implement a measure of access controls on that communication. These access controls applied to IPC make it more difficult to migrate injected code from one process to another.

    Adding difficulty to transporting injected code across processes reduces the likelihood of linking remote exploits to local exploits to achieve system level access.

    7) Scanning a Mac without a firewall using NMAP provides less information than scanning Windows with a firewall.

    The following relates to firewalls in general. Packet filters, especially those with stateful packet inspection, are effective but require more advanced knowledge to use to their full potential. Application firewalls, such as those in most personal firewall software due to being easy to use, are fairly ineffective against malware that corrupts processes running in memory, such as browser exploits. Sandboxing represents the newest and most effective form of firewalling an OS. See the content of #5 for more information.

    8) No antivirus software is 100% effective so it is no surprise that XProtect is not 100% effective. A better default implementation of DAC and far fewer privilege escalation vulnerabilities have negated much of the need for AV software in Mac OS X.

    More concealed and effective malware requires bypassing DAC to gain system level access. Doing so is far more difficult in OS X. PWN2OWN does not demonstrate exploitation to system level. See #1 for more information about the importance of DAC.

    9) Windows has far more public and/or un-patched vulnerabilities than OS X. -> list of public 0days. -> another list of public 0days. -> article about 18 year old UAC bypass vulnerability.

    10) Password handling in OS X is much more secure than Windows.

    The default account created in Windows does not require a password. The protected storage API in Windows incorporates the users password into the encryption key for items located in protected storage. If no password is set, then the encryption algorithm used is not as strong. Also, no access controls are applied to items within protected storage.

    In Mac OS X, the system prompts the user to define a password at setup. This password is incorporated into the encryption keys for items stored in keychain. Access controls are implemented for items within keychain.

    Also, Mac OS X uses a salted SHA1 hash, which is still considered cryptographically secure. It is more robust than the MD4 NTLMv2 hash used in Windows 7. -> article about Windows password hashing.

    11) Mac OS X implements two user space security mechanisms that prevent keyloggers and other malware from logging security sensitive passwords.

    The first security mechanism is called EnableSecureEventInput; this prevents keyboard events related to security sensitive logins being logged when exiting kernel space on the way to the application with keyboard focus.

    The other security mechanism is called NSSecureTextField which prevents password from being viewed or captured in the user interface; this is standard password masking.

    Native Cocoa apps, such as Safari, use NSSecureTextField by default. NSSecureTextField is set up to enable EnableSecureEventInput by default when it is used. So, the default native cocoa apps is OS X use these user space security mechanisms.

    Windows has similar protections in place but these security mechanisms are only effective if DAC is used by default and is not bypassed by malware. These conditions can not be as reliably assumed in Windows. See #1 and #6 for more information about issues with DAC in Windows.

    12) Authentication is more secure in OS X as well. The default account created in Windows does not require password authentication for UAC prompts. This leaves authentication more open to hijacking via spoofed windows that appear unrelated to UAC because no password is attached to authentication. Authentication requires a password by default in OS X.

    13) The state of exploitation in concerns to Apache/IIS shows that target softness is the more determining factor than market share in relation to incident rates of malware per platform. IIS has lower market share but has more malware than Apache because IIS is the easier target. Malware developers do not ignore any platform.

    Apache market share (~60%) to IIS market share (~22%)

    5 (Apache) : 28 (IIS)

    Windows has more malware than OS X primarily because it is the softer target.

    14) All of the security mitigations in OS X included in this post that could be improved are improved in Mac OS X Lion.

    Some examples are improvements to ASLR and DEP as well as more client-side application sandboxing.

Share This Page