Slashdot Mirror
Mozilla Will Ship Its First Rust Component In Firefox 48 (softpedia.com)
An anonymous reader quotes a report from Softpedia: Mozilla announced today plans to ship its first ever Rust code with the production releases of Firefox. The first ever Rust components will arrive in Firefox 48, scheduled for release on August 2, 2016. After teasing Rust features last year, the Mozilla Foundation announced today that Firefox 48 would contain a new media stack component that's entirely coded in Rust. The first Firefox component to feature Rust code was not chosen at random because media components often execute malicious code when parsing multimedia files. "This makes a memory-safe programming language like Rust a compelling addition to Mozilla's tool-chest for protecting against potentially malicious media content on the Web," says Dave Herman, Director of Strategy at Mozilla Research. During tests of this Rust-based media component in Firefox's unstable builds, Mozilla says that after one billion uses they have yet to see a crash or issue in the Rust media component. Last month, Mozilla released the first versions of Servo, a minimal browser created in Rust code alone. At around the same time, Microsoft open-sourced Checked C, an extension to the C programming language that brings new features to address a series of security-related issues.
Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?
Good question.
My guess is that running untrusted Java code in a trusted Java sandbox has a much larger attack surface than playing untrusted media in a (more or less) trusted Rust app.
The Rust code should still be an improvement, safety-wise, over the current C/C++ solution.
That does not mean the Rust solution will be perfect, and it *definitely* doesn't mean you should download and run untrusted Rust apps!
Rust does not derive its safety from a runtime sandbox, but from static guarantees enforced by its type system. This prevents memory errors that often lead to arbitrary code execution vulnerabilities, but it does not attempt to enforce higher-level semantic security properties, e.g. if you blindly use an untrusted string as a filename, you can still be tricked into opening /etc/passwd. Rust does not inherently protect you there, nor is it advertised as doing such.
Rust isn't run in a sandbox. It's like C++. It simply has some assurances that the code it compiles should be free of some classical problems that plague software development in systems languages, without it also sacrificing the close-to-bare-metal aspects of languages like C++, and with much more of the costs involved being pushed to the compilation phase than the runtime phase. That's much more than the likes of Java have tried to offer, and it's also why so many people love to bash on it: it's hard to buy into the assurances without enough time passing, and it's made by a relatively small company that's popular to bash on right now.
Mozilla is no longer what it used to be - one that placed users first. All they've been doing is dicking around with the UI, and getting rid of all the customizability that attracted people to it in the first place(XUL and XPCOM support is going away - so many popular extensions that modify the interface and add features are going to go away), to make it a pale copy of Chrome. The only browser today that follows the charter of the original Mozilla is Pale Moon, which was forked off Firefox 24 and will continue to support XUL and proper extensions, and provide a full blown desktop UI instead of a dumbed down touchscreen/mobile friendly one.
"..One hosts to look them up, one DNS to find them, and in the darkness BIND them."
Pale Moon is only worth it if you want to keep using obsolete tech. It's otherwise no better than Firefox, and has not improved significantly since its inception. It has already broken compatibility with more addons than Firefox did. It will either break compatibility with the obsolete tech you list in your post, or it will continue its slow downward spiral into irrelevance. It simply doesn't have the development community to be its own browser, and once Mozilla (rightly) stops supporting those outdated legacy things, you'll be SOL. Unless of course Pale Moon's community starts to actually pitch in beyond silly PR campaigns that overrate Pale Moon and poo-poo Firefox for "leaving them behind".
That does not mean the Rust solution will be perfect, and it *definitely* doesn't mean you should download and run untrusted Rust apps!
Yes. Rust isn't a sandbox, it's a programming language with memory safety built into the type system. A rust program can do whatever it wants to your system if you don't sandbox it yourself. On the other hand, whole nasty classes of bugs related to buffer overflows, stack smashing and data races cannot happen, which makes it harder to attack from the outside than C.
It says nothing about whether you should trust a particular rust program to not be malicious.
SJW n. One who posts facts.
I think the most valuable point to make is that by abstracting buffers in a meaningful way, when hackers eventually figure out how to get past the protection mechanisms... probably by stepping through the rust compiler to find loopholes, a single patch should fix all instances of the vulnerability.
Also, it should protect against code injection attacks, but it doesn't mean it's a silver bullet. It should still be possible to cause browser crashes due to I handled memory exceptions. Consider an H.264 decoder which makes a large number of branch decisions. Intentionally malicious H.264 data can still cause crashes due to OOM because of long frame sequences that could require the decoder buffers 500 seconds of frames for prediction.
Also, even when coding in Rust, optimization will be an issue. For application code, no problems. But for decoding images and video, decisions will be made to optimize code which can be performance lethal. If buffer checks are performed every time bits are decoded from the entropy coding mechanism, it could take a LONG time to decode all the bits of a frame. So, programmers will start using C or Assembler (as they always do) to optimize this code.
Consider that modern browsers also require encoders and performance of a heavily memory checked language will kill it. Even today x264 can't handle real-time with any quality for 4K video on most CPUs and Intel's hardware encoders are extremely poorly optimized for I and P only encoding as required for conferencing.
The language is certainly not a silver bullet. It's a piece of the solution. What worries me is the crazy thought process people will have about "I'm using Rust, I don't have to think about memory anymore".