Dan Goodin:
For almost 11 years, hackers have had an easy way to get macOS malware past the scrutiny of a host of third-party security tools by tricking them into believing the malicious wares were signed by Apple, researchers said Tuesday.
[…]
The technique worked using a binary format, alternatively known as a Fat or Universal file, that contained several files that were written for different CPUs used in Macs over the years, such as i386, x86_64, or PPC. Only the first so-called Mach-O file in the bundle had to be signed by Apple. At least eight third-party tools would show other non-signed executable code included in the same bundle as being signed by Apple, too. Affected third-party tools included VirusTotal, Google Santa, Facebook OSQuery, the Little Snitch Firewall, Yelp, OSXCollector, Carbon Black’s db Response, and several tools from Objective-See. Many companies and individuals rely on some of the tools to help implement whitelisting processes that permit only approved applications to be installed on a computer, while forbidding all others.
Mitchel Broussard:
Developer Patrick Wardle spoke on the topic, explaining that the bypass was due to ambiguous documentation and comments provided by Apple regarding the use of publicly available programming interfaces that make digital signature checks function: “To be clear, this is not a vulnerability or bug in Apple’s code… basically just unclear/confusing documentation that led to people using their API incorrectly.” It’s also not an issue exclusive to Apple and macOS third-party security tools, as Wardle pointed out: “If a hacker wants to bypass your tool and targets it directly, they will win.”
For its part, Apple was said to have stated on March 20 that it did not see the bypass as a security issue that needed to be directly addressed. On March 29, the company updated its documentation to be more clear on the matter, stating that “third-party developers will need to do additional work to verify that all of the identities in a universal binary are the same if they want to present a meaningful result.”
Josh Pitts:
Without passing the proper SecRequirementRef and SecCSFlags, the code signing API (SecCodeCheckValidity) will check the first binary in the Fat/Universal file for who signed the executable (e.g. Apple) and verify no tampering via the cryptographic signature; then the API will check each of the following binaries in the Fat/Universal file to ensure the Team Identifiers match and verify no tampering via containing cryptographic signature but without checking the CA root of trust. The reason the malicious code, or “unsigned” code, must be i386, is that the code signing API has a preference for the native CPU architecture (x86_64) for code signing checks and will default to checking the unsigned code if it is x86_64.
[…]
However, to properly check for this type of abuse you need to add an anchor certificate requirement via the following commands:
- codesign -vv -R=’anchor apple’ ./some_application_or_mach-o # for Apple signed code
- codesign -vv -R=’anchor apple generic’ ./some_application_or_mach-o # for Apple signed code and Apple developer signed code
[…]
Typically, a developer would check the a Mach-O binary or Fat/Universal binary with the following APIs SecStaticCodeCheckValidityWithErrors() or SecStaticCodeCheckValidity() with the following flags:
These flags are supposed to ensure that all the code in a Mach-O or Fat/Universal file that is loaded into memory is cryptographically signed. However, these APIs fall short by default, and third party developers will need to carve out and verify each architecture in the Fat/Universal file and verify that the identities match and are cryptographically sound.
Update (2018-06-13): Objective Development:
Fortunately for us and our users, the consequences this has for Little Snitch are not as as bad as it first seems when reading the various headlines about this issue: What connections are allowed or denied by Little Snitch’s network filter is completely unaffected by this. The only thing that could happen is that Little Snitch would show inconsistent or incorrect information about an app’s code signature, but it would never actually allow connections that should not be allowed.
Code Signing Little Snitch Mac macOS 10.13 High Sierra Programming Security
Rene Ritchie (tweet):
Soon enough, the priority will begin and end with showstoppers that prevent software from shipping. At that point, the glitches, no matter how maddening, will get deferred. It’s simple project management. Apple has to fix the bugs that can’t be worked around before fixing the bugs that can. And they have to fix the bugs that affect a lot of people before fixing the bugs that affect relatively few.
Right now, though, right when the first betas hit, there’s some breathing room. And that’s where radar comes in. If someone at Apple wants to get a bug fixed, they need a radar to point to. If they want to get a bug fixed as a matter of priority, they need a lot of radars to point to. Otherwise, they simply won’t be given the time to do it.
James O’Leary:
After 11 years, I finally read an Apple engineer give an unofficial deadline to file bugs - they said by beta 3.
Marco Arment:
On one hand, this is true and pragmatic.
On the other hand, it’s stupid that the richest tech company in the world can only fix our reported bugs quickly (and seems to only pay attention to them) during a brief window once a year.
Daniel Jalkut:
To make a difference you need to file bugs often and file them well. I’ve had bugs ignored, duped, fixed, and fixed with honors ;)
There’s a toxic meme in iOS and Mac community that bug filing is pointless. It’s fed by misinterpreting Apple’s challenge in replying.
Corbin Dunn:
I second this! All bugs are looked at; sometimes the screening process is slow or gets stuck on one person, or in the wrong queue. Having an existing bug rack up duplicate reports will help increase its priority.
Apple Apple Software Quality Bug Bug Tracking iOS iOS 12 Mac macOS 10.14 Mojave Radar and Feedback Assistant Reminders Siri
Howard Oakley:
Many developers are reporting that they have been unsuccessful in getting the initial beta-release of macOS 10.14 Mojave to install on external drives. In many cases, they are connecting the external drive via a USB-C adaptor to a MacBook or MacBook Pro.
I too had exactly this problem: I connected two different USB3 SSDs to my MacBook Pro 14,1 using a good quality USB-C to USB adaptor. Each time that I ran the Mojave installer to install on that external SSD, all it did was copy the install files into a folder, restart, then drop me back into High Sierra from the Mac’s internal SSD.
Jeff Johnson (tweet):
On Mojave, however, the first time after login that you try to debug an app without the com.apple.security.get-task-allow entitlement, the system displays a modal dialog requesting an administrator password:
Developer Tool Access needs to take control of another process for debugging to continue.
[…]
Prior to Mojave, Xcode would request on first launch to “Enable Developer Mode on this Mac”. On Mojave, Xcode no longer requests Developer Mode. However, Developer Mode can still be enabled manually with /usr/sbin/DevToolsSecurity -enable in Terminal. After you authenticate with DevToolsSecurity once, Developer Mode is permanently enabled on Mojave, and you won’t have to authenticate again to debug.
[…]
What happens on Mojave if you try to debug an app compiled with the hardened runtime? If System Integrity Protection is disabled, then nothing changes; it’s the same as I described in the first section of this blog post. So the hardened runtime is enforced by SIP. With SIP enabled, you can still debug your app if it’s compiled with the com.apple.security.get-task-allow entitlement. If an app doesn’t have that entitlement, however, then you can’t debug it at all.
[…]
The hardened runtime is also supposed to make the app ignore DYLD_ environment variables such as DYLD_PRINT_LIBRARIES.
Previously: The Impossible Dream of USB-C.
Code Signing Debugging LLDB Mac macOS 10.14 Mojave System Integrity Protection USB USB-C Xcode
Seth Godin (Hacker News):
I like paying for my software when I’m buying it from a company that’s responsive, fast and focused. I like being the customer (as opposed to a social network, where I’m the product). I spend most of my day working with tools that weren’t even in science fiction novels twenty-five years ago, and the money I spend on software is a bargain–doing this work without it is impossible.
To name a few, I’m glad to use and pay for: Overcast, Feedblitz, Discourse, Zapier, Dropbox, Roon, WavePad, Bench, Nisus, Zoom, Slack, SuperDuper, Mailchimp, Hover, TypeExpander, Tidal, and many others. I wish I could pay for and get great support and development for Keynote.
afarrell:
One of the reasons that I switched from Linx to OSX was so that I could pay for more of my software. Why? Because then I more of the software I used could be maintained by someone who had the time to dig into bugs and UI problems and to fix them. But in Linux, couldn’t I just edit the source myself? Realistically, no. It takes a tremendous amount of effort to source-dive in a totally new project in a language I never use, especially without someone willing to give me a walkthrough of the architecture and fundamental models of the program. It is waaaay more efficient for these to be fixed by an engineer working not in their spare time, but as their full-time job.
Business Keynote Linux Mac Open-source Software Web
Stephen Hackett:
My co-founder Philip introduced himself to me at Macworld San Francisco 2003, where I was exhibiting PageSender, my faxing software. We hit it off, I had an idea for a product, he had the artistic know how, and together we produced DiscLabel, our disc labeling app.
[…]
We acquired Textpander from Peter Maurer, now of Many Tricks. Smile shipped TextExpander 1.3 on May 23, 2006, and the post you cite does a good job telling the story. It’s a case of, ‘I really need this app for my life, other people must also’ combined with ‘If I make it, I can ensure it will always work for me.’
[…]
If the era of fax and PageSender is over, what’s next? We figured PDFs sent via email would replace faxing. Looking at the PDF editor options showed a huge gap between Apple’s Preview, which was read-only at that time, and Adobe Acrobat, which was far too much for an everyday user. We figured we could fit somewhere between ‘free and very limited’ and ‘crazy expensive and can do everything, only a bit of which you need.’
Business History Mac PDFpen TextExpander
Craig Hockenberry (tweet):
Why are the icons different? The answer lies in this one line of page markup:
<link rel="mask-icon" href="/favicon.svg" color="#990000">
We keep a favicon.ico file in the root of the website filesystem for compatibility with browsers that don’t support vector icons. But Safari knows that SVG will look better on a high resolution display, so it checks for a favicon.svg first.
Previously: Safari Should Display Favicons in Its Tabs.
Favicons Icons Mac macOS 10.14 Mojave Safari SVG
