I am see several comments from folks stating that they are surprise that Apple is taking steps to patch issues ("taking it seriously", etc.). I find that a little strange comment given that Apple is actually rather good about addressing vulnerabilities that others report to them and give them credit (if they reported it to Apple). Granted Apple's general no comment policy until investigated and patched can be a little annoying if you report an issue and would like to know more but that policy doesn't mean that Apple doesn't take security reports seriously.
Just review all of the attribution Apple has given for the many vulnerabilities they have addressed over the years. For example look at the security release announcements for 2006 (mailing list archive).
As a side note a few MOAB issues are centered on group admin writable locations that can be used to take over the system is you have local access (possibly via a remote exploit). It may take Apple a little while to address this type of issue given the possibility of permission changes causing Apple and 3rd party software (installers most likely) to fail for customers. Luckily a few new security related feature will debut in Mac OS X 10.5 that will make this type of attack harder to pull off (us 3rd party developers should adopt them ASAP).
A brief listing...
CoreGraphics CVE-ID: CVE-2006-1444 Available for: Mac OS X v10.4.6, Mac OS X Server v10.4.6 Impact: Characters entered into a secure text field can be read by other applications in the same window session Description: Quartz Event Services provides applications with the ability to observe and alter low-level user input events. Normally, applications cannot intercept events when secure event input is enabled. However, if "Enable access for assistive devices" is on, Quartz Event Services can be used to intercept events even when secure event input is enabled. This update addresses the issue by filtering events when secure event input is enabled. This issue does not affect systems prior to Mac OS X v10.4. Credit to Damien Bobillot for reporting this issue
Keychain CVE-ID: CVE-2006-1446 Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.6, Mac OS X Server v10.4.6 Impact: An application may be able to use Keychain items when the Keychain is locked Description: When a Keychain is locked, it is not possible for applications to access the Keychain items it contains without first requesting that the Keychain be unlocked. However, an application that has obtained a reference to a Keychain item prior to the Keychain being locked may, in certain circumstances, be able to continue using that Keychain item regardless of whether the Keychain is locked or unlocked. This update addresses the issue by rejecting requests to use Keychain items when the Keychain is locked. Credit to Tobias Hahn of HU Berlin for reporting this issue.
GDB CVE-ID: CVE-2006-4146 Available for: Mac OS X v10.4 and later Impact: Opening a maliciously-crafted DWARF binary with GDB may lead to arbitrary code execution Description: GDB, the GNU Debugger, is susceptible to multiple vulnerabilities that may lead to arbitrary code execution when loading maliciously-crafted DWARF binaries. This update addresses the issues by performing additional validation while handling DWARF binaries. Credit to Will Drewry and Tavis Ormandy of the Google Security Team for reporting this issue.
Sorry, but I'm not paying a cent for Bootcamp til they make it work 100%. For a bunch of guys that brag about how much better their product is than Windows, they certainly code their Windows-based stuff poorly. It is in Beta for a reason and with each Beta release they are correcting issues.:)
If you built against the 10.3 SDK and used gcc 3.3 to build your appliction it would have run on 10.3.x (.0 thru.99) and later (I assume you C++ code in it). Heck using 10.4 I can still build application that will run all the way back to 10.2....and they are not " doing the same with 10.5" since they didn't do that with 10.4.
Hate to say this but your post mischaracterizes what you are capable of doing with Apple's developers tools but don't take my word for it...
I have an idea... Apple could port those APIs to a prior version of the operating system... yeah they would take the older version of the operating system and add all these new APIs to it, burn it to a CD/DVD, put it in a box and make it available to customers. That sounds like a plan.
Why would Apple charge for something that is basically akin to GRUB? Sure, they offer you native drivers for their hardware Ok let me know when you have it working and will support customers using it? Surely something less expensive then $29 would win the market... *rolls eyes*
Apple made major releases Mac OS X available relatively often to get newly implemented features out to end customers and developers sooner (a good thing)... in 2001 Mac OS X was a relatively new operating system under going rapid concurrent team development and now that it has matured Apple has stated customers should expect major releases every couple of years as the norm.
Apple will support the current version of Mac OS X and one prior. So in reality customers concerned about the relatively small upgrade fee of $129 (family pack is even a better deal) could skip every other release and hence only purchase an update every 4 years or so (that falls in the Window release time frame and of course the 129 is less then what MS charges). On the time scales of 4 years you also start to get into purchasing new hardware mindset which would get you the latest version of Mac OS X for free.
Apple stated all along the Boot Camp would ship with Mac OS X 10.5 (aka you buy 10.5 you also get Boot Camp). So this left open the question if you would be able to purchase Boot Camp (the final version) for 10.4 or not. This rumors implies that 10.4 users will have the ability to use the release version of Boot Camp... which is a good thing. It was never really likely that Boot Camp would be free for 10.4 users.
1) Apple isn't affected by the APSL in this way. The APSL affects 3rd parties that contribute, use or modify the source that Apple makes available. It doesn't require Apple to make source or changes to source available.
2) Mac OS X is portable. It already runs on x86, x86-64, ppc, and ppc64. It looks like Apple has it running on ARM ISA (not sure exactly which) given statements by Apple.
Exactly which aspects of XNU, IOKit, BSD layer, user-land frameworks, etc. that make up "OS X" are running on the iPhone is unknown (Cocoa has been stated to exist by Apple, which implies a handful of other frameworks also exist). It is also possible that something other then XNU is being used... but I doubt that... much more likely it is has been slimmed down to exactly what the iPhone needs.
For example, the cosmic microwave background radiation that we see right now was emitted about 13.7 billion years ago by matter that has, in the intervening time, condensed into galaxies. Those galaxies are now about 46 billion light-years from us, but at the time the light was emitted, that matter was only about 40 million light-years away from the matter that would eventually become the Earth. See comoving coordinates.
Issue #8 is not an overflow issue (buffer overrun I assume you mean).
#8 involves APE (Unsanity folks could make some changes to help avoid the issue) however IMHO the core of the issue is with file permissions that Apple has defined for various directories under/Library that Apple recommends 3rd parties install software into. That is why I outlined that it is a 3rd party and Apple issue.
Note that this is third party software that all of the bugs seem to be stemming from.
This statement doesn't make sense. The MOAB issues outlined to date have been a combination of Apple and 3rd party issues. See the following break down...
MOAB #1 - Apple issue MOAB #2 - 3rd party issue MOAB #3 - Apple issue MOAB #4 - Apple issue MOAB #5 - Apple issue MOAB #6 - Apple and 3rd party MOAB #7 - 3rd party issue MOAB #8 - Apple and 3rd party MOAB #9 - Apple issue
01:04 Tue, 09 Jan 2007 PST -0800 Anatomy of the Runtime MoAB Patches
Introduction
For the past few days I've been releasing patches for software vulnerabilities in an assortment of Mac OS software. This project was intended to be a technical one, and I've never sat down to explain, in clear terms, how the patches work, what Application Enhancer is, or what the potential risks are in running these patches. I'm also not the first one (not by a long shot) to think of implementing third party patches for unpatched software vulnerabilities, either, and I'd like to discuss those efforts.
Here goes...
Third Party Patches, Past and Present
Generally speaking, a software vulnerability is usually announced in coordination with a vendor-supplied software update. However, there are cases when a vendor patch is not available for a critical software vulnerability, leaving the user with limited options. Relatively recently, the idea of a "third party patch" has emerged; when a vendor patch is not available, a third party can reverse engineer the software in question and produce a temporary bug fix.
This technique has previously been used for both unpatched Windows and Mac OS X vulnerabilities. In 2006, Alexander Sotirov presented "Hotpatching and the Rise of Third-Party Patches" at the Las Vegas Black Hat conference, and is responsible for implementing two patches for unfixed Internet Explorer vulnerabilities. ZERT (Zero-day Emergency Response Team), who is composed of an impressive array of individuals, "work(s) together as a team to release a non-vendor patch when a so-called '0day' (zero-day) exploit appears in the open which poses a serious risk to the public, to the infrastructure of the Internet or both." On the Macintosh, Unsanity released Paranoid Android, a run-time patch for a critical vulnerability in Mac OS X's document handling. I believe the award for the first third party Windows patch for an unfixed vulnerability goes to Ilfak Guilfanov's December 2005 WMF patch. Guilfanov is the author of the excellent IDA Pro disassembler and debugger.
Risks and Benefits of Third Party Patches
A vendor-supplied update is always preferable to a third party patch. Third party patches are created by reverse engineering the vulnerable code, and are subject to limited testing and potential implementation deficiencies -- like the author of the vulnerable software, patch implementors are human, too. It is always possible that a bug in the patch could result in instability, or potentially expose a new exploit scenario.
On the other hand, a third party patch can provide protection against a critical vulnerability before the vendor is able to implement, test, and release a fix. The decision to use a third party patch should be made after a careful assessment of the vulnerability's risks and your own requirements -- it's never unreasonable to wait for an officially provided vendor fix.
Patching (more) Safely with Application Enhancer
The patches we've provided have all been implemented using Unsanity's Application Enhancer, and are "run-time patches" -- the patches insert themselves into applications at runtime, find the vulnerable code, and apply a band-aid. Nearly all of the patches released so far work by wrapping the vulnerable code and providing additional data validation, rejecting data that would otherwise cause the vulnerable code to malfunction (and thus allow the exploit to succeed). There are other options for implementing run-time patches on Mac OS X, including the open source mach_star -- I've previously used mach_star to implement runtime security patches for software on my own Mac. However, for the purposes of providing these fixes, I decided upon Application Enhancer.
Application Enhancer provides a nice, easy to use GUI for installing Applicati
I doubt Apple is going to require ZFS for Time Machine anytime soon. I fully expect HFS+ to continue to be the default file system for Mac OS X for a while (years). I believe ZFS support in Mac OS X is solely for the high-end / server space of the customer spectrum.
Judging from iTunes v5 and later I say you are wrong. Starting with iTunes v5 you can ync Outlook / Outlook Express calendar items and contacts with your iPod.
Insightful?...guessing at exact requirement of a produce that hasn't been announced yet?
If you look at what Apple has done with the iPod you likely can get a more realistic picture of what may exist in this rumored phone. For example the iPod has the ability to display calendar entries and contact information. If you connect your iPod with a Mac Apple provides a way to easily and automatically sync the calendar and contact information contained in iCal and Address Book with your iPod [1]. On Microsoft Windows systems Apple provides a way to easily and automatically sync the calendar and contact information contained in Microsoft Outlook with your iPod.
It is likely Apple would provide similar capabilities (likely better) so that the "iPhone" will reach the largest market possible... of course do expect that the best integration and feature capabilities will likely favor Apple's provided solutions. Yes that is a form of lock-in but it mainly allows Apple to implement robust features since it has better control over all aspects/components of the solution.
[1] It should be noted that other applications can sync their data with the databases used by Address Book and iCal and hence indirectly with iPods and a.Mac account.
Slashdot Mirror
I am see several comments from folks stating that they are surprise that Apple is taking steps to patch issues ("taking it seriously", etc.). I find that a little strange comment given that Apple is actually rather good about addressing vulnerabilities that others report to them and give them credit (if they reported it to Apple). Granted Apple's general no comment policy until investigated and patched can be a little annoying if you report an issue and would like to know more but that policy doesn't mean that Apple doesn't take security reports seriously.
Just review all of the attribution Apple has given for the many vulnerabilities they have addressed over the years. For example look at the security release announcements for 2006 (mailing list archive).
As a side note a few MOAB issues are centered on group admin writable locations that can be used to take over the system is you have local access (possibly via a remote exploit). It may take Apple a little while to address this type of issue given the possibility of permission changes causing Apple and 3rd party software (installers most likely) to fail for customers. Luckily a few new security related feature will debut in Mac OS X 10.5 that will make this type of attack harder to pull off (us 3rd party developers should adopt them ASAP).
A brief listing...
CoreGraphics
CVE-ID: CVE-2006-1444
Available for: Mac OS X v10.4.6, Mac OS X Server v10.4.6
Impact: Characters entered into a secure text field can be read
by other applications in the same window session
Description: Quartz Event Services provides applications with
the ability to observe and alter low-level user input events.
Normally, applications cannot intercept events when secure event
input is enabled. However, if "Enable access for assistive
devices" is on, Quartz Event Services can be used to intercept
events even when secure event input is enabled. This update
addresses the issue by filtering events when secure event input
is enabled. This issue does not affect systems prior to Mac OS X
v10.4. Credit to Damien Bobillot for reporting this issue
Keychain
CVE-ID: CVE-2006-1446
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS
X v10.4.6, Mac OS X Server v10.4.6
Impact: An application may be able to use Keychain items when
the Keychain is locked
Description: When a Keychain is locked, it is not possible for
applications to access the Keychain items it contains without
first requesting that the Keychain be unlocked. However, an
application that has obtained a reference to a Keychain item
prior to the Keychain being locked may, in certain
circumstances, be able to continue using that Keychain item
regardless of whether the Keychain is locked or unlocked. This
update addresses the issue by rejecting requests to use Keychain
items when the Keychain is locked. Credit to Tobias Hahn of HU
Berlin for reporting this issue.
GDB
CVE-ID: CVE-2006-4146
Available for: Mac OS X v10.4 and later
Impact: Opening a maliciously-crafted DWARF binary with GDB may
lead to arbitrary code execution
Description: GDB, the GNU Debugger, is susceptible to multiple
vulnerabilities that may lead to arbitrary code execution when
loading maliciously-crafted DWARF binaries. This update
addresses the issues by performing additional validation while
handling DWARF binaries. Credit to Will Drewry and Tavis Ormandy
of the Google Security Team for reporting this issue.
etc.
Just because it is marketing doesn't make the statement any less funny.
Actually one exists, available in black and white.
Of course it is a funny statement to see coming from Microsoft.
Sorry, but I'm not paying a cent for Bootcamp til they make it work 100%. For a bunch of guys that brag about how much better their product is than Windows, they certainly code their Windows-based stuff poorly. It is in Beta for a reason and with each Beta release they are correcting issues. :)
To be complete...
10.4 -> 10.5 - ~24 months
10.3 -> 10.4 - ~18 months
10.2 -> 10.3 - ~14 months
10.1 -> 10.2 - ~11 months
10.0 -> 10.1 - ~7 months (free upgrade)
oops meant .9 not .99
If you built against the 10.3 SDK and used gcc 3.3 to build your appliction it would have run on 10.3.x (.0 thru .99) and later (I assume you C++ code in it). Heck using 10.4 I can still build application that will run all the way back to 10.2. ...and they are not " doing the same with 10.5" since they didn't do that with 10.4.
Hate to say this but your post mischaracterizes what you are capable of doing with Apple's developers tools but don't take my word for it...
Cross-Development Limitations from Cross-Development Programming Guide
(note the only really problematic area is with building Kernel extensions but even that can be managed with current tools)
I have an idea... Apple could port those APIs to a prior version of the operating system... yeah they would take the older version of the operating system and add all these new APIs to it, burn it to a CD/DVD, put it in a box and make it available to customers. That sounds like a plan.
Why would Apple charge for something that is basically akin to GRUB? Sure, they offer you native drivers for their hardware ... *rolls eyes*
Ok let me know when you have it working and will support customers using it? Surely something less expensive then $29 would win the market
OS updates every 12-18 months
... in 2001 Mac OS X was a relatively new operating system under going rapid concurrent team development and now that it has matured Apple has stated customers should expect major releases every couple of years as the norm.
10.4 -> 10.5 - ~24 months
10.3 -> 10.4 - ~18 months
10.2 -> 10.3 - ~14 months
10.1 -> 10.2 - ~11 months
Notice a trend?
Apple made major releases Mac OS X available relatively often to get newly implemented features out to end customers and developers sooner (a good thing)
Apple will support the current version of Mac OS X and one prior. So in reality customers concerned about the relatively small upgrade fee of $129 (family pack is even a better deal) could skip every other release and hence only purchase an update every 4 years or so (that falls in the Window release time frame and of course the 129 is less then what MS charges). On the time scales of 4 years you also start to get into purchasing new hardware mindset which would get you the latest version of Mac OS X for free.
Apple stated all along the Boot Camp would ship with Mac OS X 10.5 (aka you buy 10.5 you also get Boot Camp). So this left open the question if you would be able to purchase Boot Camp (the final version) for 10.4 or not. This rumors implies that 10.4 users will have the ability to use the release version of Boot Camp... which is a good thing. It was never really likely that Boot Camp would be free for 10.4 users.
Ah so you agree about using a dongle.... since both my bank and broker use dongles to control access to my online accounts.
WebKit is much more then just KHTML, etc.
They are the copyright holder... those terms don't apply to them.
Exactly. NeXT folks at Apple have a lot of experience with writing software and operating systems that can be compiled for multiple ISAs.
What does Media Access Controll have to do with this?
1) Apple isn't affected by the APSL in this way. The APSL affects 3rd parties that contribute, use or modify the source that Apple makes available. It doesn't require Apple to make source or changes to source available.
2) Mac OS X is portable. It already runs on x86, x86-64, ppc, and ppc64. It looks like Apple has it running on ARM ISA (not sure exactly which) given statements by Apple.
Exactly which aspects of XNU, IOKit, BSD layer, user-land frameworks, etc. that make up "OS X" are running on the iPhone is unknown (Cocoa has been stated to exist by Apple, which implies a handful of other frameworks also exist). It is also possible that something other then XNU is being used... but I doubt that... much more likely it is has been slimmed down to exactly what the iPhone needs.
Issue #8 is not an overflow issue (buffer overrun I assume you mean).
/Library that Apple recommends 3rd parties install software into. That is why I outlined that it is a 3rd party and Apple issue.
#8 involves APE (Unsanity folks could make some changes to help avoid the issue) however IMHO the core of the issue is with file permissions that Apple has defined for various directories under
This statement doesn't make sense. The MOAB issues outlined to date have been a combination of Apple and 3rd party issues. See the following break down...
MOAB #1 - Apple issue
MOAB #2 - 3rd party issue
MOAB #3 - Apple issue
MOAB #4 - Apple issue
MOAB #5 - Apple issue
MOAB #6 - Apple and 3rd party
MOAB #7 - 3rd party issue
MOAB #8 - Apple and 3rd party
MOAB #9 - Apple issue
From Anatomy of the Runtime MoAB Patches
...
------
01:04 Tue, 09 Jan 2007 PST -0800
Anatomy of the Runtime MoAB Patches
Introduction
For the past few days I've been releasing patches for software vulnerabilities in an assortment of Mac OS software. This project was intended to be a technical one, and I've never sat down to explain, in clear terms, how the patches work, what Application Enhancer is, or what the potential risks are in running these patches. I'm also not the first one (not by a long shot) to think of implementing third party patches for unpatched software vulnerabilities, either, and I'd like to discuss those efforts.
Here goes
Third Party Patches, Past and Present
Generally speaking, a software vulnerability is usually announced in coordination with a vendor-supplied software update. However, there are cases when a vendor patch is not available for a critical software vulnerability, leaving the user with limited options. Relatively recently, the idea of a "third party patch" has emerged; when a vendor patch is not available, a third party can reverse engineer the software in question and produce a temporary bug fix.
This technique has previously been used for both unpatched Windows and Mac OS X vulnerabilities. In 2006, Alexander Sotirov presented "Hotpatching and the Rise of Third-Party Patches" at the Las Vegas Black Hat conference, and is responsible for implementing two patches for unfixed Internet Explorer vulnerabilities. ZERT (Zero-day Emergency Response Team), who is composed of an impressive array of individuals, "work(s) together as a team to release a non-vendor patch when a so-called '0day' (zero-day) exploit appears in the open which poses a serious risk to the public, to the infrastructure of the Internet or both." On the Macintosh, Unsanity released Paranoid Android, a run-time patch for a critical vulnerability in Mac OS X's document handling. I believe the award for the first third party Windows patch for an unfixed vulnerability goes to Ilfak Guilfanov's December 2005 WMF patch. Guilfanov is the author of the excellent IDA Pro disassembler and debugger.
Risks and Benefits of Third Party Patches
A vendor-supplied update is always preferable to a third party patch. Third party patches are created by reverse engineering the vulnerable code, and are subject to limited testing and potential implementation deficiencies -- like the author of the vulnerable software, patch implementors are human, too. It is always possible that a bug in the patch could result in instability, or potentially expose a new exploit scenario.
On the other hand, a third party patch can provide protection against a critical vulnerability before the vendor is able to implement, test, and release a fix. The decision to use a third party patch should be made after a careful assessment of the vulnerability's risks and your own requirements -- it's never unreasonable to wait for an officially provided vendor fix.
Patching (more) Safely with Application Enhancer
The patches we've provided have all been implemented using Unsanity's Application Enhancer, and are "run-time patches" -- the patches insert themselves into applications at runtime, find the vulnerable code, and apply a band-aid. Nearly all of the patches released so far work by wrapping the vulnerable code and providing additional data validation, rejecting data that would otherwise cause the vulnerable code to malfunction (and thus allow the exploit to succeed). There are other options for implementing run-time patches on Mac OS X, including the open source mach_star -- I've previously used mach_star to implement runtime security patches for software on my own Mac. However, for the purposes of providing these fixes, I decided upon Application Enhancer.
Application Enhancer provides a nice, easy to use GUI for installing Applicati
What you say is true for some definition of "java runtime environment".
In general however Apple attempts to use as much of Sun's implementation as possible so very often issues in Sun's JVM can be present in Apple's.
I doubt Apple is going to require ZFS for Time Machine anytime soon. I fully expect HFS+ to continue to be the default file system for Mac OS X for a while (years). I believe ZFS support in Mac OS X is solely for the high-end / server space of the customer spectrum.
Judging from iTunes v5 and later I say you are wrong. Starting with iTunes v5 you can ync Outlook / Outlook Express calendar items and contacts with your iPod.
Insightful? ...guessing at exact requirement of a produce that hasn't been announced yet?
.Mac account.
If you look at what Apple has done with the iPod you likely can get a more realistic picture of what may exist in this rumored phone. For example the iPod has the ability to display calendar entries and contact information. If you connect your iPod with a Mac Apple provides a way to easily and automatically sync the calendar and contact information contained in iCal and Address Book with your iPod [1]. On Microsoft Windows systems Apple provides a way to easily and automatically sync the calendar and contact information contained in Microsoft Outlook with your iPod.
It is likely Apple would provide similar capabilities (likely better) so that the "iPhone" will reach the largest market possible... of course do expect that the best integration and feature capabilities will likely favor Apple's provided solutions. Yes that is a form of lock-in but it mainly allows Apple to implement robust features since it has better control over all aspects/components of the solution.
[1] It should be noted that other applications can sync their data with the databases used by Address Book and iCal and hence indirectly with iPods and a