Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Firefox Mozilla Programming Communications Media Microsoft Network Networking Operating Systems Software The Internet Build

Mozilla Will Ship Its First Rust Component In Firefox 48 (softpedia.com) 167

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.
This discussion has been archived. No new comments can be posted.

Mozilla Will Ship Its First Rust Component In Firefox 48

Comments Filter:
  • by 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?

    • by mandolin ( 7248 ) on Tuesday July 12, 2016 @11:15PM (#52502099)

      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!

      • by serviscope_minor ( 664417 ) on Wednesday July 13, 2016 @02:08AM (#52502515) Journal

        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: (Score:2, Interesting)

          by gweihir ( 88907 )

          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.

          That so only true if the compiler and run-time system do not have bugs. How well that assumption holds up in practice can be seen in other languages. And, because they are "safer", languages with safe memory usually come with less competent coders, which often nicely eliminates any advantage gained.

          My prediction is that Rust will do nothing security-wise as soon as attackers actually start to attack it. Initially, it will of course seem to improve things, because attackers will not invest the time to find o

          • by garethjrowlands ( 694510 ) on Wednesday July 13, 2016 @05:59AM (#52502897)

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

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

              All languages these days have *some* kind of runtime system. Even if it's just a set of low-level trusted primitives. But the important thing is that it has to be small and not try to do everything.

            • by gweihir ( 88907 )

              And here we see the cluelessness of the Rust-proponents in all is glory: Unless you do bare-metal assembly, you do have a run-time system. This does not mean an interpreter or a the like, the standard libraries already form a runtime system. And yes, Rust does have one.

          • Re: (Score:3, Insightful)

            by dos1 ( 2950945 )

            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 wil

            • Rust doesn't do anything magical to the security of programs written in it.

              Isn't it the case that Rust allows for implementations with language-enforced isolation of code domains? Because if it is, I'd definitely say it's big for security of highly performant programs, because you should be able to run foreign code (mobile code, for example?) in the same memory space, including cross-module optimizations, with (a part of) the language spec serving as your security kernel.

          • 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

            • by mvdwege ( 243851 )

              How many other languages out there get the safety through the type system rather than other mechanisms like sandboxing?

              I know of one: Ada. And it has a well-deserved reputation for safety.

              • I know of one: Ada. And it has a well-deserved reputation for safety.

                Indeed! Typesystem based safety is much better than unsafe + sandbox.

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

              Judging from this [rust-lang.org], it actually *does* have a runtime, in two forms: partly in form of some routines (used by some programs), partly in form of compiler transforms/IR operations (used by *all* programs) that securely inline some sensitive tasks into the program in a way that a library can't. Just like, for example, some Lisp implementations inline low-level memory operations even into higher-level programs to speed them up without sacrificing safety. So the problem is effectively the same: a finite set of p

              • by gweihir ( 88907 )

                My guess is that all the other proofs showing Rusts superiority are of similar quality: Simple, elegant and wrong. Reality is messy, and ignoring that will not make the messiness go away.

          • by Sloppy ( 14984 )

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

            Ah, the nobody can make things better argument, because if you improve things, someone will (should!) use up the extra slack they're given. You're basically arguing that software needs to have a certain amount of bugs, because if it has too few, the programmer market is being inefficient by not cranking out shittier code faster/cheaper.

            I don't buy it. I think

            • by gweihir ( 88907 )

              You are missing one critical effect here that happens to basically all technologies: At some point they have realized their full practical potential and any more "evolution" makes them less beneficial. Examples: Flying cars, tablets as replacement for pen&paper, video-telephony, the hypeloop, electronic locks, etc. The list is really endless and the proponents of these things always display the same amount of fanaticism, faulty thinking and lack of insight into the problem being targeted.

              But really, tha

              • by Sloppy ( 14984 )

                you should be old enough to have seen a number of "magic" new languages, tools and coding techniques only to have them all fall flat on their faces.

                Of course I've seen plenty of failures and stupid ideas! I don't see that (or your cherry-picked list) as important, though. In any human endeavor if you're around long enough, you'll see that happening. I'm sure in 4999 BC some numbnuts or con-artist had a really stupid idea about how to make farming work better. I don't care about him. Lots of people try thin

        • by 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

          • by Anonymous Coward

            The choice to use Rust for the media stack may indicate that the performance concerns you mention aren't a problem in practice, or at least that the cases where it's a problem can be nested inside an unsafe{} block without significant concern.

            Most of rust's sanity checking happens at compile time, so the performance cost should be 0 in those cases. There's no runtime. It does bounds checking on arrays by default, but those are optimized out if you use iterators or if the compiler can prove that the index is

          • ... "I'm using Rust, I don't have to think about memory anymore".

            Rust is a low level language that forces you to think about memory. It's like a modern C. You can see for yourself how much of the Rust manual deals with memory management. In particular this page shows how the Rust stack and heap are the same as in C: https://doc.rust-lang.org/book... [rust-lang.org] . The thing Rust has over C is a type system that eliminates common classes of bug.

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

            I can't imagine anyone who's used rust actually saying that. If you don't think about memory hard enough, the Rust compiler will whine horribly and won't compile your program. That's one of the biggest complaints about it AFAICT!

        • It's technically equivalent to a sandbox, but sandboxes work, which is why Rust works. Just because X can also be done badly doesn't mean that X can't be done well, too.
        • by Raenex ( 947668 )

          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.

          That's not true because of the unsafe [rust-lang.org] escape hatch and raw pointers [rust-lang.org]. It's an improvement over C/C++ by having a safe default, but you can still shoot yourself in the foot.

          • It depends. Features like Rust's "unsafe" or Oberon's imports of the SYSTEM module can at least be watched for (and banned in a project) since their use is blindingly obvious. The raw pointer stuff seems kind of more worrisome. I find its very presence peculiar.
            • by Raenex ( 947668 )

              The raw pointer stuff seems kind of more worrisome. I find its very presence peculiar.

              Raw pointers can only be used in code labeled "unsafe".

    • by Anonymous Coward on Tuesday July 12, 2016 @11:18PM (#52502107)

      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.

    • by Anonymous Coward on Tuesday July 12, 2016 @11:24PM (#52502121)

      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.

      • by whh3 ( 450031 )

        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.

      • by e r ( 2847683 )
        Considering that C, C++, and Rust all compile to machine code I think you should say "bare-metal" not "close-to-bare-metal".
    • by Cyberax ( 705495 ) on Tuesday July 12, 2016 @11:48PM (#52502205)
      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.
    • 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?

      Maybe because Graydon Hoare designed it, the same guy who did Monotone, the ancestor of Git. Something about the Sun/Gosling attitude to systems design, seems like a lot of lather and little substance.

      • by lucm ( 889690 )

        I don't know, man. I googled a picture like I always do when I come across the name of someone who's supposed to be big, and that guy looks like a dentist that had a psychotic break and turned into a serial killer. Based on that I don't trust him, or rust.

        • You come across as a bit on the psycho stalker side yourself.

          • by lucm ( 889690 )

            You come across as a bit on the psycho stalker side yourself.

            Totally uncalled for. I haven't received a single restraining order in July so far, there was just this tiny incident with the 7-11 guy and the cops said it wasn't really stalking.

    • by gweihir ( 88907 )

      There is no reason to assume that Rust would be any better. But the egos of the Rust-people are much bigger, so they make bolder claims.

    • by dmpot ( 1708950 )

      Rust does not aim to provide you a sandbox to run untrusted code. Its goal is to provide type safety. It means that code written in Rust is as safe as written in Python or in another high-level language, but it runs as fast as if it were written C++.

      Obviously, it could be bugs in the Rust compiler or an unsafe library that you use, but the attack surface is much smaller in this way. Take a look at programs written in high-level languages, you do not hear about buffer overflow and other low-level attacks ag

    • 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?

      This isn't even wrong. The media component needs to be free of bugs/vulnerabilities, not execute untrusted code.

      The better comparison is with C because if the media component wasn't written in Rust, it would be written in C. Memory safety is the safety-critical attribute that Rust and Java have that C lacks. This is not the same as a sandbox. Sandboxes are indeed important in browsers - Chrome and Edge/IE have them and Firefox's sandbox (Electrolysis) is under active development. Rust is a low level languag

    • 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?

      You don't know what you are talking about. Rust is built to make avoid memory leaks and buffer overflows. It does a good job at that.

      Java doesn't have a problem with memory overflows, either, but you got confused between the plugin and the language. The Java language was fine, the plugin (with its sandbox) had problems.

  • rust community (Score:1, Offtopic)

    by Anonymous Coward

    Too bad the Rust community is so toxic. Can't call a process a slave, it has to be a "follower".

    • by Anonymous Coward

      People at my work went through the same discussions. Wtf. We aren't talking about humans here, these are machines. Should we rename the kill command too?

      • by Anonymous Coward
        The first politically correct programming language. I hope there are more. However, I believe it should also reference more African American history and use African nomenclature. It will be much better than that racist Perl language.
        • You genuinely cannot see that this language is actually not neutral either. Of course the machine doesn't care but keeping politically saturated terms puts them on life support too. I am not necessarily in favor of this move but it has merit.
        • To have a politically correct programming language, we should also take care of replacing the "do" loop controlling statement with something less imperative, like "could you", "please compute", and so on.
      • by Anonymous Coward

        Got me thinking of the IDE days of master and slave drives. Oddly enough never once thought of slavery in the process of using that terminology, just automatically associated it with the technological meaning.

      • Re: (Score:1, Funny)

        by Anonymous Coward
        Yes, "kill -9" should be replaced by "kill --muslim"
    • by guruevi ( 827432 )

      Rust has multicore capabilities now? I thought that proper multi threading didn't fit into their "safety" models and requires ugly hacks.

      • Re:rust community (Score:5, Interesting)

        by NotInHere ( 3654617 ) on Tuesday July 12, 2016 @11:55PM (#52502221)

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

        • by Mokki ( 125575 )

          If we define what untrusted code to mean random binary/library from internet that your program downloads at runtime and then executes.

          Rust/C++ have no support for limiting what harm that random binary code does. It can do anything and any Rust/C++ compile time protections are moot because the downloaded binary/library is not compiled or checked against the expectations.
          Java sandbox (mostly used by applets) is an attempt to allow downloading binary (compiled java classes) from external source and limiting wh

          • Java (and other languages running in virtual machines or interpreters) provides the most protections

            Yes, java provides lots of protections, but those protections come with a cost, that's paid by java at runtime. Rust provides the same level of protection, but it offers it at native speed (well, not 100% the same as C++, e.g. array access is always checked, so you should use iterators, they do O(1) many checks).

            Generally only cases where safe code is calling to existing buggy C library for the data processing (for example image handling) can it untrusted input become a problem.

            Same goes for Rust. The difference is though that you can actually write performant image decoders in Rust, while you have a hard time with Java (its entirely possible to write them, they just wont

    • Re:rust community (Score:4, Insightful)

      by KermodeBear ( 738243 ) on Wednesday July 13, 2016 @01:29AM (#52502445) Homepage

      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.

      • Re: (Score:1, Flamebait)

        by gweihir ( 88907 )

        Indeed. A tech-community that allows SJWs to dictate terminology to them is weak and not worth being part of in the first place. At least they signal to anybody with a clue that they are broken in the head early on.

    • Re: (Score:2, Insightful)

      by gweihir ( 88907 )

      It is a special class of idiots that focus on irrelevant side-issues while solving a hard technological problem. A "follower" and a "slave" are also different concepts, so they are mangling technological terminology with their Newspeak. Better stay away from these people, they are not engineers at heart.

  • I really hate seeing Mozilla getting "rusty"!!!

  • Who but Mozilla can we trust to protect our privacy? Everyone else seems to want to profit in one way or another.

    • Re: (Score:2, Informative)

      by Rexdude ( 747457 )

      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 [palemoon.org], which was forked off Firefox 24 and will conti

      • Re: (Score:2, Insightful)

        by Anonymous Coward

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

      • Re:Who but Mozilla? (Score:5, Informative)

        by Anonymous Coward on Wednesday July 13, 2016 @12:15AM (#52502275)

        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: (Score:2, Interesting)

          It's otherwise no better than Firefox, and has not improved significantly since its inception.

          Don't fix what ain't broke. Pale Moon has unfucked the Firefox interface, which is a big improvement in my book.

          It has already broken compatibility with more addons than Firefox did.

          A) They've got a whole library of fixed extension for ones that are broken.
          B) Firefox is jettisoning their entire extension system anyway in the near future so it's not like they'll be any better.

          or it will continue its slow downward spiral into irrelevance

          Are we talking about PM or FF? Have you looked at your user figures recently?

          and once Mozilla (rightly) stops supporting those outdated legacy things

          You mean the things you're ripping PM for not supporting in this very same post?

          It's rather interesting that all these posts ar

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

        • What's wrong with having Pale Moon and Firefox installed side-by-side? Yes, it's a pain, but it's what I deal with to prevent the likes of Google and friends from reading over my shoulder in ways they refuse to disclose.

          I use Pale Moon as my main browser, and Firefox for development. The only extensions I need for my main browser are my ad blocker and script blocker, and I'm pretty sure those will work well with Pale Moon for many years to come. Since I don't have to restart Pale Moon every 10 minutes du

      • by Anonymous Coward

        Pale Moon is obsolete. Already it struggles with Javascript-heavy sites like Google Maps and it has hacks to get around sites that (correctly) detect it as out of date. It's only a matter of time until it becomes unusable on the modern Web.

  • Which is that JavaScript is toxic and MUST be replaced. You remove JavaScript from the equation? Suddenly all the nasties just disappear.

    So I really don't care what language they write their video player or whatever in because until we deal with the rotting elephant carcass that is JavaScript I just don't see this change doing jack squat in the long run.

    • by gweihir ( 88907 )

      While I agree that JavaScript is a horrible abomination, so much "enterprise" code these days depends on it that it will take a very long time to go away.

  • by QuietLagoon ( 813062 ) on Wednesday July 13, 2016 @08:22AM (#52503291)
    Unwanted iron oxide that is usually scraped away?
  • version of FF that we should skip?

  • Firefox routinely crashes on my OSx so much so I have abandoned it.

  • The only language whose name admits that it's out of date the day it's released.

Chairman of the Bored.

Working...