Live data from Hacker News

I hacked macOS

asahilina.net

131–140 of 140 posts

Re: I hacked macOS

#131
post #62

Earlier quoted context omitted.

The entire scope of my comment is about the message - the only one talking about the person is you. I find that disgusting.

> I find that disgusting. i am unfazed

I don't mean to pile on, but you guys can't do this here, and we ban accounts that do, so please don't do it again.

https://news.ycombinator.com/newsguidelines.html

Re: I hacked macOS

#132

Earlier quoted context omitted.

Any suggestions? I'll start with something that might be a good beginner friendly way to get familiar with some of the concepts: 'The Soul of a New Machine' by Tracy Kidder.

You'd be wasting your time with that. Go read the bible (Computer Organization and Design by Patterson) instead.

Do you recommend any specific one? I guess there are multiple for ARM, RISC-V, etc. Thanks

Re: I hacked macOS

#133
post #48
post #8

[flagged]

" Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting. " https://news.ycombinator.com/newsguidelines.html

There are times when website styling and design really go beyond the pale, and this is one of those cases.

The content may be excellent. The packaging utterly frustrates accessing that, and flouts all standard conventions of design. The author took a risk. The author lost.

Re: I hacked macOS

#134
post #128
post #52

Earlier quoted context omitted.

Respectfully: do you genuinely believe that guideline had this kind of presentation in mind, or the very common tedium of poorly built websites that occurs frequently on amateur tech posts. Even the examples provided by the rule you quoted lend to the latter. The format is indeed relevant.

Ah, a question I can answer unambiguously! - since I wrote that guideline, I can tell you what was/is in my mind. Internet threads have a tendency to get stuck on annoyances that aren't pertinent to the actual topic. It's a bit like a branch getting snagged at the edge of a creek: all sorts of detritus accumulates around the branch, clogging the flow. This isn't just about comments—arguably a bigger problem is that u…

Thank you for expanding on the point, I appreciate it.

Re: I hacked macOS

#135
post #105

Earlier quoted context omitted.

EAL is not a measure of security but a measure of the depth of analysis. Looking at the complexity of monolithic-kernel-based operating systems, I don't much can be derived from certifications with an EAL < 5.

Evaluated assurance levels (EAL) are a bundle of security assurance requirements (SAR) that reasonably trace to varying levels of assurance that the target of evaluation (TOE) enforces the Security Functional Requirements (SFR) of the product. One of the core SARs being AVA (vulnerability assessment) which evaluates resistance to penetration attackers and the presence of vulnerabilities. It is only at EAL5 that you a…

How do you define "penetration attackers with a moderate attack potential"?

No EAL>4 certification does not imply that something is insecure.

Judging something as "insecure" or "structurally insecure" is highly opinionated. Not everyone has the same tolerance of risk. For most users the common operating system is secure enough. Besides that security is not only depending on the kernel. Smartphone operating systems which are based on Linux practically provide more security through app isolation than most desktop-oriented Linux-based distributions.

Besides that a CC certification does not necessary certify the product as a whole which finally means you cannot even derive a state of security statement for the end user.

Example: Integrity OS has been certified on EAL6, yet the have provided a vulnerable telnet server: https://nvd.nist.gov/vuln/detail/CVE-2019-7715

Another example was the genugate firewall which has been certified on EAL4+ (including ALC_FLR.2, ALC_PAM.1, ASE_TSS.2, AVA_VAN.5), so in the end it was certified against attack with a high attack potential. Yet, the product was vulnerable to a simple authentication bypass of the management interface resulting in a CVSS score of 9.8: https://nvd.nist.gov/vuln/detail/CVE-2021-27215

Re: I hacked macOS

#137
post #127

Earlier quoted context omitted.

True, but we usually end up banning accounts that break the guidelines and don't adapt when asked to stop.

That is more authoritarian than what is suggested by the guidelines.

It's a matter of whether someone is using HN as intended or not (as far as we can tell). For accounts that repeatedly go against the intended use of the site, we don't have much choice but to ban them, or else the site won't survive for its purpose. We do warn them first, often quite a few times and over a long period before banning—it depends on how much history the account has here. For accounts without much history, we sometimes ban straightaway, if the violation is egregious.

That doesn't seem excessively authoritarian to me and I don't see how we could do it differently without giving up on the site's mandate, which is not an option.

Re: I hacked macOS

#138
post #105

Earlier quoted context omitted.

Evaluated assurance levels (EAL) are a bundle of security assurance requirements (SAR) that reasonably trace to varying levels of assurance that the target of evaluation (TOE) enforces the Security Functional Requirements (SFR) of the product. One of the core SARs being AVA (vulnerability assessment) which evaluates resistance to penetration attackers and the presence of vulnerabilities. It is only at EAL5 that you a…

How do you define "penetration attackers with a moderate attack potential"? No EAL>4 certification does not imply that something is insecure. Judging something as "insecure" or "structurally insecure" is highly opinionated. Not everyone has the same tolerance of risk. For most users the common operating system is secure enough. Besides that security is not only depending on the kernel. Smartphone operating systems wh…

“Moderate potential” is defined in the standard [1]. As we are generally discussing blackbox attacks on publicly accessible remote endpoints, basically the only relevant factors are “Elapsed Time”, “Expertise”. So, a “moderate attack potential” is: expert proficiency attacking team over four months. A “high attack potential” is expert proficiency attacking team over six months.

I know, the standard is embarrassingly low by modern attack standards. It really should be much stricter these days, but even at these embarrassingly low levels the standard commercial vendors such as Apple can not achieve them.

No, my statement on structural insecurity is quite objective. I said they are structurally insecure against commercial hackers and organized crime. That is a statement relative to a threat model and can be objectively verified.

Our objective verification is that their security properties get routinely invalidated by such attackers thousands of times a year. You would be hard pressed to find a professional hacker who would say something like: “Oh no, they are using a Mac, my plans are foiled.”

Commercial hackers and organized crime are expected threat actors. If you are running a commercial enterprise, you will be attacked by commercial hackers these days. If your systems are useless against them, then your security is objectively inadequate for your use case. Using systems certified to be inadequate for your use case is just engineering malpractice.

Yes, a Common Criteria certification does not mean the entire product is certified in much the same way that a nail certification does not mean your airplane is certified. You need to certify the entire product for the entire product to be certified. That should be obvious.

I do not know why you bring up uncertified composed products having problems in uncertified components. Yes, those components suck, we already know that. That in no way supports using composed products consisting entirely of inadequate components.

You seem to be confused about how you should use a Common Criteria certification to evaluate a product. EAL5 does not mean you are guaranteed to be protected against moderate attackers. It just provides some reasonable confidence that might be the case. What it really tells you is that you should have minimal or no confidence in systems not certified (or even worse failed certification) to EAL5.

A AVA_VAN.5 component might be vulnerable to moderate attacks. But a component that failed certification to AVA_VAN.3 is certainly vulnerable to moderate attacks.

The genugate firewall is EAL4. I do not see how this bolsters your point. There is a reason why we use EAL instead of just reporting the AVA_VAN requirement.

I do not have any particular insights into their product or that vulnerability. It is certainly possible they were over certified.

Looking at the PoC, it seems to indicate a administrator login authentication bypass. In the genugate firewall TOE [2] it indicates that the administrator network is assumed to be isolated and trusted. If an administrator login page is only meant to be accessible from the administrator network then the CVE would be out of scope of their certification. Though the CVE indicates other logins that might be affected, so I can not speculate any further. Certainly could be over-certified. But again, certification does not mean confidently secure, it is non-certification which means confidently insecure.

[1] https://www.commoncriteriaportal.org/files/ccfiles/CEM2022R1...

[2] http://www.commoncriteriaportal.org/files/epfiles/0300b.pdf

Re: I hacked macOS

#139
post #137

Earlier quoted context omitted.

That is more authoritarian than what is suggested by the guidelines.

It's a matter of whether someone is using HN as intended or not (as far as we can tell). For accounts that repeatedly go against the intended use of the site, we don't have much choice but to ban them, or else the site won't survive for its purpose. We do warn them first, often quite a few times and over a long period before banning—it depends on how much history the account has here. For accounts without much histor…

I disagree.

Re: I hacked macOS

#140
post #137

Earlier quoted context omitted.

It's a matter of whether someone is using HN as intended or not (as far as we can tell). For accounts that repeatedly go against the intended use of the site, we don't have much choice but to ban them, or else the site won't survive for its purpose. We do warn them first, often quite a few times and over a long period before banning—it depends on how much history the account has here. For accounts without much histor…

I disagree.

You're certainly welcome to disagree. I'd never claim we get all of this right; but we still have to moderate the site, decide which accounts to ban and when, which comments to mod-reply to, and so on. It's better to have some principles for this than not, and it's better to explain what they are than not. Then (at least some) people (hopefully) won't be (as) surprised if they get moderated or banned.
Post reply on HN