thijsr (u/thijsr) - Readit News

thijsr commented on My Favorite 39C3 Talks asindu.xyz/my-favorite-39... · Posted by u/max_

jmclnx · 13 days ago

> CPUs are permanent vulnerabilities

This one looks interesting, will need to check it out!

thijsr · 13 days ago

I may be biased, but I do think it is a very fun talk

(disclosure: I am the speaker)

thijsr commented on Europe's $24T Breakup with Visa and Mastercard Has Begun europeanbusinessmagazine.... · Posted by u/NewCzech

ranguna · a month ago

Why would anyone use wero when the digital euro gets released?

The article briefly touches this point but dismisses it saying wero and the digital euro complement each other, but doesn't go into detail on how. I see no point in a privately run digital currency when we can have a public one. I guess whichever has good privacy, reliability, ease of use and speed will win.

thijsr · a month ago

A digital euro is intended to the the digital equivalent of cash. It is issued directly by the central bank. Currently, consumers cannot have an account at the central bank. They have a balance at a commercial bank, and the commercial bank has an account at the central bank. Right now, you must have a private middleman to do any banking. The digital euro should offer a public alternative to that.

(but it probably won't ever happen, because banks are lobbying against it with FUD campaigns, they feel like it threatens their existence)

Wero is something completely different. It allows consumers to easily pay merchants, mostly online. The digital euro is not a payment network in the same sense as Visa, Mastercard, iDEAL and others.

thijsr commented on L1TF Reloaded github.com/ThijsRay/l1tf_... · Posted by u/Fnoord

boulos · 3 months ago

Disclosure: I used to work on GCE.

Nice write up and very clever work. I'm surprised by the AWS response that you linked to though (https://aws.amazon.com/blogs/security/ec2-defenses-against-l...).

While I was sure they'd note that Nitro doesn't have this vulnerability due to its design, it seems weird not to talk about Firecracker and Lambda and so on. Maybe those are always on Cascadelake+ hardware? (I also haven't followed this space for 5 years, so maybe I'm asking the wrong question)

thijsr · 3 months ago

We've only verified EC2 during our research, but you do make a good point here. Nitro wasn't vulnerable. Firecracker might have been, considering that it is also built on top of KVM. Firecracker was not specifically designed to also defend against hardware vulnerabilities [1], so I don't see an immediate reason why it wouldn't have worked.

We had to limit the scope of the project somewhere unfortunately, but it would have been nice to check Firecracker and Lambda as well.

[1] https://github.com/firecracker-microvm/firecracker/blob/main...

thijsr commented on L1TF Reloaded github.com/ThijsRay/l1tf_... · Posted by u/Fnoord

thijsr · 3 months ago

Hi, author here. Thanks for posting this! I gave a talk yesterday at the 39th Chaos Communication Congress in Hamburg that goes into detail about how the vulnerability works [1]. Short summary, on affected CPUs, all of host physical memory can be read, despite commonly applied software mitigations. On Google Cloud, we were able to leak from all of the physical memory from other tenants as well, without having to interact with the victim virtual machine.

[1] https://media.ccc.de/v/39c3-spectre-in-the-real-world-leakin...

thijsr commented on Thoughts on Go vs. Rust vs. Zig sinclairtarget.com/blog/2... · Posted by u/yurivish

throwaway894345 · 3 months ago

I cautiously agree, with the caveat that while I thought I would really like Rust's error handling, it has been painful in practice. I'm sure I'm holding it wrong, but so far I have tried:

* thiserror: I spend ridiculous and unpredictable amounts of time debugging macro expansions

* manually implementing `Error`, `From`, etc traits: I spend ridiculous though predictable amounts of time implementing traits (maybe LLMs fix this?)

* anyhow: this gets things done, but I'm told not to expose these errors in my public API

Beyond these concerns, I also don't love enums for errors because it means adding any new error type will be a breaking change. I don't love the idea of committing to that, but maybe I'm overthinking?

And when I ask these questions to various Rust people, I often get conflicting answers and no one seems to be able to speak with the authority of canon on the subject. Maybe some of these questions have been answered in the Rust Book since I last read it?

By contrast, I just wrap Go errors with `fmt.Errorf("opening file `%s`: %w", filePath, err)` and handle any special error cases with `errors.As()` and similar and move on with life. It maybe doesn't feel _elegant_, but it lets me get stuff done.

thijsr · 3 months ago

> I also don't love enums for errors because it means adding any new error type will be a breaking change

You can annotate your error enum with #[non_exhaustive], then it will not be a breaking change if you add a new variant. Effectively, you enforce that anybody doing a match on the enum must implement the "default" case, i.e. that nothing matches.

thijsr commented on Privacy and Security Risks in the eSIM Ecosystem [pdf] usenix.org/system/files/u... · Posted by u/walterbell

thijsr · 6 months ago

Scientific papers have an abstract, which already serves as a short summary.

thijsr commented on L1TF Reloaded bughunters.google.com/blo... · Posted by u/thijsr

thijsr · 6 months ago

This is a project that we've been working in collaboration with Google and AWS. We present a vulnerability that allows a malicious virtual machine to leak all physical memory of its host, including the memory of other virtual machines running on the system. L1TF Reloaded combines two long-known transient execution vulnerabilities, L1TF and (Half-)Spectre. By combining them, commonly deployed software-based mitigations against L1TF, such as L1d flushing and core scheduling, can be circumvented.

We've demonstrated our attack on real-world KVM-based cloud solutions. Both Google Cloud [1] and AWS [2] wrote a blog post in response to this attack, where they describe how they mitigate against L1TF Reloaded and how they harden their systems against unknown transient execution attacks. Google also decided to award us a bug bounty of $151,515, the highest bounty of their Cloud VRP yet.

PoC is available at https://github.com/ThijsRay/l1tf_reloaded

[1] this submission

[2] https://aws.amazon.com/blogs/security/ec2-defenses-against-l...

thijsr commented on The math of shuffling cards almost brought down an online poker empire scientificamerican.com/ar... · Posted by u/indigodaddy

dragontamer · 6 months ago

RDRAND and RDSEED are both using quantum principles (aka: heat and temperature / truly quantumly random noise at the microscopic level in the CPU's transistors) to generate random numbers.

Well... a seed at least. And then they are expanded using AES encryption IIRC (which "shouldn't" be breakable, and even if it were breakable it'd probably be very difficult to follow). I think RDSEED takes hundreds (or nearly a thousand) cycles to complete, but we're still talking millions-of-bits of entropy per second. More than enough to shuffle a deck even if you're taking a fresh RDSEED every single card.

Every few months, it feels like "someone effed up RNG" becomes an article. But in practice, RDRAND / RDSEED are the primitives you need. And you should be getting that for free with Linux's /dev/urandom on modern platforms.

----------

I think RDSEED / RDRAND cannot be "proven secure" because of all the VMs we are running in practice though. So its something you need to be running on physical hardware to be 100% sure of security. So its still harder than it looks.

But its not "impossible" or anything. Just work to cover all the little issues that could go wrong. After all, these RDRAND/RDSEED instructions were created so that we can send our credit card numbers securely across the internet. They're solid because they _HAVE_ to be solid. And if anyone figures out a problem with these instructions, virtually everyone in the cryptographic community will be notified of it immediately.

---------

EDIT: I should probably add that using the shot-noise found in a pn-junction (be it a diode or npn transistor) is a fun student-level EE project if anyone wants to actually play with the principles here.

You are basically applying an amplifier of some kind (be it 3x inverters, or an OpAmp, or another NPN transistor) to a known quantum-source of noise. Reverse-avalanche noise from a Zener Diode is often chosen but there's many, many sources of true white-noise that you could amplify.

thijsr · 6 months ago

When you can modify the microcode of a CPU, you can modify the behaviour of the RDRAND/RDSEED instructions. For example, using EntrySign [1] on AMD, you can make RDRAND to always return 4 (chosen by a fair dice roll, guaranteed to be random)

[1] https://bughunters.google.com/blog/5424842357473280/zen-and-...