Clickbait. How can someone lacking the real docs for the CPU claim that this “can’t be patched”? How could they possibly know what chicken bits exist to disable what features?
New vuln in Apple M-series allowing secret keys extraction can't be patched
121–130 of 145 posts
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#122Earlier quoted context omitted.
> How do they protect against phishing? The same way they minimize the vulnerability when running on an exploited Windows machine? Even if I log in, via a MITM attack, all they can do is read my account history. Actually making changes requires further authorization. When I make a payment the screen asks me to confirm the amount I'm about to pay. The same applies to other security sensitive changes. Still, you make a…
> Actually making changes requires further authorization. When I make a payment the screen asks me to confirm the amount I'm about to pay. The same applies to other security sensitive changes. That’s a good answer, too, especially of that custom message can be large enough to display the name & amount. Anything to jar people out of the “I thought I was sending $100 to the cable TV company, not $6,000 to someone in In…
Thank you for your supportive words.
Certainly seeing articles like this about possible flaws in a centralized system, and the last of economic responsibility for fixing issues in affected customers, ... about people losing their Google id, the monopoly abuses of Google and Apple, and the e-waste issues of depending on apps which don't support old-but-working phones (sometimes in the name of security, but more often because it's expensive to maintain old phones) ... really gives me a bad feeling about this brave new world.
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#123Earlier quoted context omitted.
I use uMatrix and allow first party JS. When some sites break I open the matrix look at what they would like to load and allow one more origin and reload. An example: chatgpt works by allowing JS from the first party domain, *azure.com and oaistatic.com, which looks like something from OpenAI. It would like to load JS from three other domains but it works even if I don't allow them, so there is no need to let that co…
This is the way. Unfortunately, I've had no luck getting others to buy into the idea that they should understand this level of detail so they can make these calls. Quite frustrating and depressing, since companies will relentlessly exploit their indifference.
Not many developers do that. The general population won't even understand what they are looking at. If you are good at teaching you can give them an idea and a few of them maybe will do it, but the time invested in the allow/reload loop is probably too much unless one is really committed.
In my case when every attempt fails I know it could be the side effect of some other privacy add on. If it's a random blog/news, that's the end of it. If I really have to use that site I open Chrome, do what I have to do, close it. Of course given a choice I pick sites that work well with only JS from a few inevitable sources.
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#124Clickbait. How can someone lacking the real docs for the CPU claim that this “can’t be patched”? How could they possibly know what chicken bits exist to disable what features?
The page for the vuln states there is a bit you can flip to disable the entire feature on the M3, but states no such feature exists on the M1 and 2. If Apple hasn't told them about a similar bit on M1 and 2 in the 100 days since it was reported, there's a pretty good chance it doesn't exist.
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#125[dupe]
Discussion on the actual vulnerability post: https://news.ycombinator.com/item?id=39779195
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#126Earlier quoted context omitted.
What I said was that centralization is the problem. Different tasks require different levels of identification. Cash (a traditional means of payment) requires no identification. I only carry up to about $200 in cash on me, which an amount I'm willing to bear if my wallet is stolen. When I use chip&pin ("what you have and what you know") for small payments, I rarely need any authentication, and when I do it's the PIN.…
> The system - whose security I trust much more than a phone's - uses a small device with a camera. The login screen shows me a pattern with colored dots. The camera reads those dots, decodes the message (and probably also validates it cryptographically) and displays a message asking me to verify I want to log in. > I enter the PIN, and it generates a response code, which I enter. How do they protect against phishing…
> Phone-based WebAuthn systems are immune to that
Do they assume the OS is locked down and secure?
I mean, clearly if someone has a remote desktop view for my machine, then they can act as me, including any check for available hardware. The same should apply for a phone, yes?
If so, that sounds like my bank will never formally support running on a PinePhone or other user-inspectable/modifiable system - they will simply say they require a full chain of trust for the OS.
I'm glad the (relatively) open arenas of macOS and Windows existing, and that people have 10+-year-old machines, forcing my bank to support alternate login methods for less-trustworthy systems.
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#127Sweet. Wonder if this opens the door a DeCSS-style hack for open source iMessage clients?
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#128Security through obscurity is really a bad idea, and Apple is no exception. In the long run, this will likely drive the adoption of RiscV as a better alternative.
What does this have to do with security through obscurity? This is an issue with cache prefetching.
It has to with the secure processor. Although you seems to ignore what is the TCB.
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#129Security through obscurity is really a bad idea, and Apple is no exception. In the long run, this will likely drive the adoption of RiscV as a better alternative.
This RISC-V evangelism is worrying. Using RISC-V doesn't make your system secure; Good ISA implementations do. The ISA has no bearing on security vulnerabilities. Perhaps a faulty decoder could be a vulnerability vector, but a faulty RISC-V decoder wouldn't be compliant, and neither would a faulty ARM decoder. If I add a custom crypto extension to a RISC-V core and implement it badly, is that the fault of RISC-V? No!…
My comment was not about the ISA implementation or specification, It's about the TCB (trusted compute base), which in Apple (like intel and AMD) is closed. In RiscV is open. I would recommend you to educate yourself on any topic before lecture others.
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#130Unfortunately, I don't think the real world applications of this exploit are explained anywhere. From skimming the paper , it looks like the attacker needs to be able to a) run code on the victim's machine and b) trigger the encryption process ("For our cryptographic attacks, we assume the attacker runs unprivileged code and is able to interact with the victim via nominal software interfaces, triggering it to perform…
Kim Zetter has a great post walking through some details and commentary across a few sources, related to the vulnerability - https://www.zetter-zeroday.com/apple-chips/
> The cryptographic key itself isn’t placed in cache. But bits of material derived from the key gets placed in the cache, and an attacker can piece these bits together in a way that allows them to reconstruct the key, after causing the processor to do this multiple times. The researchers were able to derive the key for four different cryptographic algorithms: Go, OpenSSL, CRYSTALS-Kyber and CRYSTALS-Dilithium.
> [Green] notes that in theory this attack might be used to break the TLS cryptography that a computer’s browser uses to encrypt communication between their computer and web sites, which could allow attackers to decrypt that communication to extract a user’s session cookie for their Gmail or other web-based email account and use it to log into the account as them.