Archive for February 22, 2018

Thursday, February 22, 2018

Code Signing Validation Bug

Patrick Wardle (video):

🤬🤬 Apple’s SecStaticCodeCheckValidity() API validates the signature of a file. Allows AV/security tools to say stuff like: “I’ll trust this 🍎-signed binary!” But malware can trick it into saying they are signed by Apple.

The ‘good news’ is Apple’s utils/defenses such as Gatekeeper & vm.cs_enforcement=1 aren’t tricked....just basically every 3rd-party security tool 😭😭 Until Apple fixes this - don’t invoke said API with kSecCSDefaultFlags.

Howard Oakley:

Patrick has found a workaround, and has already updated Objective-See’s invaluable signature-checking tool What’s My Sign?, which shouldn’t now succumb to this spoofing. If you rely on any other malware checking tools, such as an anti-virus product, you may want to install the updated What’s My Sign? (version 1.4.1) and perform manual checks until that product has been updated to address this problem.

Jeff Johnson:

Is the issue “By default, only the native architecture is validated”?

Patrick Wardle:

I believe that’s where the bug resides as kSecCSUseAllArchitectures correctly returns a code signing issue. Problem is, what ends up running by default (i.e. what the runtime identifies/executes as native architecture) is unsigned malicious code. So there is a discrepancy :(

Avast Antivirus False Positives for Apps That Use Swift

fed_h:

AVG Anti-virus quarantined two files today. Both were instances of libswiftDispatch.dylib from the Applications/1Password.app. AVG says they are MacOS:BitCoinMiner-AS[Trj].

vol24pl:

Suddenly one of Swift’s standard library files is considered a bitcoin miner.

Dave Nanian:

Avast is finding a false-positive bitcoin mining trojan in libswiftDispatch.dylib. If it quarantines the file, you will break many applications, including SuperDuper.

There is NO Trojan in our app (or the others it’s flagging)…

Howard Oakley:

The Avast and AVG detection libraries should be updated very shortly to address this error.

Update (2018-02-22): Dave Nanian:

One last follow-up regarding Avast’s really dumb mistake. They actually flagged THEMSELVES!

What this seriously shows is that they don’t really test on the Mac. AV apps are really focused on Windows.

Update (2024-09-09): I am now hearing that Intego VirusBarrier is reporting apps that bundle libswiftCore.dylib as false positives.

Howard Oakley:

I confirm those idiotic false positives on libswiftCore.dylib. Such dumb detection routines.

“I’ve Only Had Good Years”

Tim Cook (via John Gruber, MacRumors):

Stock price is a result, not an achievement by itself. For me, it’s about products and people. Did we make the best product, and did we enrich people’s lives?

[…]

In each case, if you look at when we started, I would guess that we started much before other people did, but we took our time to get it right. Because we don’t believe in using our customers as a laboratory. What we have that I think is unique is patience. We have patience to wait until something is great before we ship it. […] But ultimately the question is, Is the product great? Is it ready? And if it’s not, we delay.

Actions speak louder than words. Cook’s Apple is known for shipping incomplete products late. Was the disastrous MacBook keyboard really ready nearly three years ago? What about the first-generation Apple Watch?

A financial person just looking at revenues and profits may think, They’re good [at making money]. But that’s not who we are. We’re a group of people who are trying to change the world for the better, that’s who we are. For us, technology is a background thing. We don’t want people to have to focus on bits and bytes and feeds and speeds.

Why then does iCloud include such a pitiful amount of storage?

Music is a service that we think our users want us to provide. It’s a service that we worry about the humanity being drained out of. We worry about it becoming a bits-and-bytes kind of world, instead of the art and craft.

The introduction of Apple Music made the music experience worse for anyone who doesn’t pay a monthly fee.

You’re right, we’re not in it for the money. I think it’s important for artists.

Compare the way Cook talks about music vs. software and artists vs. developers.

iDefrag and iPartition Discontinued

Alastair Houghton:

Apple, for whatever reason, elected to release its new filesystem — and convert existing machines over to using it — without first publishing the filesystem specification so that utility vendors like us could update our software. Four months after the release of macOS High Sierra, it still hasn’t published the necessary information, and while without seeing the details it’s hard to speculate on how much work it would be to support APFS in our utilities, it’s a good bet that it’s more than six months’ work. In the meantime, in spite of the messages we’ve put on our website, customers continue to purchase the products, realise they don’t work for them, then ask for refunds (or, worse, file chargebacks through their respective banks); this actually costs us money, and also results in a string of less than satisfied customers. We don’t want that, and you, our customers, don’t want that either.

There have also been changes in recent versions of the macOS to tighten up security, which is definitely a good thing for end users, but makes it very awkward to make utility software function in a reasonable manner.

This is a shame because HFS+ fragmentation will likely be with us on spinning disks for a long time. I’m also not convinced that APFS fragmentation is a non-issue on SSDs. APFS apparently includes automatic defragmentation, but there’s little information about when and how that works. Does it do anything for large files when the disk is nearly full (as APFS volumes often will be due to snapshots)? My brand new Lightroom database is already fragmented into 10,833 pieces. Does that overhead really not matter? This is for a 1.5 GB file that’s stored on an SSD with (according to Finder) 363 GB available.

See also: Aura (Hacker News).

Previously: SuperDuper and APFS.

Swype Keyboard Discontinued

Naunce:

Nuance will no longer be offering the Swype keyboard on iOS app store. We’re sorry to leave the direct-to-consumer keyboard business, but this change is necessary to allow us to concentrate on developing our AI solutions for sale directly to businesses.

Ron Amadeo:

While Swype has a patent for “System and method for continuous stroke word-based text input,” for whatever reason that wasn’t enough to stop everyone on Earth from copying Swype’s gesture typing. Google made gesture typing a standard feature in Android’s default keyboard, and Microsoft did the same for Windows Phone 8.1(back when that was a thing). Third-party keyboards on iOS and Android have taken the idea, too, and today you can “swype” on Swiftkey, GoKeyboard, TouchPal, Ai-type, and a million other options.

By the time Swype finally launched in the Play Store, all the copycats had greatly limited the appeal of Swype’s 99 cent app. Swype’s ultra-slow rollout and OEM deals meant it never got a head start on creating a large user base, and, by the time it was finally for sale, it was too little, too late. Now it’s dead.

Previously: iOS 8 Keyboards.

On Writing Software Well

David Heinemeier Hansson:

I’ve begun a new YouTube series called On Writing Software Well where I explore the real Basecamp codebase in search of interesting programming topics. It’s less “here’s how to do it” and more “here’s what I was thinking when we made this choice or took this direction”. And it’s intimately grounded in real, production code that’s been used by millions of people.

On Compiling WebKit (Now Twice As Fast!)

Michael Catanzaro:

The approach is pretty simple: instead of telling the compiler to build the original C++ source code files that developers see, we instead tell the compiler to build unified source files that look like this:

// UnifiedSource1.cpp
#include "CSSValueKeywords.cpp"
#include "ColorData.cpp"
#include "HTMLElementFactory.cpp"
#include "HTMLEntityTable.cpp"
#include "JSANGLEInstancedArrays.cpp"
#include "JSAbortController.cpp"
#include "JSAbortSignal.cpp"
#include "JSAbstractWorker.cpp"

Since files are included only once per translation unit, we now have to parse the same headers only once for each unified source file, rather than for each individual original source file, and we get a dramatic build speedup. It’s pretty terrible, yet extremely effective.

Copyright © 2000–2024 Michael Tsai.