What all the detractors failed to address is the fact it's essentially a portable computer with a desktop OS.
So is the Pocket PC Phone Edition.
If there's other similar products on the market or on the way where are they?
At your nearest CompUSA, Frys, Best Buy,...
The second generation Pocket PC (and about the 5th generation of Windows Powered mobile devices), Pocket PC 2002, was pretty good. It's a full fledged desktop OS with a tightly trimmed set of included libraries that are oriented towards a high end organiser. It's possible to write applications that will run on the Pocket PC *and* Windows, just by recompiling and linking them with the Windows version of the Pocket PC libraries. The development kit for Windows is free, and the calling conventions are the same... the only differences are the set of libraries available.
The phone edition of Pocket PC 2002 has been on the market for years.
And yet the Pocket PC didn't manage to nudge Palm out of the driving seat in the PDA market until Palm decided to split into two companies and the OS side ran off trying to get BeOS running on Palms. The Windows powered share of the market was consistently under 20% right up to the time Sony got tired of Palm's lack of direction and pulled the Clie out. In the phone market... well, what device is it that keeps coming up in this conversation? The Treo. There's been one or two mentions of the Pocket PC from people other than myself, but lots of people talking about the Treo.
Why?
Because the Pocket PC is "essentially a portable computer with a desktop OS", like the iPhone, and most versions have touch-screen input, like the iPhone.
This isn't like people comparing the iPod to the Rio. This is like Apple had come up with a Newton that played MP3s and put it up against the Rio.
why don't you super glue a Zune to a Blackberry
I'll keep carrying my Clie, an iPod Shuffle and a "free" cellphone, thanks. The Clie's 3 years old and still going strong, and I can take notes and look up addresses on it without having to juggle the phone between my ear and my hand, and I don't have to worry about battery life.
If a person clicks on say, a PDF file. If they have auto-opening of PDF files disabled they then have to double click on the item in the downloads window.
You're mixing up two different things here. I'm not saying "don't provide helper applications and plugins", I'm saying "Don't use general purpose desktop applications to open untrusted files". The whole reason that everyone except Microsoft uses exclusively sandboxed interpreters in web browsers is because web browsers are applications designed for handling untrusted files. There can be (in fact there are) other applications with similar restrictions. These applications would be the ones that the browser and other "sandbox" applications would use.
It does not address other downloads from other, non-Web-kit applications like mail.
The distinction is not really "webkit" versus "not-webkit". It's "sandboxed" versus "non-sandboxed". There are webkit-based applications that aren't sandboxed, like Dashboard, and there are non-webkit-based applications that should be considered part of the sandbox, like mail and other web browsers. ANY application that is designed for handling untrusted files would use the "WebServices" API rather than the "LaunchServices" API.
The intent here is to creat an inherently safe design. An inherently safe design isn't perfectly safe... any program can have bugs... but the design is such that if there is a security flaw it can be fixed without breaking anything else. You don't have to change the behaviour of the program later on because there's a buffer overflow, you can fix the buffer overflow.
Apple's model is inherently unsafe: it deliberately exposes applications that are not (and can not be) sandboxed to untrusted content. To fix a security hole that results from this decision means either changing the behaviour of the unsandboxed application (which makes the system less convenient), changing the applications that the sandboxed viewer is allowed to use (which makes the system less convenient), trying to guess whether the action should be allowed or not (which leads to Microsoft's endless redefinition of what the 'trusted zone' is), or asking the user (which makes the system less convenient). AND you still have to deal with bugs in applications as well.
What if there is a buffer overflow in Preview and it takes over the process?
That's a bug in Preview, and it can be fixed in an update. Fixing buffer overflows doesn't break anything, so they can be fixed without having companies holding off security fixes because they're afraid it'll break software they depend on (as happens routinely with Windows).
Just because a system is inherently secure doesn't mean it's perfectly secure. An inherently secure system can have all the same coding flaws of an inherently insecure one... but the insecure one has an entire mechanism for exploits to use that the secure one avoids, and it's a mechanism that's harder to fix because it's pretty much impossible to guarantee you can allow applications that NEED to use the exploited interface legitimately working while preventing insecure ones from using it as an exploit.
You end up walking a tightrope, and it's one that you don't need to get on at all. Just don't expose any dangerous operations in the interface that's available to untrusted documents.
The way to do this is with mandatory access controls and a system to determine the trust level of a given application.
I've worked with systems that really do have fine grained mandatory access controls. If you're concerned about convenience, you REALLY don't want to go down that road.
But it's odd that you like MAC, when the scheme I'm talking about *is* a MAC regime... one that's deliberately designed to be as convenient as possible and stay out of the user's way as much as possible.
There's two trust domains: the desktop environment, where applications don't have to be sandboxed; and the sandboxed environment, that consists of applications (like the b
HTC made my T-Mobile Pocket PC Phone Edition. It could do all that stuff. I did pretty much all of that stuff on it.
It was a really really horrible phone, because it was too complex, it had too short a battery life, and dialling the phone on a touchscreen is frustrating... doing it in a hurry is just not possible.
Of course the iPhone will have all the same problems, it would take a miracle to avoid them.
The problem with not using it at all is that third party malware can still use it
The point to not using IE isn't to keep "third party malware" from using it once you're already penetrated, it's to make it even possible keep it out of your computer in the first place. To reduce the problem to one where you can control it by controlling your own behaviour.
Yes, if you download a file containing an ActiveX exploit and open it from your desktop it can use the ActiveX exploit to bootstrap into execution and own your computer. But if you download a file to your desktop and open it you're risking getting owned regardless of whether ActiveX is in the loop at all. Saving untrusted documents to disk and opening them outside the browser's "sandbox" is risky behaviour. But you can learn not to engage in that risky behaviour.
With the HTML control, the decision to open a document and what to open it with is taken away from you. You no longer have the ability to consciously make that choice.
Yes, you do have to avoid more than just IE. You have to avoid Outlook, Windows Media Player (later then version 2), Realplayer, and other applications that use it. You have to learn what those applications are. But you can do that, and you can set your company's policies to match. I did that, starting in 1997, and we were the only location in our organization that didn't have a major virus incident during the years I kept that policy in place.
The "ease of use versus security" dichotomy is a false dichotomy more often than not. You make a system more secure by designing it with security in mind, not by spending more money and time after the fact to "add security". If you're faced with chooseing "ease of use over security" (or vice versa) that probably means that you've made a design error somewhere, and fixing that as soon as practical is almost always going to be cheaper, more secure, and more convenient.
This is a design choice. They favor ease of use over security in this instance.
They think they're doing that. You apparently think they're doing that. The problem is, what they're doing was never any easier than following a more secure policy, and after the first few exploits it's resulted in an overall reduction of the ease of use of OS X, without any actual increase in security.
Instead of extending the sandbox to include those applications that themselves sandbox the documents they display (safe applications), they have added a bunch of extra dialogs into LaunchServices just in case Safari (or some other Webkit-based application displaying an untrusted document) calls LaunchServices.
The result of this decision is:
* Applications that use LaunchServices to run their own helper applications present the user with an unnecessary dialog the first time they're run. This is not only irritating, but it teaches the users that this dialog sometimes comes up for no obvious reason.
* Applications that run full-screen, for example Screen Effects (screen savers) and iTunes Visualisers can not use LaunchServices to run their own helper applications, because the first time they run it... the dialog will come up, but since they're obscuring the desktop the effect will be a lockup.
* The actual exploit that led to this change would not have been prevented by it, because the Help Viewer would still have been launched without a dialog... because it's a built-in application.
The alternative? Only open files in "safe" applications after downloading. Don't depend on LaunchServices having the expected bindings for desktop helper applications (that's already been a problem with BOMArchiver vs Stuffit Expander), give Webkit its own bindings database (either a parallel to LaunchServices or an alternate interface to LaunchServices). This has a number of advantages:
* You can put safer applications in this database. On Windows, since I was using Netscape/Mozilla browsers rather than IE, I could set the application for opening documents from email or the web to WordViewer instead of Word. Similar previewer tools (simpler, with no need for dangerous functionality, and this easier to make secure) can be used to protect general desktop applications from untrusted documents.
* LaunchServices can be returned to a "desktop" mode, where it's no more paranoid than Finder, because it's only used like Finder. This makes the system as a whole more convenient.
More convenient AND more secure. Why do anything else? Microsoft has already AMPLY proven that the path of asking the user "I'm about to do something that might be really stupid, should I?" doesn't work.
Though... can't you basically do that stuff with software for your PC? Surely there's something like that by now... AT&T had the contemporary equivalent in the UNIX PC in the mid '80s.
It's called a "T-Mobile Pocket PC Phone Edition". I've got one. I don't use it... I carry a phone, a Palm, and occasionally an MP3 player. And put together they're not much bigger than the T-Mobile Pocket PC.
* Touchscreens on phones suck dirty swamp water through used oil filters. * Battery life in fancy phones is bad enough as it is, without having it play music as well.
The iPhone isn't going to be a pops-and-mom cell phone that you get for free with your year-long subscription,
That's the point, isn't it? More than 99% of phone users get something that's at most a couple steps above that. So to get the remaining 1% of the cellphone market (which is what Jobs says he's trying for) Apple will have to get 100% of the geek market, 100% of the snob market, and 100% of the style market.
OS X has a 1337 command line and that you can run full-blown cocoa apps on there.
On the iPhone? We'll see... its only got 4GB of Flash. You can't fit OS X in there. If it's got anything like a complete OS X implementation that can actually run desktop applications I'll be astonished. In any case the odds are it's using XScale, not x86.
This is just wrong. The framework file is installed by a third party application, which sets the permissions.
% ls -ld/Library drwxrwxr-x 56 root admin 1904 Dec 27 16:07/Library % open -s "Disk Utility" (pause for repair disk permissions) % ls -ld/Library drwxrwxr-t 56 root admin 1904 Dec 27 16:07/Library % ls -l/Library [...] drwxrwxr-x 4 root admin 136 Sep 12 12:09 InputManagers drwxrwxr-x 19 root admin 646 Dec 15 12:16 Internet Plug-Ins [...] drwxrwxr-x 11 root admin 374 Dec 28 18:45 PreferencePanes [...] %
Any of these locations can be used to insert trojan horses.
In the course of running repair permissions, I noticed a number of disturbing lines like "Permissions differ on./Library/Internet Plug-Ins/Flash Player.plugin/Contents/Resources/Flash Player.rsrc, should be -rw-rw-r-- , they are -rw-r--r--" where "Repair Permissions" actually decreased the security level of the application.
Apple needs to fix this. They should of course make sure there's nothing in the basic system that requires write permission there (there shouldn't be), then "Repair Permissions" should be updated to revoke non-root write for any file under/Applications,/Library,/System,/Local, or the BSD system directories like/usr, unless they are on an explicit exception list. If any application is broken by this, it's on the vendor to fix it.
As a consumer workstation, its security is "good enough" for the average user.
I used to think so, but after their stupid response to the Safari/Helpviewer hole and the subsequent holes (all of which could have been fixed for good in June 2004), and now this... I'm not so sure.
Compared to Windows, it's good. It may be comparable to Red Hat, I don't know... but Red Hat's local security isn't "good enough" either.
Apple admits to and thanks those who submit bugs to them. I've never heard of them trying to cover one up.
They don't cover them up, they just ignore them. I sent them a report on the way aliases bypass traverse checking and can be used to 'tunnel' through top level directory permissions between accounts, and I've had no response. They still haven't changed the default "Open 'Safe' Files After Downloading" behaviour in Safari, or fixed the LaunchManager design flaws. Their response is like Microsoft's... they will apply a patch to fix a specific instance of a bug, but they don't touch the root cause.
This is like building a list of windows bugs and submitting a norton product as an exhibit.
This is not a flaw in APE. Any existing plugin or a new plugin could have equally well been used. The flaw is that/Library is writable... and in investigating I've found that even after "fixing permissions" there's an awful lot of/Library that's not just writable by administrators... but by anyone.
you're basically telling me that a local admin user can change something in the system to give themselves root privileges?
It's worse, any user on an OSX box can probably give themselves root privileges with a little patience. The default permissions on/Library give any local user write access to an awful lot of files. All you have to do is drop a plugin somewhere under/Library and wait for a priviliged program to launch and execute it.
How is this really any different from simply being an admin? AFAIK, they're basically the same thing on an OSX box.
An admin user theoretically can only perform administrative duties by going through the security dialog that lets him run a program as root. Clearly this is not the case, but it should be.
The library folder has to be accessible to applications (and thus the current user) without authentication, because of the Application Support and Preferences directories, which they write to all the time.
They should not be writing to/Library.
They should be writing to ~/Library (that is, the Library subdirectory in your home directory)
Any application that attempts to write directly to/Library without sudo-ing first is broken.
If you want that kind of service, you're buying it from a Cisco, IBM, HP, EMC, etc. Apple gear, for all the press attention, is a tiny fraction of worldwide technology spending.
I don't believe this idea of Apple buying Cisco for one second, but... if Apple did buy a company that did real enterprise level support, and just kept their hands off it, but transferred the XServe support group to them, they could actually turn that around.
The problem here is that it's almost impossible to avoid using Internet Explorer.
It's a LOT easier now than it was when the alternative was Netscape 4, friend. Don't "lock it down tight", just don't use it at all until you actually need to for something that matters (that would be 'you can't get to your bank account without it'... not 'Youtube is screwing up with Firefox').
Of course, as soon as someone finds an attack vector usable with Apple Events, OS X will be the Emperor's new OS.
Hell, Windows depends on this bug. The bug is... Apple left parts of/Library writable. Microsoft requires that every user have write access to parts of the system file tree to handle things like printing and web-page caching. Instead of fixing that, they've added a subsystem to monitor it and undo changes to system files... and of course there are viruses that use that subsystem to hide in so they get put back after they're removed by AV tools.
But more importantly, in Windows everyone runs as a member of Local Administrators anyway... and you don't need an exploit to become "root" from there, you *are* root.
While you're looking at APE, have a look in/Library... maybe you'll be the first to find some spyware hiding in there thanks to all the world-writable files and directories...... because that's the real problem. They didn't need APE, they could have used their own Input Manager instead. They just picked APE to thumb their nose at Landon Fuller.
I tell people that Macs or anything but windows are safer because less people care to attack them.
Also because there are systematic security problems in Windows that are inherently unfixable without breaking working applications.
For example, simply not using Microsoft Office or Internet Explorer (or any other application that uses Microsoft's flawed HTML control or trusts random serialised COM objects... most of which are Microsoft apps) is a more effective anti-virus and anti-spyware solution than just about anything else... including running antivirus software, keeping the system updated, and applying patches judiciously every Tuesday. Combine that with an external firewall router and about the only way you're going to get infected is if you explicitly install infected software. That is the only antivirus I've used on Windows since 1997, and so far I'm batting 1.000.
The vulnerability is that APE installs itself in/Library where its supposed to go./Library is writable by local admins.
Too many words. Let me fix that for you: The vulnerability is that/Library is writable by local admins.
Even if you don't install APE on your system, an attacker who has the ability to execute this exploit can simply drop an input manager or other plugin into/Library and piggyback their way to root on any privileged application.
No, this one Apple needs to be nailed to the wall on. Leaving parts of the system writable as admin means that you're a quick framework patch away from being root... which means being in admin is almost as dangerous as being in the Local Administrators group on Windows. Not that that stops anyone from running as Local Administrator on Windows.
The bug is that/Library/Frameworks is group-writable by users in the admin group.
ANY application run setuid, or any framework or plugin used by any application run setuid, could have been used to demo it. It's got nothing to do with APE. This is no different from the many privilege escalation issues in Windows caused by writable executables and system directories.
To tell if your Mac is susceptible to this kind of privilege escalation attack, run this command:
find/Library/System/Applications -perm -022
If there are no results, then your system is probably safe. If there are more than a few results, then you're likely vulnerable.
Slashdot Mirror
What all the detractors failed to address is the fact it's essentially a portable computer with a desktop OS.
...
So is the Pocket PC Phone Edition.
If there's other similar products on the market or on the way where are they?
At your nearest CompUSA, Frys, Best Buy,
The second generation Pocket PC (and about the 5th generation of Windows Powered mobile devices), Pocket PC 2002, was pretty good. It's a full fledged desktop OS with a tightly trimmed set of included libraries that are oriented towards a high end organiser. It's possible to write applications that will run on the Pocket PC *and* Windows, just by recompiling and linking them with the Windows version of the Pocket PC libraries. The development kit for Windows is free, and the calling conventions are the same... the only differences are the set of libraries available.
The phone edition of Pocket PC 2002 has been on the market for years.
And yet the Pocket PC didn't manage to nudge Palm out of the driving seat in the PDA market until Palm decided to split into two companies and the OS side ran off trying to get BeOS running on Palms. The Windows powered share of the market was consistently under 20% right up to the time Sony got tired of Palm's lack of direction and pulled the Clie out. In the phone market... well, what device is it that keeps coming up in this conversation? The Treo. There's been one or two mentions of the Pocket PC from people other than myself, but lots of people talking about the Treo.
Why?
Because the Pocket PC is "essentially a portable computer with a desktop OS", like the iPhone, and most versions have touch-screen input, like the iPhone.
This isn't like people comparing the iPod to the Rio. This is like Apple had come up with a Newton that played MP3s and put it up against the Rio.
why don't you super glue a Zune to a Blackberry
I'll keep carrying my Clie, an iPod Shuffle and a "free" cellphone, thanks. The Clie's 3 years old and still going strong, and I can take notes and look up addresses on it without having to juggle the phone between my ear and my hand, and I don't have to worry about battery life.
If a person clicks on say, a PDF file. If they have auto-opening of PDF files disabled they then have to double click on the item in the downloads window.
You're mixing up two different things here. I'm not saying "don't provide helper applications and plugins", I'm saying "Don't use general purpose desktop applications to open untrusted files". The whole reason that everyone except Microsoft uses exclusively sandboxed interpreters in web browsers is because web browsers are applications designed for handling untrusted files. There can be (in fact there are) other applications with similar restrictions. These applications would be the ones that the browser and other "sandbox" applications would use.
It does not address other downloads from other, non-Web-kit applications like mail.
The distinction is not really "webkit" versus "not-webkit". It's "sandboxed" versus "non-sandboxed". There are webkit-based applications that aren't sandboxed, like Dashboard, and there are non-webkit-based applications that should be considered part of the sandbox, like mail and other web browsers. ANY application that is designed for handling untrusted files would use the "WebServices" API rather than the "LaunchServices" API.
The intent here is to creat an inherently safe design. An inherently safe design isn't perfectly safe... any program can have bugs... but the design is such that if there is a security flaw it can be fixed without breaking anything else. You don't have to change the behaviour of the program later on because there's a buffer overflow, you can fix the buffer overflow.
Apple's model is inherently unsafe: it deliberately exposes applications that are not (and can not be) sandboxed to untrusted content. To fix a security hole that results from this decision means either changing the behaviour of the unsandboxed application (which makes the system less convenient), changing the applications that the sandboxed viewer is allowed to use (which makes the system less convenient), trying to guess whether the action should be allowed or not (which leads to Microsoft's endless redefinition of what the 'trusted zone' is), or asking the user (which makes the system less convenient). AND you still have to deal with bugs in applications as well.
What if there is a buffer overflow in Preview and it takes over the process?
That's a bug in Preview, and it can be fixed in an update. Fixing buffer overflows doesn't break anything, so they can be fixed without having companies holding off security fixes because they're afraid it'll break software they depend on (as happens routinely with Windows).
Just because a system is inherently secure doesn't mean it's perfectly secure. An inherently secure system can have all the same coding flaws of an inherently insecure one... but the insecure one has an entire mechanism for exploits to use that the secure one avoids, and it's a mechanism that's harder to fix because it's pretty much impossible to guarantee you can allow applications that NEED to use the exploited interface legitimately working while preventing insecure ones from using it as an exploit.
You end up walking a tightrope, and it's one that you don't need to get on at all. Just don't expose any dangerous operations in the interface that's available to untrusted documents.
The way to do this is with mandatory access controls and a system to determine the trust level of a given application.
I've worked with systems that really do have fine grained mandatory access controls. If you're concerned about convenience, you REALLY don't want to go down that road.
But it's odd that you like MAC, when the scheme I'm talking about *is* a MAC regime... one that's deliberately designed to be as convenient as possible and stay out of the user's way as much as possible.
There's two trust domains: the desktop environment, where applications don't have to be sandboxed; and the sandboxed environment, that consists of applications (like the b
HTC made my T-Mobile Pocket PC Phone Edition. It could do all that stuff. I did pretty much all of that stuff on it.
It was a really really horrible phone, because it was too complex, it had too short a battery life, and dialling the phone on a touchscreen is frustrating... doing it in a hurry is just not possible.
Of course the iPhone will have all the same problems, it would take a miracle to avoid them.
The problem with not using it at all is that third party malware can still use it
The point to not using IE isn't to keep "third party malware" from using it once you're already penetrated, it's to make it even possible keep it out of your computer in the first place. To reduce the problem to one where you can control it by controlling your own behaviour.
Yes, if you download a file containing an ActiveX exploit and open it from your desktop it can use the ActiveX exploit to bootstrap into execution and own your computer. But if you download a file to your desktop and open it you're risking getting owned regardless of whether ActiveX is in the loop at all. Saving untrusted documents to disk and opening them outside the browser's "sandbox" is risky behaviour. But you can learn not to engage in that risky behaviour.
With the HTML control, the decision to open a document and what to open it with is taken away from you. You no longer have the ability to consciously make that choice.
Yes, you do have to avoid more than just IE. You have to avoid Outlook, Windows Media Player (later then version 2), Realplayer, and other applications that use it. You have to learn what those applications are. But you can do that, and you can set your company's policies to match. I did that, starting in 1997, and we were the only location in our organization that didn't have a major virus incident during the years I kept that policy in place.
The "ease of use versus security" dichotomy is a false dichotomy more often than not. You make a system more secure by designing it with security in mind, not by spending more money and time after the fact to "add security". If you're faced with chooseing "ease of use over security" (or vice versa) that probably means that you've made a design error somewhere, and fixing that as soon as practical is almost always going to be cheaper, more secure, and more convenient.
This is a design choice. They favor ease of use over security in this instance.
They think they're doing that. You apparently think they're doing that. The problem is, what they're doing was never any easier than following a more secure policy, and after the first few exploits it's resulted in an overall reduction of the ease of use of OS X, without any actual increase in security.
Instead of extending the sandbox to include those applications that themselves sandbox the documents they display (safe applications), they have added a bunch of extra dialogs into LaunchServices just in case Safari (or some other Webkit-based application displaying an untrusted document) calls LaunchServices.
The result of this decision is:
* Applications that use LaunchServices to run their own helper applications present the user with an unnecessary dialog the first time they're run. This is not only irritating, but it teaches the users that this dialog sometimes comes up for no obvious reason.
* Applications that run full-screen, for example Screen Effects (screen savers) and iTunes Visualisers can not use LaunchServices to run their own helper applications, because the first time they run it... the dialog will come up, but since they're obscuring the desktop the effect will be a lockup.
* The actual exploit that led to this change would not have been prevented by it, because the Help Viewer would still have been launched without a dialog... because it's a built-in application.
The alternative? Only open files in "safe" applications after downloading. Don't depend on LaunchServices having the expected bindings for desktop helper applications (that's already been a problem with BOMArchiver vs Stuffit Expander), give Webkit its own bindings database (either a parallel to LaunchServices or an alternate interface to LaunchServices). This has a number of advantages:
* You can put safer applications in this database. On Windows, since I was using Netscape/Mozilla browsers rather than IE, I could set the application for opening documents from email or the web to WordViewer instead of Word. Similar previewer tools (simpler, with no need for dangerous functionality, and this easier to make secure) can be used to protect general desktop applications from untrusted documents.
* LaunchServices can be returned to a "desktop" mode, where it's no more paranoid than Finder, because it's only used like Finder. This makes the system as a whole more convenient.
More convenient AND more secure. Why do anything else? Microsoft has already AMPLY proven that the path of asking the user "I'm about to do something that might be really stupid, should I?" doesn't work.
Oooh, now THAT is an interesting idea.
Though... can't you basically do that stuff with software for your PC? Surely there's something like that by now... AT&T had the contemporary equivalent in the UNIX PC in the mid '80s.
It's called a "T-Mobile Pocket PC Phone Edition". I've got one. I don't use it... I carry a phone, a Palm, and occasionally an MP3 player. And put together they're not much bigger than the T-Mobile Pocket PC.
* Touchscreens on phones suck dirty swamp water through used oil filters.
* Battery life in fancy phones is bad enough as it is, without having it play music as well.
The iPhone isn't going to be a pops-and-mom cell phone that you get for free with your year-long subscription,
That's the point, isn't it? More than 99% of phone users get something that's at most a couple steps above that. So to get the remaining 1% of the cellphone market (which is what Jobs says he's trying for) Apple will have to get 100% of the geek market, 100% of the snob market, and 100% of the style market.
OS X has a 1337 command line and that you can run full-blown cocoa apps on there.
On the iPhone? We'll see... its only got 4GB of Flash. You can't fit OS X in there. If it's got anything like a complete OS X implementation that can actually run desktop applications I'll be astonished. In any case the odds are it's using XScale, not x86.
In the course of running repair permissions, I noticed a number of disturbing lines like "Permissions differ on
Apple needs to fix this. They should of course make sure there's nothing in the basic system that requires write permission there (there shouldn't be), then "Repair Permissions" should be updated to revoke non-root write for any file under
As a consumer workstation, its security is "good enough" for the average user.
I used to think so, but after their stupid response to the Safari/Helpviewer hole and the subsequent holes (all of which could have been fixed for good in June 2004), and now this... I'm not so sure.
Compared to Windows, it's good. It may be comparable to Red Hat, I don't know... but Red Hat's local security isn't "good enough" either.
Apple admits to and thanks those who submit bugs to them. I've never heard of them trying to cover one up.
They don't cover them up, they just ignore them. I sent them a report on the way aliases bypass traverse checking and can be used to 'tunnel' through top level directory permissions between accounts, and I've had no response. They still haven't changed the default "Open 'Safe' Files After Downloading" behaviour in Safari, or fixed the LaunchManager design flaws. Their response is like Microsoft's... they will apply a patch to fix a specific instance of a bug, but they don't touch the root cause.
This is like building a list of windows bugs and submitting a norton product as an exhibit.
/Library is writable... and in investigating I've found that even after "fixing permissions" there's an awful lot of /Library that's not just writable by administrators... but by anyone.
This is not a flaw in APE. Any existing plugin or a new plugin could have equally well been used. The flaw is that
you're basically telling me that a local admin user can change something in the system to give themselves root privileges?
/Library give any local user write access to an awful lot of files. All you have to do is drop a plugin somewhere under /Library and wait for a priviliged program to launch and execute it.
It's worse, any user on an OSX box can probably give themselves root privileges with a little patience. The default permissions on
How is this really any different from simply being an admin? AFAIK, they're basically the same thing on an OSX box.
An admin user theoretically can only perform administrative duties by going through the security dialog that lets him run a program as root. Clearly this is not the case, but it should be.
The library folder has to be accessible to applications (and thus the current user) without authentication, because of the Application Support and Preferences directories, which they write to all the time.
/Library.
/Library without sudo-ing first is broken.
They should not be writing to
They should be writing to ~/Library (that is, the Library subdirectory in your home directory)
Any application that attempts to write directly to
If you want that kind of service, you're buying it from a Cisco, IBM, HP, EMC, etc. Apple gear, for all the press attention, is a tiny fraction of worldwide technology spending.
:)
I don't believe this idea of Apple buying Cisco for one second, but... if Apple did buy a company that did real enterprise level support, and just kept their hands off it, but transferred the XServe support group to them, they could actually turn that around.
Too bad HP already bought DeQ.
The problem here is that it's almost impossible to avoid using Internet Explorer.
:)
It's a LOT easier now than it was when the alternative was Netscape 4, friend. Don't "lock it down tight", just don't use it at all until you actually need to for something that matters (that would be 'you can't get to your bank account without it'... not 'Youtube is screwing up with Firefox').
Of course, as soon as someone finds an attack vector usable with Apple Events, OS X will be the Emperor's new OS.
Indeed. I am not at all happy that Safari accepts applescript://com.apple.scripteditor without a dialog, but I have been aware of this issue for a while.
Hell, Windows depends on this bug. The bug is... Apple left parts of /Library writable. Microsoft requires that every user have write access to parts of the system file tree to handle things like printing and web-page caching. Instead of fixing that, they've added a subsystem to monitor it and undo changes to system files... and of course there are viruses that use that subsystem to hide in so they get put back after they're removed by AV tools.
But more importantly, in Windows everyone runs as a member of Local Administrators anyway... and you don't need an exploit to become "root" from there, you *are* root.
While you're looking at APE, have a look in /Library... maybe you'll be the first to find some spyware hiding in there thanks to all the world-writable files and directories... ... because that's the real problem. They didn't need APE, they could have used their own Input Manager instead. They just picked APE to thumb their nose at Landon Fuller.
You may not even need to be admin.
/Library /System /Applications -perm -02". Any files or directories that show up there are world writable.
Try "find
I don't know whether resetting those permissions will break anything or not.
I don't have a scratch Mac to test it on, anyone?
Either way, as soon as you're running malicious code, you're already screwed.
Not to minimize the problem (and it IS a real problem) but this is important.
Security is like sex. Once you're penetrated you're fucked.
You should never run applications from a source you do not trust.
Don't forget to turn off "Open 'Safe' Files After Downloading" in Safari.
I tell people that Macs or anything but windows are safer because less people care to attack them.
Also because there are systematic security problems in Windows that are inherently unfixable without breaking working applications.
For example, simply not using Microsoft Office or Internet Explorer (or any other application that uses Microsoft's flawed HTML control or trusts random serialised COM objects... most of which are Microsoft apps) is a more effective anti-virus and anti-spyware solution than just about anything else... including running antivirus software, keeping the system updated, and applying patches judiciously every Tuesday. Combine that with an external firewall router and about the only way you're going to get infected is if you explicitly install infected software. That is the only antivirus I've used on Windows since 1997, and so far I'm batting 1.000.
The problem is not that a malicious admin can gain root access -- of course he can, as you pointed out. No surprise there.
A malicious application running as an "admin" should not be able to gain root access.
No wonder Apple didn't care that aliases bypass traverse checking. That's a *minor* problem by comparison.
So the real problem is either that too many Mac users are running as admin, or that admin users have too broad write permissions without using sudo.
The real problem is that admin users have too broad write permissions.
The vulnerability is that APE installs itself in /Library where its supposed to go. /Library is writable by local admins.
/Library is writable by local admins.
/Library and piggyback their way to root on any privileged application.
Too many words. Let me fix that for you: The vulnerability is that
Even if you don't install APE on your system, an attacker who has the ability to execute this exploit can simply drop an input manager or other plugin into
No, this one Apple needs to be nailed to the wall on. Leaving parts of the system writable as admin means that you're a quick framework patch away from being root... which means being in admin is almost as dangerous as being in the Local Administrators group on Windows. Not that that stops anyone from running as Local Administrator on Windows.
c id=17546398
http://apple.slashdot.org/comments.pl?sid=216122&
Not to mention Adobe and everyone else who shows up when you run that find command.
http://apple.slashdot.org/comments.pl?sid=216122&c id=17546398
http://apple.slashdot.org/comments.pl?sid=216122&c id=17546398
The bug is that /Library/Frameworks is group-writable by users in the admin group.
/Library /System /Applications -perm -022
ANY application run setuid, or any framework or plugin used by any application run setuid, could have been used to demo it. It's got nothing to do with APE. This is no different from the many privilege escalation issues in Windows caused by writable executables and system directories.
To tell if your Mac is susceptible to this kind of privilege escalation attack, run this command:
find
If there are no results, then your system is probably safe. If there are more than a few results, then you're likely vulnerable.
Try it and see.