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.

Comments

Only as safe as the sandbox

[Anonymous Coward]

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?

Re:Only as safe as the sandbox

[mandolin]

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!

Re:Only as safe as the sandbox

[Anonymous Coward]

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.

Re:Only as safe as the sandbox

[Anonymous Coward]

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.

Re:Only as safe as the sandbox

[Cyberax]

Java bytecode confinement is fairly safe. But the security model for the sandbox was a disaster, basically full of "become root" classes because it relied on poorly thought-out "code access security". Rust's security model is much simpler - it was not designed to contain untrusted code, but to make sure that trusted code is not going to blow up.

Re:Only as safe as the sandbox

[whh3]

I wish I had mod points to recommend this. Thank you for writing so succinctly about how the "safety" of Rust is not based on a runtime sandbox but rather on compile-time analysis that determines which operations are inherently unsafe and which are safe. While Rust advocates compare their safety constructs with those that Java attempts to provide, they are achieved completely differently. Thanks again for pointing this out.

Re:Only as safe as the sandbox

[serviscope_minor]

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.

Re:Only as safe as the sandbox

[garethjrowlands]

> That so only true if the compiler and run-time system do not have bugs.

We can be certain there are no bugs in Rusts run-time system because it doesn't have one.

It's true that the compiler needs to be correct but that's true of all compilers. Rust is a clean, modern design and the critical parts of the compiler are fairly small, so the Rust compiler's chances of generating correct code are pretty good, even compared with much more mature C compilers.

Re:Only as safe as the sandbox

[dos1]

Rust doesn't do anything magical to the security of programs written in it. Rust simply won't allow you to compile quite a lot of vulnerable programs that would be happily compiled by a C compiler, because the language is a lot stricter in terms of memory and thread safety.

Also, "safety" of Rust actually requires you to be rather more than less competent. There's a rather steep learning curve, less competent coders will struggle (and learn a lot in the process) just by trying to come up with a code that will be finally accepted by the compiler. Rust doesn't provide safety by holding your hand and doing stuff for you - it's more like a strict parent that sets up boundaries of how you can play, so you won't hurt yourself, but otherwise leaves you alone.

Of course it doesn't mean that you can't write vulnerable code in Rust. It's just a bit harder to do it by accident for some class of potential issues.

Re:Only as safe as the sandbox

[serviscope_minor]

That so only true if the compiler and run-time system do not have bugs

Well the Rust runtime is provably bug free. The proof is pretty trivial: it doesn't have a runtime.

How well that assumption holds up in practice can be seen in other languages.

How many other languages out there get the safety through the type system rather than other mechanisms like sandboxing? A sandbox for a complete and growing system is a much larger attack surface than the relatively small surface of the compiler.

For the language to be insecure, there are basically 3 classes of bug:
1. There's a bug in the type system.
2. The compiler has a bug and allows invalid programs from (1) to compile.
3. It generates incorrect code in a way that's exploitable

The thing is, a C compiler is just as likely to have those bugs, especially the largest, 3, and doubly so since the Rust backend shares an optimizer with a popular C compiler.

And, because they are "safer", languages with safe memory usually come with less competent coders, which often nicely eliminates any advantage gained.

There's two things wrong with that. First you're comparing an average based on social factors to whether a specific program with a specific team will have bugs, which is a false comparison.

Secondly, Rust does not relieve you of the burden of thinking about memory (like say, Javam C#), it forces you to think very hard about it and won't compile if you think about it wrong.

My prediction is that Rust will do nothing security-wise as soon as attackers actually start to attack it.

Compared to C? I think that's unlikely because Rust is basically like C and C++ in machine model, but with several rich sources of bugs more or less removed.

Re:Only as safe as the sandbox

[mvdwege]

<citation needed>

Self-proclaimed expertise does not correlate well with actual expertise, and Ada seems to be doing quite well in its domains of highly-secure and embbeded software. In fact, it's having a bit of resurgence.

Those who do vocally hate on it seem to be the kind of cowboys that run after every new fad, the sort of programmers you wouldn't trust to code the right way to implement an automatic toilet seat.

(Side note: let's see who spots the reference in that last paragraph.)

Re:Who but Mozilla?

[Rexdude]

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.

Re:rust community

[NotInHere]

Nope, in fact its the opposite. Thanks to its ownership model, Rust eliminates most of the ugly access bugs that you might run into if you do multithreading. It puts the information whether something needs to be locked before being accessed, or whether its totally threadsafe into the type system, so that the compiler can verify everything is working as you intended it.

Of course, its not perfect, but rust is one of the languages you might want to start your multithreaded program in. It doesn't save you from thinking about the problems, but if you got it wrong, it won't compile. There are still bugs, but none that fall into the category C++ would describe as "undefined behaviour" (and those are many times the reasons for the most evil security bugs AND the hardest to debug).

Re:Who but Mozilla?

[Anonymous Coward]

More bullshit.
Always the trolling on Mozilla posts. IT is so old and frankly untrue.

Re:Who but Mozilla?

[Anonymous Coward]

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".

Re:Oh, that's just jolly

[arglebargle_xiv]

It really depends on where the rust occurs. If it's just on the panelling or in the chrome then you can sand it down and repaint, but if it's structural rust you're pretty much hosed. Time to switch to Pale Moon, which hasn't started rusting yet.

Re:Oh, that's just jolly

[ChunderDownunder]

Well if Slashdot had linked the Mozilla blog post instead of some random softpedia clickbait, you might have read where they are working with distros to incorporate the rust toolchain.

We have active discussions from the Rust side on getting the rust compiler into all of the major Linux distributions. There's definitely some complexity there, but the Rust community is working hard on doing it before Firefox would require Rust to build by default.

Re:rust community

[KermodeBear]

You're kidding me, right?

Please tell me that you're joking.

If this is true, I really have zero desire to learn the language. Anything swamped by the disaster of political correctness is, quite frankly, just not worth the trouble. If I'm going to use standard computer science terminology and get whined at because the same word means something not-warm-and-fuzzy in a totally different context, then I'm out.

just because it can't happen doesn't mean it won't

[Anonymous Coward]

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".

Rust?

[QuietLagoon]

Unwanted iron oxide that is usually scraped away?

Re:Who but Mozilla?

[TangoMargarine]

For anyone interested in numbers, I threw together a rough timeline:

47.9% July 2009 3.5 - peak Firefox usage
46.4% July 2010 4
42.0% July 2011 9
        FF12 - final release to support Windows 2000 and Windows XP RTM & SP1
        FF15 - automatic silent updates
33.7% July 2012 17
        FF19 - built-in PDF viewer
        FF20 - replacement download manager
        FF21 - Social API "multiple providers"
        FF23 - no more <blink>, new logo, JavaScript permanently enabled, can't keyword-search in URL bar
28.9% July 2013 26
        FF27 - more Social API
        FF29 - Australis, no add-on bar
        FF30 - disable most plugins by default
        FF31 - first Australis ESR; previous ESR automatically updated to this version Oct 2014
24.9% July 2014 34
        FF38 - Pocket integration
21.3% July 2015 39
        FF40 - touchscreen/Australis improvements, extension signing mandatory in future
        FF45 - Tab Groups removed
16.9% May 2016

So by now the lost percentage points have probably crossed the 2/3rds point.

http://www.w3schools.com/brows...