Microsoft’s Recall feature is back. You may remember our coverage of the new AI feature back in June, but for the uninitiated, it was a creepy security trainwreck. The idea is that Windows will take screenshots of whatever is on the screen every few seconds, and use AI to index the screenshots for easier searching. The only real security win at the time was that Microsoft managed to do all the processing on the local machine, instead of uploading them to the cloud. All the images and index data was available unencrypted on the hard drive, and there weren’t any protections for sensitive data.
Things are admittedly better now, but not perfect. The recall screenshots and database is no longer trivially opened by any user on the machine, and Windows prompts the user to set up and authenticate with Windows Hello before using Recall. [Avram] from Tom’s Hardware did some interesting testing on the sensitive information filter, and found that it worked… sometimes.
So, with the public preview of Recall, is it still creepy? Yes. Is it still a security trainwreck? It appears that the security issues are much improved. Time will tell if a researcher discovers a way to decrypt the Recall data outside of the Recall app.
Patch Tuesday
Since we’re talking about Microsoft, this week was Patch Tuesday, and we had seventy-one separate vulnerabilities fixed, with one of those being a zero-day that was used in real-world attacks. CVE-2024-49138 doesn’t seem to have a lot of information published yet. We know it’s a Heap-based Buffer Overflow in the Common Log File driver, and allows an escalation of privilege to SYSTEM on Windows machines.
BadRAM
One of the most interesting frontiers in computing right now is trying to give cloud computing actual security. AMD has approached this problem with SEV-SNP, Secure Encrypted Virtualization/Secure Nested Paging, among other approaches. But today we have a very clever hardware attack that can defeat SEV-SNP: BadRAM.
The key here is the DIMM memory specification’s SPD, Serial Presence Detect. That’s a simple protocol that uses SMBus, an I2C protocol, to pull information from a memory module. How does your desktop know that those are 4 GB modules? And how does it know the right timings to actually boot successfully? SPD provides that data. BadRAM asks the rather simple question, what happens if you overwrite a module’s SPD chip?
When you convince SPD to lie, and report a memory module that’s larger than it really is, you get a sort of shadow memory. Put simply, multiple memory addresses refer to the same physical bits. That should set your security alarm bells to sounding. This defeats most memory protection schemes, and allows overriding SEV-SNP, by just over-writing the security hashes after they’ve been calculated. AMD has released updated firmware that actively checks for aliasing addresses, defeating the attack.
When rnd is Hard
Getting good random bits is hard. There is the obvious problem, that computers are deterministic, and can’t actually generate randomness without dedicated hardware for the purpose. Beyond that, different languages and platforms have different quirks. Many of those languages have a pseudorandom function, that can produce a good approximation of random numbers. The catch is that those numbers are entirely deterministic, and to be anything close to usable as a safe source of randomness, the pseudorandom function must be seeded with a truly non-deterministic number.
Which is why it’s particularly bad to accidentally hard-code the seed into a platform. And yes, that’s exactly what the Web assembly platform for Dart did until surprisingly recently. This did result in an easy-to-guess websocket port/key/password combination that could result in the takeover of a Dart application from another visited website. And that’s not all, follow the link above to find two other similar stories in the Dart/Flutter world.
OpenWRT and sha256 collisions
The OpenWRT project had a bit of a security scare late last week. It turns out that the attended sysupgrade service actually triggers custom firmware builds on the OpenWRT servers. And it’s possible to run arbitrary code insode that build process. That’s not as bad as it sounds, as the project works very hard to isolate each of those builds inside podman containers. There was another problem, where build artifacts were tracked using a partial SHA256 hash. The full 64 characters of a SHA256 hash is enough to be secure, particularly in this case — but reducing that to twelve characters is not.
[RyotaK] actually did the work, using hashcat to find a hash collision, resulting in the server serving a tampered firmware image in place of the correct one. The find was reported, and the sysupgrade build server was temporarily taken offline, and a fix rolled out. The OpenWRT project put out a statement, acknowledging the issue, and pointing out that there are insufficient logs to determine whether this vulnerability chain has ever actually been used. And so out of an abundance of caution, users of the sysupgrade server should trigger an in place upgrade to completely rule out the possibility of running a compromised image.
Bits and Bytes
Facebook Messenger on iOS had an issue, where a member of group calls could crash the app for all members of the call, simply by sending an invalid emote to the group. Sure puts the angry face in context. It’s fixed now, appears to be strictly limited to the denial of service crash, and there’s a decent walkthrough of the problem at the link.
Maxwell Dulin, AKA [Striꓘeout], has now worked on both sides of the security coin. He’s both been the security researcher, and now is on the security team at a company. This puts him in a particularly good position to comment on why it takes so long to fix a given bug. And not to give it away, but some of the reasons are better than others.
And finally, how not to fall for a crypto scam. In this case, it was a Telegram group, that was hawking a fake new token. The scam was rather impressive, with faked reviews from Certik and TechRate, and legitimate looking smart contracts. But like most deals that seem to good to be true, this was a rugpull, where criminal con artists convinced a few investors to put money into the scheme, only to take the money and run. Stay frosty out there!
“badram” is just another hint that what they’re trying to achieve is fundamentally impossible and foolhardy.
You MUST trust your hardware. You MUST trust your host. If you can’t trust the cloud provider with physical access to your machine, then you should be running your workloads on-prem. End of story.
I can’t think of a realistic scenario for this attack. BOFH at a hoster breaking into customer VMs?
As you point out, requiring root and (one time) physical access is already close to game over. In addition, I’d expect the system to become very unstable with the modification in place, at least if it does any meaningful work outside of running the exploit POC.
Everything is possible if a governmental or military agency asks nicely…
Or you could argue a proof that it can be secure enough to be well worth considering – a rapid and apparently effective fix to a problem that would be I’d think nearly impossible to exploit in the wild.
Ultimately some degree of ‘cloud’ or ‘multi-headed’ architecture just makes sense far too often to ignore it. The energy and cost savings of the right sort of hardware timeshares are just too great in many cases. So putting in the work that you can have trust in the remote and ‘secure’ systems… It is just a solution to a problem most of us won’t personally have.
BadRAM reminds of one of the early attacks on Wii security, by aliasing RAM using tweezers to bridge lines on the bus. Everything old is new again…
So you have a hardware RNG in the TPM. Why not use it?