Howard Oakley:
One of the strangest and most irritating bugs with sparse bundles in APFS format is the unreliability of their estimates of size and free space. Whether you look at free space shown in the Finder or in Disk Utility, there is no correlation between what is shown and what is actually available for use in the sparse bundle.
For example, the smallest APFS sparse bundle allowed is 8.4 MB, which is stated as having 8 MB of free space. Yet you’ll find it impossible to copy a 7 MB file to that sparse bundle, as you’ll be told that it’s full even when it’s completely empty. macOS simply refuses to let you use the claimed free space on APFS sparse bundles, although HFS+ sparse bundles aren’t as unreliable.
[…]
Despite their widespread use and advantages, macOS features supporting the use of APFS-format sparse bundles are at present riddled with bugs (I count 6 above) and have serious shortcomings. Their inability to self-compact is a major failing which makes their use clumsy at best, and Disk Utility’s lack of support for basic maintenance functions through the last 2.5 years reflects badly on Apple’s engineering priorities. Disk Utility remains of early beta-test quality and far from complete.
I don’t see much reason to use APFS disk images, except for testing how an app works with APFS. HFS+ sparse bundles are dependable and can be compacted with DropDMG.
The Disk Utility reliability problems go back to the rewrite in macOS 10.11. Usually the command-line tools work better.
Previously:
Apple File System (APFS) Bug Disk Image Disk Utility Mac macOS 10.15 Catalina
Jeff Johnson (tweet):
Normally, when a sandboxed app writes to a file, the file is quarantined. If the file is a shell script, then the quarantine extended attribute would prevent the script from running. However, when an app such as TextEdit with the “com.apple.security.files.user-selected.executable” entitlement saves a file, it removes the quarantine extended attribute!
My sample app opens a shell script in TextEdit, and then it uses the Apple Events permission to tell TextEdit to save the file, thus removing the quarantine and allowing the script to be executed outside the app’s sandbox.
This should appear very innocuous to the user, because nobody thinks that TextEdit is dangerous, so one would think it’s not much of a risk to allow TextEdit to be controlled.
I tried the sample project, and this seems to be legit. The app can save an arbitrary shell script, launder it through TextEdit, and then tell the system to open it, which will make it run outside of the sandbox.
I don’t understand why Apple thinks there are no “actual security implications” (and thus won’t pay the bug bounty). This comes on the heels of the iOS Mail vulnerabilities—which Apple said could not be exploited even though the reporter, ZecOps, claims it has seen them in the wild—and Johnson’s own report about Safari running disabled extensions, where Apple initially didn’t see a problem but later fixed it and credited him.
Jeff Johnson:
Note that Transmit is another sandboxed app, along with BBEdit and TextEdit, that possesses the special “executable” entitlement. These apps can all escape their own sandboxes.
The “user-selected” part of the “com.apple.security.files.user-selected.executable” entitlement is extremely misleading. No user action is required to use that entitlement.
It seems to me that the core issue is not the entitlement but that if a shell script has executable permission, macOS will run it when it’s opened. Why not restrict code execution to .app bundles? I’m not even sure it’s a useful feature. I always run scripts via a helper app or from within Terminal.
Previously:
Update (2020-05-18): Daniel Jalkut:
I just reproduced
@lapcatsoftware’s sandbox escape. Incredible find, I can’t believe Apple doesn’t deem this a legitimate security issue that warranted a bounty payment?
Update (2020-06-05): Jeff Johnson:
So I’m writing now to clarify a number of points that I feel have not been broadly understood.
See also: Hacker News and this Twitter thread.
Apple Security Bounty AppleScript BBEdit Bug Entitlements Exploit Mac macOS 10.14 Mojave macOS 10.15 Catalina Privacy Sandboxing Security TextEdit Transmit
Stephen Cass (via Josh Centers):
This hack allows digital systems without specialized graphics hardware to produce color images by exploiting quirks in how TVs decode analog video signals.
NTSC artifact color was used most notably by the Apple II in 1977, where Steve “Woz” Wozniak’s use of the hack brought it to wide attention; it was later used in the IBM PC and TRS-80 Color Computers. But it was unclear where the idea had originally come from, so we were thrilled to see that video game and electrical engineering legend Allan Alcorn left a comment on the article with an answer: the first color computer graphics that many people ever saw owe their origin to a cheap test tool used in a Californian TV repair shop in the 1960s. IEEE Spectrum talked to Alcorn to find out more[…]
Apple II Color Graphics History Programming Steve Wozniak
