I’ve decided to put together a blog post that comprehensively covers all the new Mac malware that appeared during the course of the year. While the specimens may have been briefly reported on before (i.e. by the AV company that discovered them), this blog aims to cumulatively and comprehensively cover all the new Mac malware of 2019 - in one place …yes, with samples of each malware for download!
Oskar Groth published a modern iteration of the “LetsMove” framework where you can show a dialog at app launch, asking the user if she wants to move the app to /Applications first.
LetsMove uses AuthorizationExecuteWithPrivileges, which has long been deprecated but doesn’t have a good replacement.
AppMover uses NSAppleScript, without escaping the paths in the generated AppleScript string, to invoke rm and cp via do shell script […] with administrator privileges.
Neither works with sandboxed apps.
I think the problem is that my app is running an AppleScript, which is running a shell script, which in turn actually needs to be entitled to write to this removable storage. Although the user selects the location in which to save the logarchive – which surely establishes user intent, Apple’s reason for permitting the action – that intent isn’t communicated through the AppleScript and shell script chain to give the
logcommand the ability to save the logarchive where the user wants.
Previously:
Update (2020-01-06): Howard Oakley:
It’s this which is most frustrating of all, that neither the user nor developer gets to know, let alone grok, the rules, nor do they appear able to modify them so that macOS works the way that they expect it to. Controls in the Privacy tab don’t appear to apply to per-file privacy protection accomplished using the
com.apple.maclextended attribute, and as the extended attribute itself is protected by SIP, neither user nor developer can remove or modify it. There’s no override feature, no off switch, and no way to get your Catalina Mac to forget about per-document privacy protection and its bizarre behaviours. When you’re trapped with a document that’s behaving like a crazed cat, there’s just nowhere to go.[…]
If this is how per-document and folder privacy is going to work, then it turns using files in macOS into a game of chance, and it’s a chance that is only going to deter users. When privacy protection has these unpredictable and obstructive effects, it’s surely time to consider whether it isn’t bringing the whole of macOS, and by association Macs, into disrepute.
Cliff Biffle (via Bryan Cantrill, Hacker News):
The Rust implementation is simpler, shorter (in lines of code), faster, and smaller (in bytes of Flash) than my heavily-optimized C++ version — and because it’s almost entirely safe code, several types of bugs that I fought regularly, such as race conditions and dangling pointers, are now caught by the compiler.
[…]
Rust’s ownership rules produce a sort of bizarro-world of API design.
Some (uncommon, but reasonable) API designs won’t make it past the borrow checker. (In nearly every case, these are APIs that were easy to use incorrectly in other languages.
Some API patterns that are grossly unsafe or unwise in other languages are routine in Rust because of lifetime checking.
[…]
Because of Rust’s ownership and thread-safety rules, you can only share data between threads and ISRs if it’s packaged in one of these thread-safe containers. In Rust terms, the containers convert a type that is
Send, or safe to move between threads but not safe to use concurrently, into a type that isSync, or safe for concurrent use. If you add some new data and attempt to share it without protecting it, your code will simply not compile. This means I don’t have to think about data races except when I’m hacking the internals of a locking primitive, so I can think about other things instead.
Ben Lovejoy (tweet):
My immediate reaction was frustration at the fact that it appeared nobody had carried out a real-life test of the machine. The records showed that it had been put through all the automated tests, and had passed all of them. It also showed that a ‘functional test’ had been performed. This is what is supposed to be a real-life test: starting up and then running some software to ensure that trackpad, keyboard, microphone, speakers, and so on, were all working.
However, what hadn’t been done was to startup or wake the machine on battery, as that’s what resulted in an instant shutdown when the machine was brought in and still resulted in an instant shutdown when I tested it on collection.
[…]
A third failure in a three-year-old machine. Put another way, the MacBook Pro has three modular components, and two of them have failed. Additionally, the keyboard is liable to do so again as it’s been replaced with an identical one which has the same inherent design flaw.
[…]
I am considering fairly radical action in response: taking the advice of one reader […] to always buy AppleCare, then replace the machine every three years so it’s always under warranty.
Practically speaking, I can see why that might make sense. But it’s a bad signal to send: make unreliable hardware, and we’ll respond by subscribing to it.
Previously:
