The direct download pages are published first. It should be showing up on the update servers shortly.
999 karma · joined September 10, 2009
[ my public key: https://keybase.io/frogor; my proof: https://keybase.io/frogor/sigs/vbzsT82eX8xx51WUy-F6_i3YZucl0pVyQOFWrolI3Gw ]
The direct download pages are published first. It should be showing up on the update servers shortly.
This addresses CVE-2014-6271 and CVE-2014-7169 only. There are currently 6 CVEs listed on the Wikipedia page (not sure which are accurate): http://en.wikipedia.org/wiki/Shellshock_%28software_bug%29#S...
Some protection is better than none and I'm glad to see Apple rapidly responding. But this doesn't fix all the issues known to exist currently.
OS X has shipped with python for quite some time.
In addition, OS X python started including a build of pyobjc since OS X 10.5
You literally can fire up python from the terminal on OS X 10.5 and later and type: import Foundation and it will "just work".
No additional installs required.
If you're using the natively included python, pyobjc comes free.
As soon as I saw that mentioned in the documentation, I knew this project was going to have issues.
Have you actually gotten an APK from that site?
It looks like a 100% fake site that takes you through never ending scam surveys and sign ups.
Easy to prove it's on, just don't take it out of airplane mode until you arrive at your destination. In flight you could power it off & back on before touchdown to preserve battery.
http://wwwizer.com/naked-domain-redirect
It'll 302 redirect naked domains to www.domain, which will resolve to whatever you've configured it for.
This should let you chain A -> 302 redirect -> CNAME and bypass the GitHub DDoS protection.
They prohibit on-device dynamic native code generation (ie. no JIT and no interpreters that attempt to mark memory as executable).
They also (generally) prohibit interpreters that download code from the network and execute it.
If you're doing a workflow like: non-ObjC language -> llvm -> native code, Apple has no problem with that generally (currently).
They just want to make sure that the executable code that ships in your iOS app is all they have to worry about, that it can't generate access to system libraries/routines that were not present when submitted to them.
This is why things like Pythonista and LuaBox are in the store currently, in addition to many apps written in other languages with other IDEs (Xamarin, etc.)
Really? I'd love for some examples for where Ruby shines when it comes to Unicode handling when dealing with web content.
I know a lot of work was done in Ruby 1.9+ to bring decent Unicode encoding support to the language, but I still see a good number of complaints/articles about issues with it.
The encoding issues I've run into with python 2 have generally been whatever framework I'm using to ingest the content took a website at face value for encoding: either it wasn't defined at all or it was defined incorrectly.
In the wild wild world of web, unless you're doing intelligent data inspection, you're just going to run into that sort of thing.
In python, that's why projects like this exist: https://github.com/LuminosoInsight/python-ftfy
They let you correct Unicode content that was decoded with the wrong encoding.
I see the calculator floating around in the comments, but it's not formatted in a backup-friendly fashion / use case (ie. set storage size with XYZ% churn for changed files, or continuously expanding snapshots with aged snapshot deletion).
I've always been curious for usage for backup storage. The costs for retrieval are expensive enough (in the time frames I'd care to see for a personal computer) that I think I'll still avoid that aspect for the time being.
American branded "milk chocolate" (and specifically the process that Hershey's does) has much lower cocoa solids (and additive control) requirements than elsewhere.
- Configure proxy settings: prompt for admin credentials
- Launch arbitrary: already admitted as much
- Delete all users files: yup, that's a problem
But the problems I illustrated aren't limited to the single machine that gets infected.
Just clarifying.
And all you did was echo the lower portions of my own comment where I admitted that "fake alert" style applications could also take these details. And I'm sure other styles of attack as well.
The author of the article was trying to make a simple point though: If Apple allows an iTunes plugin such low level access that it can proxy a store transaction - ideally the thing they should be the most paranoid about - then they should probably revisit their plugin architecture (possibly taking a page from web browsing plugin sandboxing).
Claiming there will always be problems until the OS is as locked down as iOS is overkill.
I have no idea what your statement is about.
It's not an attack in its own right, but a powerful step in a non-elevated attack against Apple products.
If someone were to end up running malicious code (say, due to a recent Flash Player zero day code execution exploit ...), without the need for administrative rights, they could install this plugin into the iTunes environment for that same user.
Why is this a problem?
This plugin successfully MITM attacks an iTunes purchase and extracts your Apple ID and plaintext password. Network proxying at the machine level to attack SSL traffic would normally require admin rights.
Now that the attacker has the Apple ID, they can:
- Send a remote lock or wipe command to the user's Apple devices that are using Find My Mac/iPhone.
- Log in to Messages and receive copies of everything sent to them / they say to everyone. (They will get email notification of a new device, mind you)
- Potentially find out their home address, phone number, and real name information from the Apple service portal if they've ever taken in a device to be worked on (turning it into an identity theft attack of sorts)
Etc.
Just an FYI if you're not familiar with what an Apple ID does for the average Apple user.
Mind you, without admin rights, fake alert software could also be installed on the Mac, prompting a user for credentials of some sort with a dialog specially crafted to imitate the real thing.
The difference here, however, is that it is all legit dialogs. There are no crazy unknown processes listed on the machine that a more paranoid person might notice (once the iTunes plugin is dropped). The iTunes process itself has been made malicious.
I, for one, will be changing ownership and permissions on the plugin folder on my machines to make it non-writeable without elevation.
http://www.reddit.com/r/Bitcoin/comments/1x93tf/some_irc_cha...
They didn't discover anything - they were warned, quite some time ago, that they were not correctly spending and opening themselves up for double+ spends due to their own misunderstanding of how to reliably track a spend (compounded by their coding errors).
* Buying copies of your app as gifts (you get 70% back eventually), getting the codes, and sending those. However, gifts are per national App Store, so you have to know the store their Apple ID is associated with in advance. Additionally, you'd probably need a method of payment with a billing address in the countries you wanted to buy gift codes in ...
* Setting the cost of the app to free for 24-48 hours, with advance notification of the app being on the store / when it will be released, plus an email on the day of release with a direct app link for the store. The problem here is dissatisfaction if they "missed it" for some reason (thus the really really really early notification to the backers).
There's obviously an automated gift mechanism of some sort. IGN, Sephora, Starbucks - they all have mechanisms for generating gift codes for non-free apps when they do a giveaway. But I don't know if that mechanism is "pre-purchase a ton of codes" or an on-demand private API Apple has available.
Plus lots of other vendors that don't have their own hardware chain. Powell's books, for example.
Or anyone attempting to self-publish a DRM'd ePub without putting it in Apple's store.
> And of course Kindle and Apple customers won’t even notice, thanks to those companies’ wise decision to use their own DRM.
About the only thing "wise" about it is that if Apple were to change its own DRM scheme for the books it sells, I'm assuming they'd update iOS to include the new functionality. Admittedly, this would still lock out older devices potentially that couldn't upgrade to the latest version of iOS.
http://dns.comcast.net/index.php/help#faq2
Now no customers from Comcast suffer this.
... JavaScript and HTML injection when you reach a cap limit in a throttled market or when you get a cease and desist for pirating, however, is another matter.
Thank you for that!
You never stop making rental payments.
Worth it.