The Gates to Hell: Apple’s Notarizing • Hacker News Board

Re: The Gates to Hell: Apple’s Notarizing

#171

Post by AnthonyMouse » Sat, May 01, 2021, 3:08 AM UTC

jolux wrote: post #66

mmastrac wrote: post #7

Notarization has been a nightmare of a solution to a problem that isn't effective. You can get practically as much security by pushing malware signatures to the client without the massive privacy overreach of having Apple archive each and every bit of code that you generate for distribution. This is just Apple's overreach extended to the desktop. Excessive control that makes developer's lives hell while adding barely…

>You can get practically as much security by pushing malware signatures to the client without the massive privacy overreach of having Apple archive each and every bit of code that you generate for distribution. Apple do this too, it's called XProtect: https://support.apple.com/guide/security/protecting-against-... They also have a built-in malware remediation tool, which is presumably what was used when they killed t…

> Notarization is clearly part of a defense in depth strategy for macOS.

Defense in depth means layering security. It's, for example, when you use password hashing but also full disk encryption. That way if someone gets your hard drive, even if they break the disk encryption, they don't get your password in plaintext. Even if they know how to crack the password hash, they first have to get past the disk encryption.

Notarization and signatures aren't two separate measures. They're the same measure implemented two different ways. That's basically useless. If some piece of code is identified as malware then it both gets revoked and added to the malware list, and then they both catch it. If it hasn't been identified then it's neither revoked nor on the malware list.

The things that make it past one also make it past the other. There is no defense in depth because there is no depth. The two measures would have to operate based on a different principle in order to achieve that.

Re: The Gates to Hell: Apple’s Notarizing

#172

Post by mrtesthah » Sat, May 01, 2021, 3:11 AM UTC

judge2020 wrote: post #151

DCKing wrote: post #48

Earlier quoted context omitted.

Having to get any Apple code signing key for regular users is a barrier of entry for malware. However low it is, it is there. Moreover, it gives Apple the power to revoke certificates in the future to at least attempt to contain further malware activity. Is it really that hard to get your code signed as a malware developer? No, not at all. Is that worth bothering developers so much? Maybe not. Is it a power grab? Pro…

The economics also work in Apple's favor as it either requires using your real identity to commit fraud, committing identity theft by creating an LLC with someone else's identity, or paying for a registered agent in a third-world country to sign up for you (not sure how much that costs though, I've never looked!). I'm sure most malware cases they deal with are triaged for the possibility of filing a police report.

And how is any of that different from the Developer ID code-signing Apple had already? You still needed to register as either a corp or an individual using legal identifying documents just to generate the certificates. This is the step you seem to be attributing to notarization. It’s not new at all.

Moreover, Apple was also already using OSCP to check for revoked certificates when validating the code signature. They’d already revoked malware-producing Developer ID certificates several times in the past before notarization ever existed.

Re: The Gates to Hell: Apple’s Notarizing

#173

Post by AnthonyMouse » Sat, May 01, 2021, 3:18 AM UTC

Closi wrote: post #62

mmastrac wrote: post #7

Notarization has been a nightmare of a solution to a problem that isn't effective. You can get practically as much security by pushing malware signatures to the client without the massive privacy overreach of having Apple archive each and every bit of code that you generate for distribution. This is just Apple's overreach extended to the desktop. Excessive control that makes developer's lives hell while adding barely…

> You can get practically as much security by pushing malware signatures to the client without the massive privacy overreach I think the issue with pushing malware signatures to the client is that it is reactive rather than proactive - i.e. by the time you have identified a malware signature, it is already too late (which leads to an inevitable cat-and-mouse / whack-a-mole game).

> I think the issue with pushing malware signatures to the client is that it is reactive rather than proactive - i.e. by the time you have identified a malware signature, it is already too late (which leads to an inevitable cat-and-mouse / whack-a-mole game).

But notarization is the same. Apple isn't vetting notarized apps before they're distributed. All it does is impose a cost on the developer, who could still for all you know be a member of the Russian mafia. Or any random developer who has had their machine compromised and then used to sign the compromising party's malware.

It doesn't get revoked until somebody identifies the code as malware. It's the same reactive process as malware signatures.

Re: The Gates to Hell: Apple’s Notarizing

#174

Post by judge2020 » Sat, May 01, 2021, 3:55 AM UTC

mrtesthah wrote: post #172

judge2020 wrote: post #151

Earlier quoted context omitted.

The economics also work in Apple's favor as it either requires using your real identity to commit fraud, committing identity theft by creating an LLC with someone else's identity, or paying for a registered agent in a third-world country to sign up for you (not sure how much that costs though, I've never looked!). I'm sure most malware cases they deal with are triaged for the possibility of filing a police report.

And how is any of that different from the Developer ID code-signing Apple had already? You still needed to register as either a corp or an individual using legal identifying documents just to generate the certificates. This is the step you seem to be attributing to notarization. It’s not new at all. Moreover, Apple was also already using OSCP to check for revoked certificates when validating the code signature. They’…

I'm explaining how it currently works - they have the legal resources file police reports for serious reports of malware, or if it's in a place with largely uncooperative police, a domestic federal investigation into the activity.

Re: The Gates to Hell: Apple’s Notarizing

#175

Post by Klonoar » Sat, May 01, 2021, 4:00 AM UTC

hansvm wrote: post #156

Klonoar wrote: post #147

Earlier quoted context omitted.

But your release build is not done constantly, and so you have to sign in and accept an agreement - neither of which is a big deal.

> But your release build is not done constantly Some people (are they the minority? probably?) cut release builds frequently enough for it to be a big pain point. > and so you have to sign in and accept an agreement - [which isn't] a big deal It probably is though. Have _any_ agreements you've accepted in the last, say, 5yrs not had blatantly overbearing or malicious terms?

If you're cutting release builds often enough that the extra minute or two is hampering your productivity, you may have bigger issues with software development.

Re: The Gates to Hell: Apple’s Notarizing

#176

Post by zackees » Sat, May 01, 2021, 4:14 AM UTC

AnthonyMouse wrote: post #173

Closi wrote: post #62

Earlier quoted context omitted.

> You can get practically as much security by pushing malware signatures to the client without the massive privacy overreach I think the issue with pushing malware signatures to the client is that it is reactive rather than proactive - i.e. by the time you have identified a malware signature, it is already too late (which leads to an inevitable cat-and-mouse / whack-a-mole game).

> I think the issue with pushing malware signatures to the client is that it is reactive rather than proactive - i.e. by the time you have identified a malware signature, it is already too late (which leads to an inevitable cat-and-mouse / whack-a-mole game). But notarization is the same. Apple isn't vetting notarized apps before they're distributed. All it does is impose a cost on the developer, who could still for…

Malware can change its signature and then it’s no longer on the exclusion list.

However if an inclusion list is used, then the malware changing its signature means that it loses the ability to execute.

Re: The Gates to Hell: Apple’s Notarizing

#177

Post by [deleted] » Sat, May 01, 2021, 4:29 AM UTC

AnthonyMouse wrote: post #171

jolux wrote: post #66

Earlier quoted context omitted.

>You can get practically as much security by pushing malware signatures to the client without the massive privacy overreach of having Apple archive each and every bit of code that you generate for distribution. Apple do this too, it's called XProtect: https://support.apple.com/guide/security/protecting-against-... They also have a built-in malware remediation tool, which is presumably what was used when they killed t…

> Notarization is clearly part of a defense in depth strategy for macOS. Defense in depth means layering security. It's, for example, when you use password hashing but also full disk encryption. That way if someone gets your hard drive, even if they break the disk encryption, they don't get your password in plaintext. Even if they know how to crack the password hash, they first have to get past the disk encryption. N…

[deleted]

Re: The Gates to Hell: Apple’s Notarizing

#178

Post by jolux » Sat, May 01, 2021, 4:42 AM UTC

AnthonyMouse wrote: post #171

jolux wrote: post #66

Earlier quoted context omitted.

>You can get practically as much security by pushing malware signatures to the client without the massive privacy overreach of having Apple archive each and every bit of code that you generate for distribution. Apple do this too, it's called XProtect: https://support.apple.com/guide/security/protecting-against-... They also have a built-in malware remediation tool, which is presumably what was used when they killed t…

> Notarization is clearly part of a defense in depth strategy for macOS. Defense in depth means layering security. It's, for example, when you use password hashing but also full disk encryption. That way if someone gets your hard drive, even if they break the disk encryption, they don't get your password in plaintext. Even if they know how to crack the password hash, they first have to get past the disk encryption. N…

XProtect has a wider scope than notarization, though, and its detection rules are different. Notarization and XProtect are both focused on stopping malware but they don't actually operate on the same principle, notarization happens in the cloud before deployment (to stop malware from being deployed) and XProtect happens continuously in the operating system (to stop malware from running), checking for malicious signatures. That functionality intersects with notarization, but it's not equivalent.

Re: The Gates to Hell: Apple’s Notarizing

#179

Post by iancarroll » Sat, May 01, 2021, 4:57 AM UTC

AnthonyMouse wrote: post #171

jolux wrote: post #66

Earlier quoted context omitted.

>You can get practically as much security by pushing malware signatures to the client without the massive privacy overreach of having Apple archive each and every bit of code that you generate for distribution. Apple do this too, it's called XProtect: https://support.apple.com/guide/security/protecting-against-... They also have a built-in malware remediation tool, which is presumably what was used when they killed t…

> Notarization is clearly part of a defense in depth strategy for macOS. Defense in depth means layering security. It's, for example, when you use password hashing but also full disk encryption. That way if someone gets your hard drive, even if they break the disk encryption, they don't get your password in plaintext. Even if they know how to crack the password hash, they first have to get past the disk encryption. N…

Notarization is distinct from code signing/signatures, and has distinct security benefits. Notarization involves uploading the entire binary to Apple, where signatures involve you creating signatures on files that Apple is blind to.

Apple cannot guarantee they are revoking all certificates for a given malicious application with code signing, because they do not know what variants exist even if they have obtained one of them. Revoking just one code signing certificate may not be sufficient. With notarization, they can search for these variants and prevent new variants from being signed by new developer accounts -- protecting machines that i.e. have outdated XProtect definitions.

Re: The Gates to Hell: Apple’s Notarizing

#180

Post by mmastrac » Sat, May 01, 2021, 5:03 AM UTC

iancarroll wrote: post #179

AnthonyMouse wrote: post #171

Earlier quoted context omitted.

> Notarization is clearly part of a defense in depth strategy for macOS. Defense in depth means layering security. It's, for example, when you use password hashing but also full disk encryption. That way if someone gets your hard drive, even if they break the disk encryption, they don't get your password in plaintext. Even if they know how to crack the password hash, they first have to get past the disk encryption. N…

Notarization is distinct from code signing/signatures, and has distinct security benefits. Notarization involves uploading the entire binary to Apple, where signatures involve you creating signatures on files that Apple is blind to. Apple cannot guarantee they are revoking all certificates for a given malicious application with code signing, because they do not know what variants exist even if they have obtained one…

> Notarization involves uploading the entire binary to Apple

And that's exactly what I have a problem with.