daysetr.blogg.se

1. MACOS MALWARE YEARS RUNONLY APPLESCRIPTS FIVE SOFTWARE
2. MACOS MALWARE YEARS RUNONLY APPLESCRIPTS FIVE CODE

Tying the code to its authors is a step to making those authors answerable for their code’s behavior.

MACOS MALWARE YEARS RUNONLY APPLESCRIPTS FIVE SOFTWARE

Guarantee that if signed code is later on tampered with, that tampering is detected andĮnable software distributors (in this case Apple) to blacklist any program immediately on it being reported to contain malware and to provisionally suspend or permanently revoke the credentials of any developer found to be accidentally/deliberately malware so that all their other code is immediately blocked from running too. Knowing provenance is critical.Ĭodesigning itself does not guarantee that the code is safe and free of malware (although related processes such as notarization can include checks for some recognized naughties), as a malware author can always sign his own code. In essence, a code signature is a binding declaration by that software’s author: “I personally wrote this software, and I take responsibility for everything that it does.” To use a comparison: there’s a good reason why airport customs always asks if you packed your own suitcases, or if someone else packed them for you. So it’s good if Apple is now forcing the issue by requiring all code be signed before it can freely run on anyone’s machines but its authors’.

It’s just that the programmer world is taking its sweet time to start addressing it, because it’s a monster they created and they know it will take a lot of hard work to fix now. Supply-chain attacks are not a new phenomenon.

(Sad to say, but the only real growth industry for AppleScript &co these days is the malware market.) If you know of any official Apple docs mentioning it, please do share.Īn “all libraries must be signed” policy makes a lot of sense in light of recurrent supply-chain attacks, where malware authors insert malicious code, not into the apps themselves, but into the 3rd-party libraries used by those apps (and in the libraries used by those libraries, and so on). If so, I would not categorize that as a “failure” (which implies a macOS bug, to be reported and fixed) but as an intentional change in macOS’s security policy, part of Apple’s general movement toward requiring all executable code is codesigned.įWIW, I quickly skimmed the 12.5 security notes and didn’t see anything specifically about codesigning and AS libraries, but it does sound like an intentional tightening of security policy around scripting and automation in general, which is both needed and overdue. If I understand you correctly, what you’re saying is that as of 12.5 a codesigned app will not load (unsigned) libraries from /Library/Script Libraries and ~/Library/Script Libraries.