Slashdot Mirror

← Back to Stories (view on slashdot.org)

Vulnerability In Font Processing Library Affects Linux, OpenOffice, Firefox (softpedia.com)

Posted by timothy on from the well-stop-using-fonts dept.

An anonymous reader writes: If an application can embed fonts with special characters, then it's probably using the Graphite font processing library. This library has several security issues which an attacker can leverage to take control of your OS via remote code execution scenarios. The simple attack would be to deliver a malicious font via a Web page's CSS. The malformed font loads in Firefox, triggers the RCE exploit, and voila, your PC has a hole inside through which malware can creep in.

9 of 95 comments (clear)

  1. Current version of Firefox is not vulnerable by Anonymous Coward · · Score: 5, Informative

    Known Vulnerable Versions:
    Libgraphite 2-1.2.4
    Firefox 31-42

    source: http://blog.talosintel.com/2016/02/vulnerability-spotlight-libgraphite.html

    1. Re:Current version of Firefox is not vulnerable by Anonymous Coward · · Score: 3, Informative

      Yes, Firefox fixed this issue in 44.0.2, released last Thursday. Weirdly, when I checked that page Thursday it did not mention a thing about the graphite vulnerability. It was added today: https://www.mozilla.org/en-US/...

    2. Re:Current version of Firefox is not vulnerable by buchner.johannes · · Score: 5, Informative

      in the meantime, you can set gfx.font_rendering.graphite.enabled to False

      --
      NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
    3. Re:Current version of Firefox is not vulnerable by BZ · · Score: 3, Informative

      Firefox fixed this issue in Firefox 43, not in 44.0.2. In particular, it was "fixed" in Firefox by updating to a version of libgraphite that did not have the problem, and this happend before the issue was even reported to libgraphite.

      Hence no CVE for Firefox 43 or 44, because they were never vunerable, and no CVE for Firefox 42, because it was long-superseded by the time the vulnerability was even reported.

      The CVE, if you note, is for Firefox 38 ESR, which _was_ vulnerable until the 38.6.1 release.

  2. Re:But this is open source, right? by Anonymous Coward · · Score: 3, Funny

    your eyes are not open source, they are processing fonts, and they are vulnerable

  3. Re:Another buffer overflow by Anonymous Coward · · Score: 4, Informative

    Can I haz SELinux + grsecurity in all major distributions by default plz.

    Of course that wouldn't protect Windows, which is also affected by this and is conveniently left out of the summary. Actually, it doesn't impact linux or windows. It impacts applications that run on them that enable smart fonts using graphite. If you haven't turned on this capability or if you turn it off, you aren't impacted at all. Good news is that it has already been fixed in the latest release of graphite in January.

  4. Hyperbole? Much? by Viol8 · · Score: 5, Insightful

    FTA:

    "The worst is an out-of-bounds read bug (CVE-2016-1521) that allows attackers to crash the system"

    Err no. It'll crash the browser (or whichever userspace program is using the library). Thats a bit different to crashing the kernel.

    Bring back the X Font Server and get off my lawn!

  5. Re:gfx.font_rendering.graphite.enabled by gustygolf · · Score: 5, Informative

    Or disable web fonts. No attack vector that way.

    gfx.downloadable_fonts.enabled = false

    --
    "Slow Down Cowboy! It's been 58 minutes since you last successfully posted a comment" -- slashdot, driving users away.
  6. Re:Another buffer overflow by Anonymous Coward · · Score: 3, Interesting

    I get that you clearly have an axe to grind about Rust for some reason, but you have not explained why it isn't viable. It's impossible to take you seriously when you make empty claims about Servo "going nowhere" when components written in Rust for Servo are being added to Firefox as we speak, or that Rust's syntax is "a step backward" from the likes of C++ or PHP, or argue that you might as well use C++ instead, despite the fact that C++ offers too many convenient footguns to make such a thing viable without expensive static analysis tools to make sure you aren't screwing up... which Rust offers built-in as part of the compilation process.

    It honestly sounds like you're just unwilling to acknowledge Rust because Mozilla did something to piss you off. Maybe they removed a feature from Firefox you don't like, or maybe you just think they should have pushed Rust out the door faster than any other advanced language, or maybe you just don't like some people working on Rust or at Mozilla. At any rate, you are doing a piss poor job of convincing anybody as to what Rust's actual flaws are. The standard library not being as mature as the ones in older languages? That's really the only substantive thing you've mentioned here that doesn't smack of petty sensationalism.