Alban Diquet:
To further prevent user tracking, Apple has extended MAC address randomization to additional services, and seems to now include location services scans.
[…]
Keychain items can now be encrypted using both the device’s passcode and an “Application password”; both values are then needed to decrypt and retrieve the item. This allows Apps to control when the data is accessible/decrypted, instead of having the data decrypted as soon as the device is unlocked.
[…]
iOS 9 brings several new extension points geared toward network filtering and VPNs:
- The Packet Tunnel Provider extension point, to implement the client-side of a custom VPN tunneling protocol.
- The App Proxy Provider extension point, to implement the client-side of a custom transparent network proxy protocol.
- The Filter Data Provider and the Filter Control Provider extension points, to implement dynamic, on-device network content filtering.
These extension points can only be used with a special entitlement, thereby requiring Apple to approve the extension first.
Maybe someday Little Snitch for iOS will be possible.
Extensions iOS iOS 9 Keychain Little Snitch Privacy Security Virtual Private Network (VPN)
Hector Matos:
At this point we have a retain cycle. You see, closures in Swift behave exactly like blocks in Objective-C. If any variable is declared outside of the closure’s scope, referencing that variable inside the closure’s scope creates another strong reference to that object. The only exceptions to this are variables that use value semantics such as Ints, Strings, Arrays, and Dictionaries in Swift.
Here, NSNotificationCenter retains a closure that captures self strongly when you call eatHuman(). Best practice says that you clear out notification observers in the deinit function. The problem here is that we don’t clear out the block until deinit, but deinit won’t ever be called by ARC because the closure has a strong reference to the Kraken instance!
Other gotchas where this could happen is in places like NSTimers and NSThread.
The fix is to use a weak reference to self in the closure’s capture list. This breaks the strong reference cycle.
[…]
Weak and unowned references are essentially the same. It does not increase the retain count of the object being referred. However, in Swift, an unowned reference has the added benefit of not being an Optional.
Blocks Cocoa iOS Language Design Mac Memory Management Programming Swift Programming Language
Craig Hockenberry:
Gatekeeper rejected the app because I’m using Sparkle 1.5b6. The framework has symlinks to paths on a Mac that I doubt Andy Matuschak uses anymore. That’s completely reasonable: those symlinks could just as easily point to something a lot more damaging that a non-existent directory.
The --strict option currently checks the validity of symlinks. You can point a symlink at a path in your own application package, /System or /Library, but nowhere else. The code signing rules also allow language translations to be removed, but if they are present they must be unmodified.
[…]
Many of your customers will be downloading and running your app on the El Capitan public beta: you should do the codesign --deep --strict check on any new releases to avoid customer support issues. It’s also likely that a similar check will be performed for you when the Mac App Store eventually allows submissions for 10.11.
Code Signing Gatekeeper Mac Mac OS X 10.11 El Capitan Sparkle
Raymond Chen:
This is a really bad idea. GUIDs are designed for uniqueness, not for security.
For example, we saw that
substrings of GUIDs are not unique.
For example, in the classic v1 algorithm,
the first part of the GUID is a timestamp.
Timestamps are a great technique for helping
to build uniqueness, but they are horrifically
insecure because, well, duh, the current time
is hardly a secret!
Programming Security
Stefan Esser (via Rene Ritchie, comments):
When this variable was added the usual safeguards that are required when adding support for new environment variables to the dynamic linker have not been used. Therefore it is possible to use this new feature even with SUID root binaries. This is dangerous, because it allows to open or create arbitrary files owned by the root user anywhere in the file system. Furthermore the opened log file is never closed and therefore its file descriptor is leaked into processes spawned by SUID binaries. This means child processes of SUID root processes can write to arbitrary files owned by the root user anywhere in the filesystem. This allows for easy privilege escalation in OS X 10.10.x.
At the moment it is unclear if Apple knows about this security problem or not, because while it is already fixed in the first betas of OS X 10.11, it is left unpatched in the current release of OS X 10.10.4 or in the current beta of OS X 10.10.5.
[…]
The problem with this code is that it does not come with any safeguards that are required when adding new environment variables to the dynamic linker. Normally for security reasons the dynamic linker should reject all environvent variables passed to it in case of restricted files. This is automatically handled when new environment variables are added to the processDyldEnvironmentVariable() function. However in the DYLD_PRINT_TO_FILE case the code was directly added to the _main function of dyld.
Update (2015-08-13): This is fixed in the final release of Mac OS X 10.10.5.
Update (2015-08-21): Dan Goodin (via Roustem Karimov):
On Monday, researchers from anti-malware firm Malwarebytes said a new malicious installer is exploiting the vulnerability to surreptitiously infect Macs with several types of adware including VSearch, a variant of the Genieo package, and the MacKeeper junkware.
Bug Exploit Mac Mac OS X 10.10 Yosemite Mac OS X 10.11 El Capitan MacKeeper Security
Apple (tweet):
In Swift 2, the String type no longer conforms to the CollectionType protocol, where String was previously a collection of Character values, similar to an array. Now, String provides a characters property that exposes a character collection view.
[…]
When you add an element to a collection, you expect that the collection will contain that element. That is, when you append a value to an array, the array then contains that value. The same applies to a dictionary or a set. However, when you append a combining mark character to a string, the contents of the string itself change.
[…]
However, String determines equality based on being canonically equivalent. Characters are canonically equivalent if they have the same linguistic meaning and appearance, even if they are composed from different Unicode scalars behind the scenes. […] In Swift, strings are considered equal regardless of whether they are constructed from decomposed or precomposed character sequences.
Update (2015-07-25): Pierre Lebeaupin:
If Apple can’t get its “Characters”, UTF-16 scalars, and bytes of a seemingly simple string such as “café” straight in a blog post designed to show these very views of that string, what hope could you possibly have of getting “character”-wise text processing right?
Indeed, Apple has corrected its blog post (silently).
marcelolr:
Baking in a canonicalization policy into a basic type is … interesting. I’m sure somewhere someone will be unhappy their password no longer hashes to the same value.
iOS Language Design Mac Programming Swift Programming Language Unicode
