6 ms·

I read the Android team is trying to secure Android by writing new code in Rust. I am wondering how many of these issues would go away by using Rust or at least

I read the Android team is trying to secure Android by writing new code in Rust. I am wondering how many of these issues would go away by using Rust or at least minimized to easier to audit unsafe blocks. Obviously it might take them 10x the effort to write the code on Rust and to integrate that into Chrome, but the security effort shown here has a large cost as well.

Cloudef 3y ago
Theres wgpu if you have hard on for rust webgpu implementation. Also zig implementation called dusk (very early)
- pjmlp 3y ago
  Zig still has UAF problem.
bionhoward 3y ago
Seems like the first two issues would be harder to encounter in rust (raw pointers and double mutable borrows) but rewriting a huge project is a bad idea because of the massive amount of work involved. The maintainers could make a crate for some tiny crucial vulnerable subsystem and call it from c++, that might be more reasonable baby step and get them rolling with rust inside chrome (as opposed to chrome inside rust which would possibly take forever, some dork can crank a little rust program in a weekend) Also automatic rewriting the whole codebase could work but that’s just a research direction at this point even for google as far as I know, and chrome probably isn’t the kind of thing you just auto-rewrite and it works right away (maybe I’m pessimistic)
- galangalalgol 3y ago
  I think you are correct to suggest starting from small important pieces. I propose the attack surfaces and working out from them. The dom, and sandbox as a whole seems like a prime candidate.
- nicoburns 3y ago
  There is at least already a WebGPU implementation in Rust (the one that Firefox uses). So they could use that if they wanted to. I guess it's probably better for the overall health of the ecosystem if there are multiple implementations though.
  - tormeh 3y ago
    Yup, wgpu is already a thing. While it's ironically widely used on desktop, it's less mature in the browser context. Like, there is an open-world 3D MMORPG using wgpu for its graphics, meanwhile it's not yet enabled on stable Firefox. I'm not sure whether many different implementations is inherently good, though.
    - nabakin 3y ago
      What MMO?
      - i_am_a_peasant 3y ago
        I think he means Veloren.
      - tormeh 3y ago
        https://veloren.net/ https://veloren.net/ I'm a bit impartial since I'm a former contributor, but I think it's super cool. Aside from that, the Bevy game engine also uses wgpu on non-web, but afaik no game of particular significance or player base has shipped with it yet. I think the biggest user of it is actually a software tool for mining (the hardhat kind), but it's a "call us for a quote" kind of thing so hard to tell how big it is.
        i_am_a_peasant 3y ago
        wgpu I think might be finally an OpenGL killer. It's more platform independent than any graphics API ever dreamt of being.
- pjmlp 3y ago
  Initially the Chrome team was the opinion that adding Rust to Chrome would be a too big effort and thus focusing on better practices for C++ would be a better approach, hence Olipan, the C++ GC now introduced in V8. Eventually about an year later they changed their mind, and are now allowing Rust for new code in Chrome, in a kind of baby steps. Most likely, because as the report shows, no matter how carefully the code is written and reviewed, there are security flaws due to memory corruption sneaking in.
- logicchains 3y ago
  >Also automatic rewriting the whole codebase could work but that’s just a research direction at this point even for google as far as I know, and chrome probably isn’t the kind of thing you just auto-rewrite and it works right away (maybe I’m pessimistic) GPT4 is extremely good at translating between programming languages without error. The hard part is there's way to much code to feed to it all at once, so the naive approach of just feeding it all in wouldn't work, and doing it file-by-file would cause problems as GPT wouldn't understand the functions defined in other files.
  - hutzlibu 3y ago
    Even if you could feed ChatGPT4 with all of chromiums codebase, I really, really doubt it would just work. Otherwise it would be just a matter of scaling and waiting longer.
  - nmfisher 3y ago
    I doubt this would work (at least with the current version of GPT4). I tried the same thing last week (Swift to Kotlin) and there were so many errors the whole exercise was pointless. Claude fared better, but I wouldn’t bother doing it again.
nvm0n2 3y ago
Wouldn't help in this case, the bugs are in things that Rust's type system doesn't help you with like references being held across processes that are sharing memory segments, connected to GCd JavaScript heaps. Affine types aren't able to express that stuff.
- alexvitkov 3y ago
  You're overthinking it. The rust argument often boils down to: Rust = Safety. Those things sound unsafe, therefore Rust solves them.
- insanitybit 3y ago
  At least some of the issues here appear to be UAFs where raw pointers are taken to RC'd objects under the assumption that the object will not be freed while the raw pointer is held. That is not possible to express in Rust (without unsafe). Some other issues are definitely going to be trickier - for example, passing a raw pointer to another context and then crashing that context while it's still held. This has come up within Rust before - how do you handle `&str` backed my mmap when another process could write to those values. And then some are... maybes. Integer underflow panics in tests but not in release - when mixing it with something inherently unsafe like alloca, would Rust have helped? IDK. Certainly I think integer overflows are less likely to make it to release in Rust thanks to the default behavior, but it's also absolutely an area where I expect Rust to do only a bit better than other languages.
- Rusky 3y ago
  Cross-process shared memory doesn't really make a difference here. Rust's support for multithreading works the same way regardless, there's no expressivity problem.
  - insanitybit 3y ago
    x-process shared memory is definitely a problem. This has come up before - ex: is it safe to hold a &str into an mmap'd page? Another process could modify the data such that it is no longer valid utf8, even though you held a reference to it. This is just out of scope for the borrow checker. Instead you'll have to roll your own abstraction that tries to maintain its own invariants, such as a &MmapStr that doesn't perform any `unsafe` operations that assume utf8/ immutability.
wffurr 3y ago
Already happening but the timeline is too late for Dawn (the Chrome WebGPU implementation): https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html https://security.googleblog.com/2023/01/supporting-use-of-ru...
deleted 3y ago
[deleted]

Cloudef 3y ago

Theres wgpu if you have hard on for rust webgpu implementation. Also zig implementation called dusk (very early)

pjmlp 3y ago
Zig still has UAF problem.

bionhoward 3y ago

Seems like the first two issues would be harder to encounter in rust (raw pointers and double mutable borrows) but rewriting a huge project is a bad idea because of the massive amount of work involved. The maintainers could make a crate for some tiny crucial vulnerable subsystem and call it from c++, that might be more reasonable baby step and get them rolling with rust inside chrome (as opposed to chrome inside rust which would possibly take forever, some dork can crank a little rust program in a weekend) Also automatic rewriting the whole codebase could work but that’s just a research direction at this point even for google as far as I know, and chrome probably isn’t the kind of thing you just auto-rewrite and it works right away (maybe I’m pessimistic)

galangalalgol 3y ago
I think you are correct to suggest starting from small important pieces. I propose the attack surfaces and working out from them. The dom, and sandbox as a whole seems like a prime candidate.
nicoburns 3y ago
There is at least already a WebGPU implementation in Rust (the one that Firefox uses). So they could use that if they wanted to. I guess it's probably better for the overall health of the ecosystem if there are multiple implementations though.
- tormeh 3y ago
  Yup, wgpu is already a thing. While it's ironically widely used on desktop, it's less mature in the browser context. Like, there is an open-world 3D MMORPG using wgpu for its graphics, meanwhile it's not yet enabled on stable Firefox. I'm not sure whether many different implementations is inherently good, though.
  - nabakin 3y ago
    What MMO?
    - i_am_a_peasant 3y ago
      I think he means Veloren.
    - tormeh 3y ago
      https://veloren.net/ https://veloren.net/ I'm a bit impartial since I'm a former contributor, but I think it's super cool. Aside from that, the Bevy game engine also uses wgpu on non-web, but afaik no game of particular significance or player base has shipped with it yet. I think the biggest user of it is actually a software tool for mining (the hardhat kind), but it's a "call us for a quote" kind of thing so hard to tell how big it is.
      - i_am_a_peasant 3y ago
        wgpu I think might be finally an OpenGL killer. It's more platform independent than any graphics API ever dreamt of being.
pjmlp 3y ago
Initially the Chrome team was the opinion that adding Rust to Chrome would be a too big effort and thus focusing on better practices for C++ would be a better approach, hence Olipan, the C++ GC now introduced in V8. Eventually about an year later they changed their mind, and are now allowing Rust for new code in Chrome, in a kind of baby steps. Most likely, because as the report shows, no matter how carefully the code is written and reviewed, there are security flaws due to memory corruption sneaking in.
logicchains 3y ago
>Also automatic rewriting the whole codebase could work but that’s just a research direction at this point even for google as far as I know, and chrome probably isn’t the kind of thing you just auto-rewrite and it works right away (maybe I’m pessimistic) GPT4 is extremely good at translating between programming languages without error. The hard part is there's way to much code to feed to it all at once, so the naive approach of just feeding it all in wouldn't work, and doing it file-by-file would cause problems as GPT wouldn't understand the functions defined in other files.
- hutzlibu 3y ago
  Even if you could feed ChatGPT4 with all of chromiums codebase, I really, really doubt it would just work. Otherwise it would be just a matter of scaling and waiting longer.
- nmfisher 3y ago
  I doubt this would work (at least with the current version of GPT4). I tried the same thing last week (Swift to Kotlin) and there were so many errors the whole exercise was pointless. Claude fared better, but I wouldn’t bother doing it again.

nvm0n2 3y ago

Wouldn't help in this case, the bugs are in things that Rust's type system doesn't help you with like references being held across processes that are sharing memory segments, connected to GCd JavaScript heaps. Affine types aren't able to express that stuff.

alexvitkov 3y ago
You're overthinking it. The rust argument often boils down to: Rust = Safety. Those things sound unsafe, therefore Rust solves them.
insanitybit 3y ago
At least some of the issues here appear to be UAFs where raw pointers are taken to RC'd objects under the assumption that the object will not be freed while the raw pointer is held. That is not possible to express in Rust (without unsafe). Some other issues are definitely going to be trickier - for example, passing a raw pointer to another context and then crashing that context while it's still held. This has come up within Rust before - how do you handle `&str` backed my mmap when another process could write to those values. And then some are... maybes. Integer underflow panics in tests but not in release - when mixing it with something inherently unsafe like alloca, would Rust have helped? IDK. Certainly I think integer overflows are less likely to make it to release in Rust thanks to the default behavior, but it's also absolutely an area where I expect Rust to do only a bit better than other languages.
Rusky 3y ago
Cross-process shared memory doesn't really make a difference here. Rust's support for multithreading works the same way regardless, there's no expressivity problem.
- insanitybit 3y ago
  x-process shared memory is definitely a problem. This has come up before - ex: is it safe to hold a &str into an mmap'd page? Another process could modify the data such that it is no longer valid utf8, even though you held a reference to it. This is just out of scope for the borrow checker. Instead you'll have to roll your own abstraction that tries to maintain its own invariants, such as a &MmapStr that doesn't perform any `unsafe` operations that assume utf8/ immutability.

wffurr 3y ago

Already happening but the timeline is too late for Dawn (the Chrome WebGPU implementation): https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html https://security.googleblog.com/2023/01/supporting-use-of-ru...

deleted 3y ago

[deleted]