Go Back   MacRumors Forums > Apple Applications > Mac Applications and Mac App Store

Reply
 
Thread Tools Search this Thread Display Modes
Old Mar 8, 2013, 07:53 AM   #1
phillipduran
macrumors 6502a
 
phillipduran's Avatar
 
Join Date: Apr 2008
Location: Iowa
Safari - Last Man Standing

Way to go Safari! At PWN2OWN 2013, the only browser to make it past day one without being hacked is Safari!

Although it seems like they just might be scared to take it on.

http://nakedsecurity.sophos.com/2013...ed-on-day-one/
__________________
That's "Geniuses," not Genii, genius.
To err, is PC.
phillipduran is online now   0 Reply With Quote
Old Mar 8, 2013, 08:05 AM   #2
Jessica Lares
macrumors 604
 
Jessica Lares's Avatar
 
Join Date: Oct 2009
Location: Near Dallas, Texas, USA
I'm surprised, considering how many times Safari crashes on me, and the fact tat it eats up my memory like crazy.
__________________
Have You Hugged Your Mac Today?
Daily Expressions | iMac G4 | Late 2011 13" MacBook Pro | iPod Nano (7G) | iPad Mini | iPod Touch (5G) | iPhone 5S
Jessica Lares is offline   0 Reply With Quote
Old Mar 8, 2013, 08:15 AM   #3
br3nt
macrumors member
 
Join Date: Jul 2012
Quote:
Originally Posted by phillipduran View Post
Way to go Safari! At PWN2OWN 2013, the only browser to make it past day one without being hacked is Safari!

Although it seems like they just might be scared to take it on.

http://nakedsecurity.sophos.com/2013...ed-on-day-one/
I'm careful not to draw any conclusions just yet... Security by obscurity isn't all that good
__________________
......
.....

Please quote me if responding to something I said!
.. MBPr (mid 2012) 2.3 Ghz, 256 SSD & 16 GB RAM
br3nt is offline   0 Reply With Quote
Old Mar 8, 2013, 11:49 AM   #4
jackgreenfield
macrumors newbie
 
Join Date: Mar 2013
My guess - Safari made it to the end because it's so S L O W that the hackers didn't bother messing with it.

I was a Safari user from day 1 and loved it, but I switched to Chrome months ago. Sorry to say, but Safari is a turd.
jackgreenfield is offline   0 Reply With Quote
Old Mar 8, 2013, 12:00 PM   #5
phoenixsan
macrumors 65816
 
phoenixsan's Avatar
 
Join Date: Oct 2012
At least.....

some nice to say/know about Safari...


__________________
Mac Pro 2012 3.06 Westmere version, 12 Core 64 GB RAM, 4 TB , iPhone 5 (black), Moto G 8 GB (black)
phoenixsan is offline   0 Reply With Quote
Old Mar 8, 2013, 12:14 PM   #6
z06gal
macrumors 6502
 
Join Date: Aug 2011
I have been running the Webkit daily build and it is outstanding for me. Very nice
z06gal is offline   0 Reply With Quote
Old Mar 8, 2013, 02:54 PM   #7
munkery
macrumors 68020
 
munkery's Avatar
 
Join Date: Dec 2006
Pwn2own started as a Mac hacking contest and hacking Safari used to be the pinnacle event of the contest.

Headlines artificially made Macs out to be the easiest by saying Macs hacked first but the machines were hacked on a schedule with Macs being first on the schedule. The competition wasn't done head to head.

Also, companies, such as Microsoft, with a vested interest in the results of the competition sponsor the event. This introduces bias in the presentation of the contest results. Bias influenced by a funding source is a common bias in all research.

Macs, due to a Unix foundation, have always been more resistant to hacking because Macs don't have structured exception handling (SEH), which Windows does include. SEH allows an attacker to remotely execute code by overwriting the exception instruction and generating an exception (crash). Abusing SEH is much easier than having to create an instability in the process by triggering a vulnerability and overwriting the return address to achieve code execution all without causing an exception.

Historically, most malware that uses these types of exploits in the wild targets abusing SEH because it requires less skill. SEH also provides second vector if overwriting the return address isn't successful so it is easier to produce more reliable exploits for Windows.

Mac market share is rising so the motivation to attack Safari should have increased yet no one compromised Safari. No one compromised Safari running on Lion last year.

The reason for this is that no researcher has demonstrated a method to defeat the runtime security mitigations in Lion and ML since the introduction of position independent executables, which Windows doesn't yet include.

So, these types of exploits no longer seem to be an issue for Macs due to its Unix foundation and more recent runtime security mitigations.

But, Macs aren't completely immune from all attacks. Java applets are only protected by the Java sandbox which is independent of the protections provided by OS X. Luckily, the default security setting of Java have been increased and Apple is diligent to blacklist vulnerable versions of Java via XProtect, which is included in OS X, when security threats arise.

Also, the robust discretionary access controls in OS X mitigate the usefulness of Java attacks at least in mainstream malware, such as malware that targets protected data entry to steal banking credentials, so the typical consumer isn't at risk. These types of exploits against Macs only target specific individuals who work for companies that have valuable intellectual property.
munkery is offline   1 Reply With Quote
Old Mar 8, 2013, 03:08 PM   #8
Shrink
macrumors Demi-God
 
Shrink's Avatar
 
Join Date: Feb 2011
Location: New England, USA
Quote:
Originally Posted by jackgreenfield View Post
My guess - Safari made it to the end because it's so S L O W that the hackers didn't bother messing with it.

I was a Safari user from day 1 and loved it, but I switched to Chrome months ago. Sorry to say, but Safari is a turd.
As a long term turd user...it is stable, never crashes for me, and does the job I want it to do.

If this makes me an unsophisticated, easy to please moron...I revel in my stupidity.
__________________
Two things are infinite, the universe and human stupidity; and I'm not sure about the universe. -- Albert Einstein
Shrink is offline   2 Reply With Quote
Old Mar 8, 2013, 03:12 PM   #9
spyguy10709
macrumors 6502a
 
Join Date: Apr 2010
Location: One Infinite Loop, Cupertino CA
Quote:
Originally Posted by jackgreenfield View Post
My guess - Safari made it to the end because it's so S L O W that the hackers didn't bother messing with it.

I was a Safari user from day 1 and loved it, but I switched to Chrome months ago. Sorry to say, but Safari is a turd.
Chrome is safari (webkit) with a ****** JS accelerator. Anything you see in chrome is a placebo, it's a proven fact. It has a lower FPS rate in rendering, it executes code slower (saving for V8 optimized fake-world tests) and is all around inferior to safari.

If you like Chrome because of its features, that's legitimate, but not because of speed.
__________________
Last edited by spyguy10709; Tomorrow at 07:10 AM.
spyguy10709 is offline   1 Reply With Quote
Old Mar 8, 2013, 03:12 PM   #10
cal6n
macrumors 68000
 
cal6n's Avatar
 
Join Date: Jul 2004
Location: Brighton, UK
... and as far as the tech-press reporting Safari's outstanding performance in this respect, the silence has been deafening.

I can't say I'm surprised, though.
__________________
Is your internet experience tainted by trolls, shills, bigots & fools?
Select "User CP" > "Edit Ignore List" > Add [username] to Your Ignore List > Save List
Every little helps.
cal6n is offline   1 Reply With Quote
Old Mar 8, 2013, 03:28 PM   #11
elberto1
macrumors newbie
 
Join Date: Jul 2012
Quote:
Originally Posted by jackgreenfield View Post
My guess - Safari made it to the end because it's so S L O W that the hackers didn't bother messing with it.

I was a Safari user from day 1 and loved it, but I switched to Chrome months ago. Sorry to say, but Safari is a turd.
Ummm. When's the last time you tried Safari? Didn't you know that it's snappier now?
elberto1 is offline   1 Reply With Quote
Old Mar 9, 2013, 05:24 AM   #12
Spikeywan
macrumors 6502
 
Join Date: Dec 2012
I'm a very new user, and love Safari. I am running the WebKit, though.

Is there a decent portable version for Windows, so I can use it at work?
__________________
iPhone 3GS, 8 Gb.
iPod Touch, Retina, 64 Gb.
iPad, Retina, 64 Gb.
MacBook Pro, Retina, 2.3 GHz i7 Haswell, 16 Gb RAM, 512 Gb Flash, Mavericks.
Spikeywan is offline   0 Reply With Quote
Old Mar 10, 2013, 06:54 PM   #13
munkery
macrumors 68020
 
munkery's Avatar
 
Join Date: Dec 2006
Here is more information about this topic:

Quote:
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 Mountain Lion has contained only 1 elevation of privilege vulnerability since it was released; obviously, it hasn't been used in malware. http://www.h-online.com/security/new...ml?from-mobi=1

Windows 8 has contained at least 10 elevation of privilege vulnerabilities related to just kernel-mode drivers since being released with at least 2 of those vulnerabilities being remote system level access (root) vulnerabilities, which are the most critical type of vulnerability. https://cve.mitre.org/cgi-bin/cvekey...=8+kernel-mode

Windows 7 alone has many more privilege escalation vulnerabilities than all the versions of Mac OS X combined.

The following link shows the number of privilege escalation vulnerabilities in Windows 7 related to just kernel-mode drivers:

https://cve.mitre.org/cgi-bin/cvekey...=kernel-mode+7

More information about privilege escalation in Windows 7:

http://www.exploit-db.com/bypassing-...vista7-mirror/ -> guide to develop exploits to bypass UAC by manipulating registry entries for kernel mode driver vulnerabilities.

https://media.blackhat.com/bh-dc-11/...nelpool-wp.pdf -> more complete documentation about Windows kernel exploitation.

http://mista.nu/research/mandt-win32k-paper.pdf -> more complete documentation about alternative methods to exploit the Windows kernel.

http://threatpost.com/en_us/blogs/td...net-bug-120710 -> 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.

http://secunia.com/gfx/pdf/DEP_ASLR_2010_paper.pdf -> article overviewing the issues with ASLR and DEP implementation in Windows.

Also, methods have been found to bypass ASLR in Windows 7.

http://vreugdenhilresearch.nl/Pwn2Ow...tExplorer8.pdf -> article describing bypassing ASLR in Windows 7.

Mac OS X has full ASLR implemented on par with Linux. This includes ASLR with position independent executables (PIE). DLLs in Windows have to be pre-mapped at fixed addresses to avoid conflicts so full PIE is not possible with ASLR in Windows.

Using Linux distros with similar runtime security mitigations as Lion for a model, client-side exploitation is incredibly difficult without some pre-established local access. Of course, this is self defeating if the goal of the exploitation is to achieve that local access in the first place.

See the paper linked below about bypassing the runtime security mitigations in Linux for more details.

http://www.blackhat.com/presentation...slr-slides.pdf

The author only manages to do so while already having local access to the OS.

3) Mac OS X Lion has DEP on stack and heap for both 64-bit and 32-bit processes. Third party software that is 32-bit may lack this feature until recompiled in Xcode 4 within Lion. Not much software for OS X is still 32-bit.

But, not all software in Windows uses DEP; this includes 64-bit software. See first 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.

http://www.blackhat.com/presentation...rman-paper.pdf -> 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. Both mandatorily exposed services (mDNSresponder, netbios...) and many client-side apps (Safari, Preview, TextEdit…) are sandboxed in Lion.

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.

http://www.exploit-db.com/download_pdf/16031 -> article about Mac sandbox.

http://msdn.microsoft.com/en-us/libr...(v=VS.85).aspx -> MS documentation about MIC.

https://media.blackhat.com/bh-eu-11/...xes-Slides.pdf -> researchers have found the MIC in IE is not a security boundary.

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.

As of OS X Lion, the XPC service has also been added to implement MAC (see #5) on IPC in OS X. (http://developer.apple.com/library/m...CServices.html)

7) Security benefits of a UNIX foundation

Not all software vulnerabilities are exploitable. Vulnerabilities that are not exploitable only allow a denial of service condition upon being triggered. Exploitable vulnerabilities allow code execution when triggered.

There are two methods to achieve code execution in relation to buffer overflows:

1) RET overwrite -> control return address of instruction pointer

2) SEH (structured exception handler) overwrite -> control content of handler that will be executed upon an exception

To clarify:

Quote:
While typical stack-based buffer overflows work by overwriting the return address in the stack, SEH overwrites work by overwriting the handler attribute of an exception registration record that has been stored on the stack. Unlike overwriting the return address, where control is gained immediately upon return from the function, an SEH overwrite does not actually gain code execution until after an exception has been generated. The exception is necessary in order to cause the exception dispatcher to call the overwritten handler.
Basically, SEH overwrites provide a second method to exploit a vulnerability in the event that a RET overwrite is unsuccessful or not exploitable. Obviously, more vectors being available to facilitate exploiting a vulnerability increases the number of vulnerabilities that are exploitable. SEH overwrites reduce the number of vulnerabilities that only produce a denial of service condition.

Mitigations have been developed to prevent SEH overwrites. These include SafeSEH and SEHOP. Methods are known that allow bypassing both mitigations.

SafeSEH is bypassed if only one component of the program doesn't implement this mitigation; it is common that not all components implement SafeSEH.

SEHOP is bypassed if ASLR is compromised via a memory disclosure vulnerability.

So, what does this have to do with the security benefits of a UNIX foundation?

UNIX and UNIX-like operating systems, such as Mac OS X and Linux, don't have structured exception handling. So, SEH overwrites, as a vector to increase the number of exploitable vulnerabilities, doesn't exist in these operating systems. The signalling system used in these operating systems isn't liable to this type of manipulation.

SEH overwrites do provide a plausible explanation for more vulnerabilities being exploitable in Windows.

http://www.i-hacked.com/freefiles/Ea...ploit_v1.3.pdf

http://www.sysdream.com/sites/defaul...s/sehop_en.pdf

8) Windows has far more public and/or unpatched vulnerabilities than OS X.

http://m.prnewswire.com/news-release...110606584.html -> article about 18 year old UAC bypass vulnerability.

9) 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 Lion uses a salted SHA512 hash, which is still considered cryptographically secure. It is more robust than the MD4 NTLMv2 hash used to store passwords in Windows 7.

http://www.windowsecurity.com/articl...ord-Part1.html -> article about Windows password hashing.

10) The new runtime security mitigation improvements to be included in Windows 8 have already been defeated.

http://vulnfactory.org/blog/2011/09/...op-mitigation/

Alternative methods to defeat the runtime security mitigations in Windows 8 were also demonstrated at pwn2own 2013.

To put this into perspective, methods to bypass the new runtime security mitigations in Mac OS X Lion and Mountain Lion are not yet available.

11)In regards to recent earlier version of Mac OS X:

The following article relates to varying levels of security mitigations in different Linux distros but it is applicable in revealing that the runtime security mitigations in some earlier versions of Mac OS X prior to Lion were far from inadequate.

http://www.blackhat.com/presentation...slr-slides.pdf

While Mac OS X Leopard/SL lack full ASLR, Windows Vista/7 have stack canaries (aka stack cookies) that are trivial to bypass.

The following link shows the issues with stack canaries in Windows. -> http://www.blackhat.com/presentation...rman-paper.pdf

So:

Windows Vista/7 = NX + ASLR
Mac OS X Leopard/SL = NX + stack cookies

These articles show that NX in combination with stack canaries is more difficult to bypass than a combination of NX and ASLR.

12) Mountain Lion only improves upon the security of Lion.

BTW, Safari on a Mac running Lion was not hacked at pwn2own 2012.

And, Safari on a Mac running Mountain Lion was not hacked at pwn2own 2013.

Last edited by munkery; Mar 15, 2013 at 11:40 AM.
munkery is offline   0 Reply With Quote

Reply
MacRumors Forums > Apple Applications > Mac Applications and Mac App Store

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Similar Threads
thread Thread Starter Forum Replies Last Post
Streaming Standing; Anectdotal woesong Apple TV and Home Theater 0 Mar 8, 2014 03:09 PM
iPad: Who is standing in line? AdonisSMU iPad 14 Nov 1, 2013 03:54 AM
Who's just standing in line? JSMencer iPhone 7 Sep 16, 2012 09:06 AM

Forum Jump

All times are GMT -5. The time now is 08:29 AM.

Mac Rumors | Mac | iPhone | iPhone Game Reviews | iPhone Apps

Mobile Version | Fixed | Fluid | Fluid HD
Copyright 2002-2013, MacRumors.com, LLC