Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A 0-click exploit chain for the Pixel 10

projectzero.google

Post reply on HN
Print view View original

71–80 of 255 posts

Re: A 0-click exploit chain for the Pixel 10

#71

Post by kps »

IshKebab wrote: post #28
codedokode wrote: post #7

I read about Pixel 9 Dolby Decoder bug, and it is based on integer overflow. It was a mistake to allow "+" operator to overflow, and this must be fixed in new languages like Rust, but it is not.

It isn't because no ISA implements add like that, so there's always performance on the table if you check every time, and people would probably endlessly moan about how Rust is 20% slower than C on this add-heavy microbenchmark. That said you can enable overflow checks in Rust's release mode. It's literally two lines: [profile.release] overflow-checks = true I wonder if it would make sense for ISAs to have trapping v…

> It isn't because no ISA implements add like that

MIPS does (did?). And VAX, IBM/360, ....

Re: A 0-click exploit chain for the Pixel 10

#72

Post by CobrastanJorji »

greesil wrote: post #4

"This is notably fast given that this is the first time that an Android driver bug I reported was patched within 90 days of the vendor first learning about the vulnerability." This makes me feel better about Google, but also makes me kind of frightened of the rest of Android. I wonder what Apple's response time is?

Android vendors have been notorious about updates for a long time. Part of that is supposedly because all of the phone companies want to distinguish themselves from each other, and so they all want to fork the default Android UI so they can offer some psychedelic UI vision with some brand-specific features. But that means that when an update to stock Android comes out, it's a lot of work to migrate.

Re: A 0-click exploit chain for the Pixel 10

#73

Post by ysnp »

jeffbee wrote: post #35
NooneAtAll3 wrote: post #5

fascinating how GrapheneOS achieves high security level on the same hardware where Google failed to even randomize android's kernel location

KASLR isn't an effective mitigation against anything, and to me this is part of GrapheneOS's catalog of superficial but meaningless claims.

I've not seen someone refer to a portion of GrapheneOS's mitigations as superficial and meaningless before. What might an OS with significant improvements to usable attack surface reduction and exploit mitigations look like to you? What sort of things (given a team of less than a dozen contending with OS updates, upgrades and device support) would you have liked to see implemented?

Re: A 0-click exploit chain for the Pixel 10

#74

Post by tialaramex »

bombcar wrote: post #54
tialaramex wrote: post #44

Earlier quoted context omitted.

Well, one scenario would be that everybody who writes code would do so for money. Take my friend who is a property lawyer. The firm she works for buys her insurance, because it would be insane to operate without insurance, but the only available insurance is personal insurance, it insures a specific person to do property law. So, although her day job is helping that $100Bn farm equipment company buy a $10M new factor…

Or it becomes standardized to have exclusions - pilots for example often have extensive insurance that covers the company when they’re flying for hire, but covers nothing if puttering around in a Cessna on the weekend. Insurance companies are very, very good at figuring out how to identify and price risk, once motivated to do so.

Sure as you'd expect lawyers are better at cutting a good deal for themselves than other professions, but I wanted to cite an example where it does work out.

Also from what I've seen there are way too many GA accidents involving airline pilots for the insurers to eat that loss. They almost invariably have superior skills, but some of them more than compensate with risk taking.

Re: A 0-click exploit chain for the Pixel 10

#75

Post by codedokode »

tialaramex wrote: post #31
codedokode wrote: post #7

I read about Pixel 9 Dolby Decoder bug, and it is based on integer overflow. It was a mistake to allow "+" operator to overflow, and this must be fixed in new languages like Rust, but it is not.

In Rust the decision about whether to pay for overflow checks or just wrap (because all modern hardware will just wrap if you don't check and that's cheaper) is a choice you can make when compiling software, by default you get checks except in release builds but you can choose checks everywhere, even in release builds or no checks even in debug. By definition in Rust it's incorrect to overflow the non-overflowing int…

> is a choice you can make when compiling software

That is not a solution because it means the code can behave differently, and expose vulnerability if wrong compilation settings are chosen.

The functions like "wrapping_add" have such a long names so that nobody wants to use them and they make the code ugly. Instead, "+" should be used for addition with exceptions, and something like "wrap+" or "" or "[+]" used for wrapping addition.

That's how people work, they will choose the laziest path (the simplest function name) and this is why you should use "+" for safer, non-wrapping addition and make the symbol for wrapping addition long and unattractive. Make writing unsafe code harder. This is just basic psychology.

C has the same problem, they have functions checking for overflow, but they also have long and ugly names that discourage their use.

> modern hardware will just wrap if you don't check and that's cheaper

So you suggest that because x86 is a poorly designed architecture, we should adapt programing languages to its poor design? x86 will be gone sooner or later anyway.

Also, there are languages like JS, Python, Swift which chose the right path, it is only C and Rust developers who seem to be backwards.

Re: A 0-click exploit chain for the Pixel 10

#76

Post by lightedman »

orf wrote: post #62
mark_l_watson wrote: post #58

Earlier quoted context omitted.

Not sure how much it helps, but I just run all my Apple devices in "Lockdown mode", don't install apps (use Safari), and try to mostly use Safari in private sandboxed mode.

This makes sense if you’re a human-rights journalist working in a dangerous country, with the threat of state-level actors looking to compromise you. If you’re not then this seems quite paranoid, bordering on LARPing.

"If you’re not then this seems quite paranoid, bordering on LARPing."

There are sooooooo many other situations where such device lockdown is warranted. Government intrusion, sensitive industry, journalism, anything ITAR/EAR covered, and more. Your reduction to a single issue is absurd.

Re: A 0-click exploit chain for the Pixel 10

#77

Post by Seattle3503 »

jcims wrote: post #51
revolvingthrow wrote: post #6

Semi-related: has the rate of published exploits picked up as if late, or is it simply the fact that there’s hype around ai as security tool (offense or defense) so it’s simply in the news more often? Feels like there’s something new every other day - linux, windows, mobile, various commonplace tools used by everybody, the list goes on

I just did some analysis on this last weekend, in 2024 there were roughly 100 CVEs published every day. In April we hit approximately 200 per day. Going backwards from 2023, the doubling interval for published CVEs was approximately 4 to 4 1/2 years. Since then it’s approximately two years. There has definitely been a rapid uptick.

The rules around CVE reporting changed recently and it would be expected a lot more are accepted.

Re: A 0-click exploit chain for the Pixel 10

#78

Post by shay_ker »

gruez wrote: post #64
shay_ker wrote: post #3

Hmmm... I'd like someone to double check my thinking here. I posted this exact prompt for gpt 5.5 xhigh: ``` does this look right to you? don't do any searches or check memory, just think through first principles static int vpu_mmap(struct file fp, struct vm_area_struct vm) { unsigned long pfn; struct vpu_core core = container_of(fp->f_inode->i_cdev, struct vpu_core, cdev); vm_flags_set(vm, VM_IO | VM_DONTEXPAND | VM…

That's not really a fair test because you're leading the model pretty hard, even if the prompt doesn't specifically say there's a bug to be found. It's basically the same objections that people raised in the thread where someone claimed current models are just as good as mythos.

right exactly, but clearly it's possible to elicit the behavior we want in the model, which means the capabilities are there!

Re: A 0-click exploit chain for the Pixel 10

#79

Post by shay_ker »

thejokeisonme wrote: post #38
shay_ker wrote: post #3

Hmmm... I'd like someone to double check my thinking here. I posted this exact prompt for gpt 5.5 xhigh: ``` does this look right to you? don't do any searches or check memory, just think through first principles static int vpu_mmap(struct file fp, struct vm_area_struct vm) { unsigned long pfn; struct vpu_core core = container_of(fp->f_inode->i_cdev, struct vpu_core, cdev); vm_flags_set(vm, VM_IO | VM_DONTEXPAND | VM…

How do you know it didn't search the web?

no tool calls!

Re: A 0-click exploit chain for the Pixel 10

#80

Post by codedokode »

IshKebab wrote: post #28
codedokode wrote: post #7

I read about Pixel 9 Dolby Decoder bug, and it is based on integer overflow. It was a mistake to allow "+" operator to overflow, and this must be fixed in new languages like Rust, but it is not.

It isn't because no ISA implements add like that, so there's always performance on the table if you check every time, and people would probably endlessly moan about how Rust is 20% slower than C on this add-heavy microbenchmark. That said you can enable overflow checks in Rust's release mode. It's literally two lines: [profile.release] overflow-checks = true I wonder if it would make sense for ISAs to have trapping v…

I think it is 3 extra instructions on RISC-V if you add signed numbers. So 1 addition (the most popular operation) turns into 4 instructions. What are those people thinking? I generally like RISC-V but this part in my opinion, is wrong. They should just have added "overflow enabled" bit to the add instruction.
Post reply on HN