Slashdot Mirror
Apple Mac OS X Update For 17 Vulnerabilities
BSDetector writes "Apple has released fixes for 17 OSX vulnerabilities, ranging from system takeover to denial-of-service attacks. It was the fifth security update released this year. It also marked the first time this year that an operating system security update from Apple did not patch a vulnerability disclosed by the January Month of Apple Bugs project. Today's update pushed Apple's year-to-date patch total to over 100. More than one of the affected flaws were called 'critical' or 'dangerous'."
Yeah, Slashdot never makes post like this about Microsoft. Certainly this article from two weeks ago has nothing to do with notable Windows security patches.
... it's also about /how/ they are handled. Some might say more-so.
From what I've seen, Apple has been quite responsible with fixing found vulnerabilities: turn around times, etc. More-so than that other guy. So, I can't really complain.
All of the ones you listed involve manipulating code on my computer in ways it was not meant to be run, so sure.
There have been no exploits in any of those categories in the wild. Heck, some of the proof of concept exploits don't even generally work (like the Quicktime exploit, that required I RUN AN EXPLOIT GENERATOR locally and run the generated QT file - still didn't work on any of my Macs!)
"There is more worth loving than we have strength to love." - Brian Jay Stanley
What is it about developing software for Mac OS X that you dislike compared to Linux ?
Are you using Cocoa, Carbon, Java, BSD/POSIX APIs, X Server ?
Are you using X-Code, eclipse, something else ?
I routinely develop software for a variety of Unix systems, and I find Mac OS X just as comfortable and any other Unix. I can't think of many developer tools for Linux that is not also available for Mac OS X (Maybe the IBM/Rational Tools Suite ?). Some of the Mac OS X tools like Interface Builder, Shark, CHUD, and OpenGL Profiler are best of breed.
She must have hit the dialog without realizing it...by default, Apple Software Update won't auto-restart, and I don't think there's any way to even enable that behavior.
By default, this is how it works:
* ASU puts up dialog showing list of installable updates; they're checked by default. Ones with restart required are marked.
* User unchecks items they don't want, presses "Install" or hits Return.
* ASU downloads and installs software. At end, flashes its own icon in the Dock as notification.
* User returns to ASU; if an update requiring restart has been installed, a modal dialog is displayed saying "The new software requires that you restart your computer..." with options "Shut Down" and "Restart." Default is 'Restart,' if user presses Return. (However, the dialog is modal only within the ASU application, you can still switch away from ASU and use the computer normally, and after clicking on it once, ASU no longer bounces in the Dock.)
* If Restart is pressed, the computer will begin the reboot process. I *think* that the process will stop if you have an application open with an unsaved document, but I haven't tested this recently.
Unfortunately, I think users are sometimes conditioned to quickly clicking the default option in any dialog they're presented with, that they sometimes don't realize until 1/4 sec after they hit it, that they just rebooted their computer.
As an aside: it's possible to avoid the reboot either by just leaving ASU in the background indefinitely (pressing Cmd-H 'hides' it so that it doesn't clutter up the UI) or by Force Quitting it, although I doubt that's recommended.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
a modal dialog
Nope, the ASU dialog is non-modal, just like all other dialogs in OS-X. Modal means the user can do no more work on the computer until they respond. Non-Modal means the user can hide the dialog or application or switch focus and continue working. Dialogs can be modal to their application, but this is strongly discouraged as a design philosophy as well.
Yes, I am a veteran of the Modal Wars. The war is mostly over and we non-modalists and computer users everywhere won. It was a major, well understood design decision from the original OS-X architects that nothing could ever be modal in OS-X. Users who switch away from using OS-X to a system that still permits modal dialogs often comment about how jarring it is to have a modal dialog they don't understand, and being forced to make an uninformed decision before being allowed to continue working or unable even to save their work. It is a subtle but very powerful distinction about who is in control of a session, the user or the OS. Modality is just a power trip for those who hate the idea that a person sitting in front of a machine might actually know what they are doing.
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
Which Microsoft vulnerability are you referring to as being over 10 years old?
Well, they started out caling it "Active Desktop". It's had other names, but that's where it started.
The vulnerability is that when you combine ActiveX with the API that applications use to call the HTML control the resulting design is fundamentally impossible even in principle to secure. The problem is that the HTML control is given the responsibility for deciding whether an object its called on to display should be trusted or not, but there the HTML control does not have enough information to make that determination. It's arguable whether the application calling it does, but in every exploit I'm aware of that has made use of this vulnerability to infect the computer giving the application responsibility for that decision would have prevented it.
The changes required to the API could be:
(1) Making the control would call back to the application to follow links, access embedded objects, and so on.
(2) Making the control by itself purely a display mechanism, and requiring explicit installation of extensions by the application.
(3) Making the sandbox the control uses "hard", and requiring the user or the application to explicitly install plugins based on roles, and making the application explicitly specify the role that the instance of the control takes.
In addition, in all cases:
(4) Make the inheritence of the environment absolute. If you follow a link from an application then the target of the link MUST be displayed under the control of the same application. That application can display it by running a more restricted helper application if appropriate (so Windows Explorer could call Internet Explorer) but that decision MUST be made by the application, not the HTML control.
Except in VERY limited circumstances (such as the default "open safe files after downloading" option in Safari, which CAN BE TURNED OFF) every other browser or mail software follows some variant of these rules (for example, the KHTML/Webkit "IO slaves" follow rule 2). The idea that a program failing to implement one of these rules would be treated as anything less than a critical bug to be fixed as soon as it was discovered was literally a bad joke before 1997. I mean, there were jokes going around about it, because everyone knew nobody would be so stupid as to implement something like Active Desktop.