Apple does use a special type of window that can only be interacted with if a user enters an administrator's username and password.
It says that's exactly what the user is doing in that Ars article. And UAC won't prevent an application running as SYSTEM from issuing commands that require SYSTEM.
Those 9 lines won't actually run without entering an administrator's username and password first to permit Script Editor to control other applications.
This is a malicious application (not an image) that has been allowed to run after the user dismissed the gatekeeper dialog that warns about downloading applications, after the user entered their password (to allow the malicious application to control other applications) and it's accessing a keychain item with no ACLs? How is that a flaw in Mac OS X?
Hmm I thought apple received billions in revenue from defaulting search to google
And?
Also, the search engine recently defaults to Bing in a lot of contexts. Apple gives the contract to whoever is the most willing to adhere to Apple's rules.
In fact, it's the exact opposite. Most religions (at least Abrahamic religions) dictate that personal health is a paramount concern. Even if something required for good health would violate some religious law, good health overrides the religious law. For example, Judaism and Islam declare pigs as unclean animals. They are not to be consumed. However, if a pork derivative is used in a vaccine, the rule of good health means that not getting the vaccine would actually be violating religious law.
The "religious exception" was added in there so idiotic anti-vaxxers could deny their children necessary vaccinations without ever getting questioned, because asking a person about their religion is considered discriminatory.
I'm not sure how this differs from the ability to set dyld environment variables to get dyld to search other paths for loading libraries (very useful for debugging). Of course, doing that requires the ability to set environmental variables (which any user can do with the Terminal). And dyld environmental variables are cleared for apps that run as root.
To me, this presentation looks like an overview of Mac OS X management and debugging features and an ad for "knockknock".
The sensible way would be to do what every Linux distro has been doing for 20 years now. The "APP" includes a manifest of its dependencies. When you install it from the App store (remember Apple does not make side loads easy, unless you are developer in which case you can solve deps issue by having the required packages available) it simply goes an fetches the required libraries at the same time if you don't already have them.
So then every developer would have to submit all the libraries they use separately so that they can be indexed and maintained? Who signs the libraries? How do they know Library A doesn't have a backdoor from Developer B when used in App C?
Non system libraries are statically linked.a files in IOS. Apple insists on this, although I'm not entirely sure why. I guess its to avoid DLL hell.
It saves them money; they don't have to spend the time developing a robust system for DLL registration, signing, updating, etc...
But it is still a really bad engineering decision, because it means what could have been patched once has to push security updates in *fifteen hundred statically linked applications*. It's their marketplace and their walled garden; they should be subsidizing the expenses which make it more secure for everybody and reduce total developer time for publishers. Push the update to developers a little in advance in case it breaks an app, then auto-push the update either to everyone or with a held-back copy for any apps that specifically flag no-security-update.
It's not rocket science, it's just good engineering.
So what are you suggesting? That every single library every single third party app uses all be installed into one location? And that every single application submitted to the app store break out their libraries separately?
iOS apps are meant to be completely contained within a single bundle.
(and yes, iOS supports dynamically linked libraries, of course it does)
The fact that a library cannot be updated simultaneously with a security patch in all apps in the app store with a change that does not change API or in-app behavior is kind of absurd.
Disclaimer: I am guessing this is the case, or else why would 1500 apps still be vulnerable?
Maybe because it's not a library or a framework? AFNetworking is a set of classes/source code that you add to your project. It is not meant to be used as a separate library.
It bugged me when Apple dropped USB cable syn(hronization) feature in Mac OS X 10.9. Lots of iDevice users were angry and made Apple add it back in the later versions.
Something that never happened bugged you? Apple never removed cable syncing from Mac OS X and iOS devices.
What did change, in Mavericks, was that SyncServices was removed. SyncServices was only responsible for syncing calendars and contact information and without it iCloud was required to sync calendars and contacts. iTunes still synced everything else.
SyncServices was added back in Mac OS X 10.9.3. But at no time did they remove the ability to sync music, photos, videos, apps, or anything other than contacts and calendars from iTunes.
You're not required to file tax returns if you fall below a certain limit or otherwise don't owe taxes. Of course, if you don't file and do owe taxes, you get punished. (And if you don't file, you can still be audited, which is fun if it turns out the IRS owes you six years of refunds)
Also, non-compete agreements are not valid in California. Even out-of-state NCAs are invalidated if the employee is to work at a CA company, (Exceptions if the employee is a stakeholder/partner/owner, which doesn't apply here).
Correct, LoopPay only works with existing magnetic swipe readers. LoopPay works by basically cloning the credit card. The LoopPay devices sends out a magnetic field that is picked up by the magstripe reader in the POS terminal.
LoopPay does not use NFC or RFID. Which also means it's great for those that want to commit credit card fraud since there is no verification or executable code to copy. Just load up the LoopPay device with multiple CC numbers, and see which ones work.
LoopPay also does not work unless there is a magstripe reader in the POS device. In October 2015, retailers in the US will start being liable for fraud committed via the magstripe reader, meaning retailers likely won't be willing to accept magstripe cards, such as those the LoopPay copies.
Remember the primary concern when these laws were proposed. As soon as criminals discover a way to maliciously activate the kill switch on a non-stolen phone, there will be serious fallout. Imagine the ransomware. There are similar concerns with law enforcement, who have demonstrated a desire to be able to wipe or forever disable a phone they've confiscated (usually one documenting their misdeeds).
And how would that work? The iPhone's activation lock is removed by entering the Apple ID/password that set up Find My iPhone on the device. You cannot change the username/password combo online (because the iPhone's activation lock doesn't use network access when triggered)
Citation of a smartphone remote kill switch being abused? Especially one that, like iOS, is triggered on an erase and is only based on the owner's credentials for unlocking?
At least on iOS, it's not so much a "remote kill switch". That is, it cannot be triggered remotely. For iPhones, if you opt in, a setting is set on the phone that if the iPhone is erased a username/password is required to activate the phone again. While you can initiate a remote wipe, that wipe just causes the iPhone to respect the initial offline setting.
For users, it's better if the iPhone is not wiped because then it can still be tracked with Find My iPhone.
If they have micro transactions (in-app purchases), then it's definitely not free. What kind of in-app purchases would products called, Clean Master, Battery Doctor, and Photo Grid have, anyways?
I don't know how I feel about this case. I avoided iTunes because I didn't like the two-faced approach of buying a license so you don't own the music, but if the device dies, you bought a file, we aren't obligated to let you retrieve the content that you have a license for.
You can download anything you've purchased again it's been that way for quite a while now.
All of those hoops are removed if the app is signed by an Apple 'enterprise deployment' certificate. Someone anyone can get just by asking.
No, those are all the hoops you have to go through to accept the "enterprise deployment" certificate profile the first time, then accept the app launching the first time. Also, the phone needs to be unlocked to accept any of these dialogs.
But then Apple can just revoke the cert (which it did for WireLurker) and blacklist the malware on the Mac side (which it also did for WireLurker).
The real issue is that you can't opt out of automatically having your phone number become and account/id in iMessage.
I want to use iMessage on my iPhone, but only with regular iCloud accounts, not with the phone number being used to create an account.
Unfortunately, the iOS team doesn't give the user that option.
The option is given when you set up a device for iMessage. It explicitly asks how you want to be contacted. By number, by email(s)/AppleIDs, or all of the above
Slashdot Mirror
Apple does use a special type of window that can only be interacted with if a user enters an administrator's username and password.
It says that's exactly what the user is doing in that Ars article. And UAC won't prevent an application running as SYSTEM from issuing commands that require SYSTEM.
Those 9 lines won't actually run without entering an administrator's username and password first to permit Script Editor to control other applications.
Try it.
This is a malicious application (not an image) that has been allowed to run after the user dismissed the gatekeeper dialog that warns about downloading applications, after the user entered their password (to allow the malicious application to control other applications) and it's accessing a keychain item with no ACLs? How is that a flaw in Mac OS X?
Hmm I thought apple received billions in revenue from defaulting search to google
And?
Also, the search engine recently defaults to Bing in a lot of contexts. Apple gives the contract to whoever is the most willing to adhere to Apple's rules.
The funny thing about this... there is no mainstream religion that actually bans vaccinations. Religious dogma predates the germ theory and therefore couldn't have possibly included vaccinations as anything banned.
In fact, it's the exact opposite. Most religions (at least Abrahamic religions) dictate that personal health is a paramount concern. Even if something required for good health would violate some religious law, good health overrides the religious law. For example, Judaism and Islam declare pigs as unclean animals. They are not to be consumed. However, if a pork derivative is used in a vaccine, the rule of good health means that not getting the vaccine would actually be violating religious law.
The "religious exception" was added in there so idiotic anti-vaxxers could deny their children necessary vaccinations without ever getting questioned, because asking a person about their religion is considered discriminatory.
I'm not sure how this differs from the ability to set dyld environment variables to get dyld to search other paths for loading libraries (very useful for debugging). Of course, doing that requires the ability to set environmental variables (which any user can do with the Terminal). And dyld environmental variables are cleared for apps that run as root.
To me, this presentation looks like an overview of Mac OS X management and debugging features and an ad for "knockknock".
The sensible way would be to do what every Linux distro has been doing for 20 years now. The "APP" includes a manifest of its dependencies. When you install it from the App store (remember Apple does not make side loads easy, unless you are developer in which case you can solve deps issue by having the required packages available) it simply goes an fetches the required libraries at the same time if you don't already have them.
So then every developer would have to submit all the libraries they use separately so that they can be indexed and maintained? Who signs the libraries? How do they know Library A doesn't have a backdoor from Developer B when used in App C?
Non system libraries are statically linked .a files in IOS. Apple insists on this, although I'm not entirely sure why. I guess its to avoid DLL hell.
It saves them money; they don't have to spend the time developing a robust system for DLL registration, signing, updating, etc...
But it is still a really bad engineering decision, because it means what could have been patched once has to push security updates in *fifteen hundred statically linked applications*. It's their marketplace and their walled garden; they should be subsidizing the expenses which make it more secure for everybody and reduce total developer time for publishers. Push the update to developers a little in advance in case it breaks an app, then auto-push the update either to everyone or with a held-back copy for any apps that specifically flag no-security-update.
It's not rocket science, it's just good engineering.
So what are you suggesting? That every single library every single third party app uses all be installed into one location? And that every single application submitted to the app store break out their libraries separately?
iOS apps are meant to be completely contained within a single bundle.
(and yes, iOS supports dynamically linked libraries, of course it does)
The fact that a library cannot be updated simultaneously with a security patch in all apps in the app store with a change that does not change API or in-app behavior is kind of absurd.
Disclaimer: I am guessing this is the case, or else why would 1500 apps still be vulnerable?
Maybe because it's not a library or a framework? AFNetworking is a set of classes/source code that you add to your project. It is not meant to be used as a separate library.
And yes, bug fixes always change behaviour
It's not even really a library (in the linking sense). It's just a set of source files you add to your project.
It bugged me when Apple dropped USB cable syn(hronization) feature in Mac OS X 10.9. Lots of iDevice users were angry and made Apple add it back in the later versions.
Something that never happened bugged you? Apple never removed cable syncing from Mac OS X and iOS devices.
What did change, in Mavericks, was that SyncServices was removed. SyncServices was only responsible for syncing calendars and contact information and without it iCloud was required to sync calendars and contacts. iTunes still synced everything else.
SyncServices was added back in Mac OS X 10.9.3. But at no time did they remove the ability to sync music, photos, videos, apps, or anything other than contacts and calendars from iTunes.
You're not required to file tax returns if you fall below a certain limit or otherwise don't owe taxes. Of course, if you don't file and do owe taxes, you get punished. (And if you don't file, you can still be audited, which is fun if it turns out the IRS owes you six years of refunds)
A123 has had a number of problems, from their bankruptcy in 2012, their massive layoffs and executive bonuses, to later being purchased by a Chinese company and selling off their assets
Also, non-compete agreements are not valid in California. Even out-of-state NCAs are invalidated if the employee is to work at a CA company, (Exceptions if the employee is a stakeholder/partner/owner, which doesn't apply here).
Correct, LoopPay only works with existing magnetic swipe readers. LoopPay works by basically cloning the credit card. The LoopPay devices sends out a magnetic field that is picked up by the magstripe reader in the POS terminal.
LoopPay does not use NFC or RFID. Which also means it's great for those that want to commit credit card fraud since there is no verification or executable code to copy. Just load up the LoopPay device with multiple CC numbers, and see which ones work.
LoopPay also does not work unless there is a magstripe reader in the POS device. In October 2015, retailers in the US will start being liable for fraud committed via the magstripe reader, meaning retailers likely won't be willing to accept magstripe cards, such as those the LoopPay copies.
Remember the primary concern when these laws were proposed. As soon as criminals discover a way to maliciously activate the kill switch on a non-stolen phone, there will be serious fallout. Imagine the ransomware. There are similar concerns with law enforcement, who have demonstrated a desire to be able to wipe or forever disable a phone they've confiscated (usually one documenting their misdeeds).
And how would that work? The iPhone's activation lock is removed by entering the Apple ID/password that set up Find My iPhone on the device. You cannot change the username/password combo online (because the iPhone's activation lock doesn't use network access when triggered)
Citation of a smartphone remote kill switch being abused? Especially one that, like iOS, is triggered on an erase and is only based on the owner's credentials for unlocking?
At least on iOS, it's not so much a "remote kill switch". That is, it cannot be triggered remotely. For iPhones, if you opt in, a setting is set on the phone that if the iPhone is erased a username/password is required to activate the phone again. While you can initiate a remote wipe, that wipe just causes the iPhone to respect the initial offline setting.
For users, it's better if the iPhone is not wiped because then it can still be tracked with Find My iPhone.
Oddly, the 10GB plan is the only one that went up in price (and by $20, no less). There's a chart of all the new prices.
So in order for this to work, an iOS device must already be compromised with a jailbreak? Why is that news?
This isn't a vulnerability, and to disable it all you have to do is uncheck "Mail & Messages" in the Spotlight preference pane in System Preferences.
If they have micro transactions (in-app purchases), then it's definitely not free. What kind of in-app purchases would products called, Clean Master, Battery Doctor, and Photo Grid have, anyways?
How are they earning a profit? If the apps are free, where do they get the money? If it's from ads, then that doesn't count as free.
I don't know how I feel about this case. I avoided iTunes because I didn't like the two-faced approach of buying a license so you don't own the music, but if the device dies, you bought a file, we aren't obligated to let you retrieve the content that you have a license for.
You can download anything you've purchased again it's been that way for quite a while now.
All of those hoops are removed if the app is signed by an Apple 'enterprise deployment' certificate. Someone anyone can get just by asking.
No, those are all the hoops you have to go through to accept the "enterprise deployment" certificate profile the first time, then accept the app launching the first time. Also, the phone needs to be unlocked to accept any of these dialogs.
But then Apple can just revoke the cert (which it did for WireLurker) and blacklist the malware on the Mac side (which it also did for WireLurker).
The real issue is that you can't opt out of automatically having your phone number become and account/id in iMessage.
I want to use iMessage on my iPhone, but only with regular iCloud accounts, not with the phone number being used to create an account.
Unfortunately, the iOS team doesn't give the user that option.
The option is given when you set up a device for iMessage. It explicitly asks how you want to be contacted. By number, by email(s)/AppleIDs, or all of the above