back to article Anatomy of a 22-year-old X Window bug: Get root with newly uncovered flaw

The X Window System, which today underpins Linux desktops the world over, has been around for more than two decades – and so have its bugs. Sysadmins have a few days to patch libXfont to remove a newly discovered, 22-year-old privilege-escalation bug in the code before any tiresome users whip out an exploit. The flaw allows …

COMMENTS

This topic is closed for new posts.
  1. DougS Silver badge

    It looks like NO ONE ever audited X Windows

    Many eyes only works when there's at least one person who doesn't assume that someone else has already looked at it!

    This is such a basic fail, an unbounded sscanf() is the sort of thing you'd look for when trying to discover buffer overflows. The fact it survived that long demonstrates that no one ever looked at it. Glad someone has, and if he's the first it is not surprising he's got 120 or them.

    Hell, you could probably write some code in lex or use cpp to find stuff like this, I'm stunned something as basic as this was never found. Hopefully they'll all be local privilege escalation, as I know that code that touches the external port it uses has been looked at pretty well - or at least better than the rest of it apparently was.

    1. vagabondo

      Re: It looks like NO ONE ever audited X Windows

      > Hell, you could probably write some code in lex or use cpp to find stuff like this,

      But there really should be no need to. The compiler/language should catch/prevent this stuff. This, and much else, is a consequence of the fashion for using "C" (a really good portable assembler) for just about everything. There have been better tools for at least 30 years. The great thing about computing is that the repetitive, boring stuff is fairly easily automated.

      We should also keep this in perspective. This is a desktop application. So for the most part any vulnerability enables the user to break their own machine/instance. Without such flaws how are people going to jail-break/root their proprietary phones, tablets, etc?

      The article says that the flaw is 22 years old. I thought that the present Xorg code dates from 10 years ago?

      1. Hans 1 Silver badge

        Re: It looks like NO ONE ever audited X Windows

        @ vagabondo

        Did you follow the links in the article ? Sadly it is that old ....

        >http://lists.x.org/archives/xorg-announce/2014-January/002389.html

        Affected Versions

        =================

        This bug appears to have been introduced in the initial RCS version 1.1

        checked in on 1991/05/10, and is thus believed to be present in every X11

        release starting with X11R5 up to the current libXfont 1.4.6.

        (Manual inspection shows it is present in the sources from the X11R5

        tarballs, but not in those from the X11R4 tarballs.)

        1. vagabondo

          Re: It looks like NO ONE ever audited X Windows

          @Hans 1

          > Did you follow the links in the article ? Sadly it is that old ....

          Yes, and I addressed this in another thread. My recollection of the change from XFree to X.org, is that there was supposed to be a re-write. Certainly the X.Org libXfont did not exist before this millenium, and is dated as eight years old by Freedesktop.org.

          The possibility of a crafted BDF overflow vulnerability in this library was known in 2004

          CVE-2007-1352

          Description

          Integer overflow in the FontFileInitTable function in X.Org libXfont before 20070403 allows remote authenticated users to execute arbitrary code via a long first line in the fonts.dir file, which results in a heap overflow.

          And an (inelegant) OpenBSD workaround/patch promptly published.

          I suspect (but have no evidence) that the present story is the result of a rediscovery of this flaw, and the subsequent release of a Ubuntu security update. And that the offending libXfont code was blindly copied from the earlier work.

    2. Anonymous Coward
      Anonymous Coward

      Re: It looks like NO ONE ever audited X Windows

      Don't really do it any more, but used to effectively crash-test Windows and 3rd-party software running on it and was amazed at how often I'd find bugs I thought thousands should have found before me. I still find it hard to believe people didn't find them but assume they must already be known of, rather than simply being too lazy to report them. Or never found them, due to a staggering lack of curiosity. The frustration of this is the reason I stopped.

      But for many years I've run multiple distros until I break them - can't help it! - which takes from an hour or two to a few weeks tops. I've done it to upward of two dozen distros over the last decade. And all this time I've been trying to square the apparent denial and scathing hostility of the Linux equivalent of the Windows beta tester, and suddenly I see it...I believe it's called a circle jerk?

      Really, guys. If you think you don't need to check stuff - because you're so smart - you're not only actually stupid, but you're a self-made man into the bargain!

      (I tend to figure the chicks really are smart, at least the ones who are good with computers)

      1. Christine Hedley

        Re: It looks like NO ONE ever audited X Windows

        "(I tend to figure the chicks really are smart, at least the ones who are good with computers)"

        Based on my experiences of various co-workers over the years, I'd say that failure to do proper sanity checking is certainly an equal opportunity thing. God knows I've made enough of my own gaffes in that time.

      2. AndrueC Silver badge
        Happy

        Re: It looks like NO ONE ever audited X Windows

        (I tend to figure the chicks really are smart, at least the ones who are good with computers)

        Too small a sample size for me to really draw a valid conclusion but I will say that the few I've worked with seem to spend more time thinking about what they are doing rather than the more typical (male?) trait of leaping in with both hands. The end results were much of a muchness but it seemed to me that the women 'lost' time in thinking about the problem and the men lost time in 'redoing' stuff until worked.

        Now if you combined both approaches...

        ..you'd end up with a programmer that spends ages thinking about the problem then codes a solution that turns out to be a g'awful mess that takes ages to fix :)

        1. Lallabalalla

          Re: It looks like NO ONE ever audited X Windows

          "a programmer that spends ages thinking about the problem then codes a solution that turns out to be a g'awful mess that takes ages to fix" -??

          I could name quite a few of those, believe me!

      3. big_D Silver badge

        Re: It looks like NO ONE ever audited X Windows

        Own machine? And all of those people working on multi-user machines? We have around 50 people working on one machine here...

        1. vagabondo

          Re: It looks like NO ONE ever audited X Windows

          @big_D

          > Own machine? And all of those people working on multi-user machines?

          > We have around 50 people working on one machine here...

          The actual phrase used was:

          " ... their own machine/instance."

          If you have 50 untrusted logins/users and allow them to install their random software, fonts, etc., then it would be prudent to provide them with their own virtual desktop o.r chrooted (jail) environment. I.e. their own "instance".

      4. big_D Silver badge

        Re: It looks like NO ONE ever audited X Windows

        @Mary Jane yeah, I tested for MS products and for SUSE. You can find some real doozies.

        The most "fun" one was the J++ compiler / runtime for Windows. I found that the following statement would not work correctly:

        a = 10;

        b = -1;

        a =+ b;

        Now, this should return 9 (10 + -1 = 9), but Microsoft J++ insisted that it return 11! I reported it as a bug in the late 90s, 2 years later, it was still there!

        The moste reliable code I worked on was 70,000 lines of VB, released to over 40 countries for a corporate customer. In 2 years they reported 2 bugs - and one was a Windows bug!

        Using the Win32 function to return the local month names worked fine on our UK machine and a French and a German test machine. The function returned all the correct month names. We then ran into a problem with the International English version, it would return "January" as the name for every month!

        On the SUSE side, I logged one for the installer, it would list which CD was currently being read, it was displaying CD 4, even though I was installing from DVD and there was only 1 DVD in the set! That was another one that didn't really get treated with any priority. Still, I did get free copies of the packaged SUSE product for several years for working as a tester.

      5. amanfromMars 1 Silver badge

        Re: It looks like NO ONE ever audited X Windows

        SMARTR Chicks can Rule with Great Game Computers, Input to XSSXXXX Guaranteed Output, Virtually Protected with Browser Activity and HyperRadioProActive IT ....... Inter Species Quantum Communications .

        I Kid U Not, Kemo Sabe. Apache speak truth to Global Operating Devices.

        Enter Stage ..... A Right Virtuous Bunch of Dynamic Digital Designers in Real Bad Territory Autonomously.

        <XSSXXXX GO> :-)

        GCHQ Special Virtual Ops Apps for CyberIntelAIgent Travellers/Wanton Emerging Precocious Drivers/Spooks.

        cc Francis Maude re the Virtual Governance Conundrum to Admit Defeat and Celebrate to XSSXXXX Success.

        NSA Sentient App Press Ready to Go...... Watch Out for Player Burn Out/Catastrophic Self Destruct/Strictly Adults Only Warez.

        And what is the national state of virtual readiness for All Current Systems Command and Control Takeover for Makeover, Mr Maude? Robust and Resistant or Rare and Renegade Rogue?

    3. Anonymous Coward
      Anonymous Coward

      Re: It looks like NO ONE ever audited X Windows

      There's a cost/benefit trade-off to bug hunting, and given my ubuntu machine has 337 ttf fonts and 0 bdf fonts, I wouldn't worry too much...

      1. Anonymous Coward
        Anonymous Coward

        Re: It looks like NO ONE ever audited X Windows

        "and given my ubuntu machine has 337 ttf fonts and 0 bdf fonts, I wouldn't worry too much..."

        Did you know that most burglars these days don't bother breaking in through Windows? They prefer to bust the windows in doors, which most people overlook. It's easier, quicker and actually quieter in a built-up area.

        Never, ever get blase about security either physical or software based. Some smartarse will happily turn your day upside-down in an instant!

        1. AndrueC Silver badge
          Thumb Up

          Re: It looks like NO ONE ever audited X Windows

          Never, ever get blase about security either physical or software based. Some smartarse will happily turn your day upside-down in an instant!

          On a vaguely related front never get blase about anything IT. I've just had a bit of a panic at home because I noticed I was chewing through my download allowance at an alarming rate (over 70GB so far this month). Turned out my mail server was the cause. It was set to send bad emails to the bit bucket and that was fine until this month when some skiddie started sending crap that was 100kB instead of the usual 12kB or less.

          100kB doesn't sound much but when the skiddie's tools are sending you three or four a second it becomes a more serious problem. Solved fairly easily by telling the server to reject the email instead but now I'm left with 20GB of allowance to last me the remainder of the month.

          As you say - never be complacent.

          1. Anonymous Coward
            Anonymous Coward

            Re: It looks like NO ONE ever audited X Windows

            "over 70GB so far this month"

            I had a similar surprise last month, my son had installed with permission from me some game which unbeknown to me included an open source P2P utility which then downloaded a bunch of themes, scenarios etc. One night we left the PC on overnight, and for 2 or 3 nights total. What we did not realise is that during that time it was uploading / sharing files with the rest of the world.

            I only noticed when completely by chance I looked at the router logs and saw that a whopping 60Gb of data had been used already that month compared to previous month, but we were only in mid-December!

            I calculated 55 Gb down to that oversight and deleted the P2P utlitity which I then discovered was separate to the main program.

            Serves me right, I know, and fortunately I am on genuinely unlimited bandwidth contract, but it's taught me to go back to planning to re-install outbound firewalls on each PC rather than just the inbound windows one.

        2. Anonymous Coward
          Anonymous Coward

          Re: It looks like NO ONE ever audited X Windows

          Oh shit - I'll fix the bug and recompile the component on my machine immediately! ;-)

        3. Anonymous Coward
          Anonymous Coward

          Re: It looks like NO ONE ever audited X Windows

          "Did you know that most burglars these days don't bother breaking in through Windows?"

          It's the same on the internet too. You are about 3-4 times more likely to be hacked if you are running an Internet facing webserver with a Linux based OS compared to a Windows Server based one these days....

          1. Jes.e

            Re: It looks like NO ONE ever audited X Windows

            " It's the same on the internet too. You are about 3-4 times more likely to be hacked if you are running an Internet facing webserver with a Linux based OS compared to a Windows Server based one these days...."

            Could you provide a source please?

            1. James O'Shea

              Re: It looks like NO ONE ever audited X Windows

              "Could you provide a source please?"

              no, he can't.

              1. David Barrett Silver badge

                Re: It looks like NO ONE ever audited X Windows

                This is the internet we don't need to provide sources, or proof.

              2. dssf

                Re: It looks like NO ONE ever audited X Windows... Why not see it as a potential compliment?

                Considering that Linux-based servers reportedly have more or increasing marketshare than Windows-based server, would not there exist a thrown-down-gaunlet situation?

                Run a Linux-based server, get attacked for the challenge.

                Run a windows-based server, get hacked for the potential goddies behind it.

                Circular--- run a Linux-base server, and it may be hacked/probed for the goodies behind it...

            2. Anonymous Coward
              Anonymous Coward

              Re: It looks like NO ONE ever audited X Windows

              ""Could you provide a source please?""

              From link above: http://www.zone-h.org/news/id/4737

              If you adjust the defacements for relative market share of webservers of Linux versus Windows (for instance via the monthly Netcraft survey), you will see that 3-4 times more likely to be attacked on Linux is pretty spot on....

              1. Anonymous Coward
                Anonymous Coward

                Re: It looks like NO ONE ever audited X Windows

                Did readers know that the vulnerability referenced in teh zone-h defacements article now repeatedly being touted as 'look how vulnerable Linux is' testimony was *only* applicable on x86 boxes ? Not ARM, not MIPS, not PowerPC, not SPARC (etc). Only applicable on an x86-64box running an x86-64 Linux of a particular version range, running a widely used x86-32 app stack. So yes there's a lot of them about. But it's not a generic problem with the OS, it's a problem which shows up only with a particular version of the OS on a particular set of underlying hardware with a particular application stack. Extrapolation from that to any other statistic is rather risky.

                The X/scanf thing is pretty poor code, any fule knows that. Exploiting it for anything useful (other than to crash the X server, which would presumably often result in the X server restarting?) might be trickier.

                From the zone-h article: "The most used exploit by the defac­ers is the CVE-​2010 – 3301, that was fixed in 2007 and was mys­te­ri­ously rein­tro­duced in 2008, in a large pile of ker­nel ver­sions x86_​64."

                Hey look, someone who's heard of CVE. How often does that happen round here ?

                Have a lot of fun.

          2. Anonymous Coward
            WTF?

            Re: It looks like NO ONE ever audited X Windows

            "You are about 3-4 times more likely to be hacked if you are running an Internet facing webserver with a Linux based OS compared to a Windows Server based one these days...."

            TheVogon is that you?

            I only ask because your fallacies seem familiar. Like a mirror-universe Eadon, with a pointy beard.

          3. Anonymous Coward
            Anonymous Coward

            Re: It looks like NO ONE ever audited X Windows

            "You are about 3-4 times more likely to be hacked if you are running an Internet facing webserver with a Linux based OS compared to a Windows Server based one these days...."

            Citation needed, but at a guess...

            This claim typically originates from a zone-h defacements article relating to numbers of websites being defaced vs website OS. Defacement is embarrassing for the website in question, but not everyone would class it as being hacked (presentation layer people obviously would; other worlds are available).

            Did readers know that the vulnerability referenced in teh zone-h defacements article now repeatedly being touted as 'look how vulnerable Linux is' testimony was *only* applicable on x86 boxes ? Not ARM, not MIPS, not PowerPC, not SPARC (etc). Only applicable on an x86-64box running an x86-64 Linux of a particular version range, running a widely used x86-32 app stack.

      2. petur
        Facepalm

        Re: It looks like NO ONE ever audited X Windows

        Trolling, sarcastic or ignorant?

        I'm sure that a suitable bdf font will be part of the attack, as the bug clearly isn't triggered by the normal fonts you have around.

      3. Lallabalalla

        Re: It looks like NO ONE ever audited X Windows

        Yeah, but "client libraries trusted servers to send valid data" ! That is SUCH a schoolboy error. Literally.

      4. Frumious Bandersnatch Silver badge

        Re: It looks like NO ONE ever audited X Windows

        given my ubuntu machine has 337 ttf fonts and 0 bdf fonts, I wouldn't worry too much...

        Eh, you should worry. Just because you don't have any bdf fonts, it doesn't mean that the buggy interface for loading them isn't there. As the article said, it triggers "when reading a user-provided specially crafted font". Any user program that's talking to the X server can then use it for privilege escalation, and that's a really bad thing.

        Besides, just because you didn't find any bdf files, it doesn't mean that your system isn't already rooted. An attacker can delete the temporary bdf file after running an exploit. In fact, the code looks like it doesn't even care whether the supplied filename even exists (and in fact, it won't), so your blithe dismissal is even more stupid.

  2. This post has been deleted by a moderator

  3. btrower

    I have looked

    I have looked at a lot of the code on various Linux systems. It is riddled with bugs even now. Just getting lots of this stuff to compile is an adventure.

    Code should not cause compilers to issue dozens of warnings. It sure should not die on actual errors. I have never had the persistence to completely clean up any of that code on a non-trivial system. The main cause is programmers with six to ten years of bad habits under their belts who are just good enough to create havoc.

    On the upside, there *are* a lot of good programmers out there who have good habits and some are tackling some of the basic code. There is hope yet.

    1. Wzrd1

      Re: I have looked

      "On the upside, there *are* a lot of good programmers out there who have good habits and some are tackling some of the basic code. There is hope yet."

      Yep! The NSA is loaded with good programmers.

      Look at SELinux.

      Hmmm...

      1. TheVogon Silver badge

        Re: I have looked

        "Look at SELinux."

        A bolt on to fix what many other OSs (even Windows) already have built in from the ground up...

        1. DanDanDan

          Re: I have looked

          It was originally a set of patches, which have now been integrated into the core of the Linux kernel (since 2003). It's not really what I'd call a bolt-on.

          1. Anonymous Coward
            Anonymous Coward

            Re: I have looked

            "It's not really what I'd call a bolt-on."

            Regardless of how it's integrated into the source code - it is a bolt on additional module to fix stuff that should have been controlled in the first place by including these features from the ground up.

            Because it's an afterthought, you now effectviely have multiple security models - and because it's a bolt-on module, it in turn breaks other stuff - for instance: http://www.juniper.net/security/auto/vulnerabilities/vuln30276.html - and still doesnt have the capabilities of even Windows in this area - for instance dynamic access control / expression based security, and constrained delegation.

            1. DanDanDan

              Re: I have looked

              Hmmm, the debian ssh bug is definitely interesting, have an upvote. However, the bug only circumvents the SELinux policies, so I don't quite see it being the same as "breaking other stuff". Breaking other stuff would imply that it stops something working or is in itself a vulnerability.

              The usual access control rules would still apply and Linux is still quite safe without SELinux installed (due to the myriad of other control mechanisms in place already (ACL, PAM, IPtables, SSHconfig for your example [authorized_keys restriction of executable commands]).

              I also dislike the phrase "Regardless of how it's integrated into the source code" - Being built in from the start is a method of integrating it into the source code, one you seem happy with. Also, who says it's still considered an "afterthought"? I'm pretty sure SELinux is on a firm and secure footing by now.

              I also don't see any issue with having "multiple security models", indeed, this is good security practice. Redundancy and a layered approach mean that you're never left with a single point of failure. IPTables are unnecessary with an effective implementation of SELinux. Encrypting your hard disk is unnecessary if you aren't connected to a network and have physically secured the server. Memory segmentation is unnecessary if source code is correctly vetted and free from faults. But personally, I employ them all as and where necessary. Different tools for different jobs.

        2. tom dial Silver badge

          Re: I have looked

          Much like IBM's OS/360 and its successors through z/OS: the core OS has features like the Authorized Program Facility and System Authorization Facility, to support "bolt ons" like Resource Access Control Facility (IBM), Top Secret (CA), and Access Control Faclity 2 (also CA).

          Windows is the not only OS with built in mandatory access control; Unisys OS2200 and VMS appear to build it in. But Linux and other Unix and Unix like systems provide it as an add on are not inherently less secure for that.

    2. A Non e-mouse Silver badge

      Re: I have looked

      Code should not cause compilers to issue dozens of warnings

      How many compiler errors does closed source software produced when it is compiled? I don't know, do you?

      Sometimes, though, compiler warnings can be wrong. Anyone remember the Debian SSL security issue? Some well meaning maintainer tweaked the code to remove a compiler warning. The only downside was the compiler warning was a false positive and altering the code to remove the compiler warning caused all the SSL certificates produced by that bit of code to be easily crackable.

      As people discover more security vulnerabilities, compilers and other tools get better at picking up potential problems (and not highlighting false positives either - see the latest LLVM/Clang release)

      1. itzman

        Re: I have looked

        That is a result of fixing things the WRONG way.

        99% of the 'warning's I see are in fact type casting warnings.

        easily fixed by explicit casts in the source that change nothing in the compiled code, only tell the compiler 'its cool, I really meant to expand a 32 bit quantity into a 64 bit one, actually'.

        or whatever.

      2. Def Silver badge

        Re: I have looked

        How many compiler errors does closed source software produced when it is compiled?

        If I work on it, zero. One of the first things I do when I start working for a new company is to enforce warnings-as-errors, whack the warning level up to maximum (and disable the few genuinely useless ones), and then fix the errors. I also regularly run static code analysis tools (such as CppCheck) on any codebase I work on.

        99.99% of warnings are errors that don't prevent the compiler from producing *something*. If your code produces compiler warnings, then you're not doing your job properly.

        1. Roland6 Silver badge

          Re: I have looked

          >If I work on it, zero. ... is to enforce warnings-as-errors, whack the warning level up to maximum (and disable the few genuinely useless ones), and then fix the errors.

          Didn't happen to work with Ada in a previous life? I seem to remember the various compilers I worked with as being very unforgiving...

        2. JEDIDIAH
          Devil

          Re: I have looked

          > If I work on it, zero. One of the first things I do when I start working for a new company is to enforce warnings-as-errors

          So what you're really saying is that this problem is pervasive across the industry and that closed proprietary code isn't any worse in this regard than Free Software is. It's just easier to hide your sins when no one can see your code.

        3. Tim Bates

          Re: I have looked

          "One of the first things I do when I start working for a new company is <blah blah>"

          So you focus on scoring a perfect score in the compile? I'm curious... Does that devotion to zero compiler warnings effect how much time is left for writing code that actually does what it was meant to?

          Surely it has some effect if people are more worried about it being allowed through the compiler than getting the logic correct.

    3. Ian Johnston

      Re: I have looked

      Code should not cause compilers to issue dozens of warnings.

      Meh. If you're not getting compiler warnings you're not trying hard enough.

      1. Roland6 Silver badge

        Re: I have looked @Ian Johnston

        Final Release to Manufacture "Code should not cause compilers to issue dozens of warnings."

        If it does it typically means you've not tried hard enough to understand just what exactly your code is permitting.

  4. frank ly
    Happy

    smiles for the 'goto'

    You don't see them often nowadays.

    1. Number6

      Re: smiles for the 'goto'

      There are occasions where it produces more readable, and sometimes more efficient, code than trying to do a bunch of conditionals to achieve the same thing.

      1. Dan 55 Silver badge

        Re: smiles for the 'goto'

        I'd rather have four if-gotos at the top level rather than four levels of nested ifs-elses.

        Some people still insist on rewriting it so it's harder to read though. They've been told that gotos are evil and there's no way to convince them otherwise.

        1. Destroy All Monsters Silver badge

          Re: smiles for the 'goto'

          ALl of that could be avoided with proper sub-functions

          1. itzman

            Re: ALl of that could be avoided with proper sub-functions (smiles for the 'goto')

            sub functions are longer and use stack.

            Lets face it, all machines have an unconditional branch instruction - a machine level 'goto'

            the C statements 'break' and 'continue' are both essentially unconditional branches as are many instances of '}' and '{'

            if(a)

            {

            }

            else

            {

            }

            becomes a goto from the final '}' in the first conditional to the final '}' in the second.

            It is not really any different in ultimate sense from

            IF (NOT A)

            THEN GOTO LABEL 1

            ...

            GOTO LABEL2

            LABEL1:

            ...

            LABEL2:

            its just shorthand for it.

            1. Frumious Bandersnatch Silver badge

              Re: ALl of that could be avoided with proper sub-functions (smiles for the 'goto')

              'break' and 'continue' are both essentially unconditional branches

              Actually, your example is wrong, assuming you're telling us to put a break statement somewhere in an if ... else block. They don't break out of if() statements... only loop or switch constructs.

              That aside, the point I really wanted to make is that break/continue in C are really limited since they only jump out of the nearest enclosing loop/switch. Unlike Perl (where the next/last keywords can take a label to indicate which loop to jump out of), there's no way to use them to quickly exit several nesting levels. That's one of the reasons why C has goto and, IMO, it's perfectly acceptable at times. The alternative of setting up a temporary "want to exit" variable in each loop level is just too messy, error prone and, at times, inefficient.

            2. Vic

              Re: ALl of that could be avoided with proper sub-functions (smiles for the 'goto')

              > sub functions are longer and use stack.

              Not when the compiler inlines them...

              Vic.

        2. Joseph Haig

          Re: smiles for the 'goto'

          I cannot remember the last time I even considered using 'goto'. I don't think of them as evil so much as non-existent. It must be an habitual thing.

          1. John Gamble
            Boffin

            Re: smiles for the 'goto'

            It does depend on the coding problem. The last time I had to use a goto was about twenty years ago (and it was only the second time I'd ever used one), but it only lasted in the code for about three years before refactoring made it unnecessary.

            I don't have anything against the construct, but it may indicate a need for a closer examination of how one's code is organized.

        3. Roland6 Silver badge

          Re: smiles for the 'goto'

          "I'd rather have four if-gotos at the top level rather than four levels of nested ifs-elses."

          Interestingly, a good optimising compiler will produce largely the same assembler code - or did when I was heavily into compilers and code optimisation in the 80's...

          1. Dan 55 Silver badge

            Re: smiles for the 'goto'

            @Roland6

            I've no doubt that any compiler can easily make sense of it, but I'm talking humans. I only let myself use one label per function if I have to, so I can get out of buried ifs and loops and tidy up resources before returning.

            Nowadays wih C++ we've got exceptions and all that spangly stuff. RAII FTW.

            1. Roland6 Silver badge

              Re: smiles for the 'goto' @dan 55

              Sorry my point was an attempt to head off clueless individual's who think that one or other method produces more efficient ASM, because as you point out the real issue is code readability to humans and particularly to future programmer's who won't have the benefit of your understanding of the problem and why the code is written one way and not another.

              As for "exceptions and all that spangly stuff" - well just spare a thought for those who job it is to write the stack and memory clean up routines...

      2. dajames Silver badge
        Facepalm

        Re: smiles for the 'goto'

        There are occasions where it produces more readable, and sometimes more efficient, code than trying to do a bunch of conditionals to achieve the same thing.

        More readable I doubt. More efficient I grant you, but the difference is seldom significant. The big trouble with GOTOs is that they reduce robustness and maintainability -- it's all too easy to accidentally skip past some vital clean-up code and introduce BUGS.

        Give me stuctured exception-handling, any day!

    2. Richard 22

      Re: smiles for the 'goto'

      Take a look at the linux kernel code - the enforced coding style for the kernel virtually mandates the use of gotos (80 char max line width, 8 char tab indentation). It forces a style without excessive nesting, and gotos are commonly used as a way of jumping to some end-of-function cleanup (in a similar way to how exceptions might be used).

      Takes some getting used to at first, but you learn to love it in the end... (though 40 char+ function names don't help - wait_for_completion_interruptible_timeout I'm looking at you...)

      1. sabroni Silver badge

        Re:though 40 char+ function names don't help

        "wait_for_completion_interruptible_timeout" seems pretty helpful, more helpful than "x" anyway.....

        Doesn't your IDE complete that stuff for you once you start typing anyway?

        1. Anonymous Coward
          Anonymous Coward

          Re: Re:though 40 char+ function names don't help

          One of the reasons for disliking IDEs. They remove too much thinking, allow sloppiness and avoidable code verbosity and make for incredibly complicated code organisation, quickly worsened by a programmer in a hurry going straight to the concerned file to do the quick fix with a normal editor.

          It's a high price and another learning curve (each IDE differs from the others) in return for apparent consistency and a lot of obscurity. I find Java, for instance, straightforward. My big barrier to bothering with it is the heavyweight performance and learning of something like Eclipse before I can even type a "hallo world" programme using it (I know I could just use vi(1) or notepad; I'm illustrating a point). The other nasty bit is that people learn the IDE inside out and are often completely unaware of the quirks of the operating system. So, on a UNIX system, one sees a "developer" writing a Java programme to do what UNIX utilities like date(1) or sort(1) do when all he wants to do is look at the files in a directory in some particular order at the shell level. Meanwhile, because he has used Eclipse on UNIX, he claims to be a UNIX expert when actually he has no idea if he is on UNIX or Windows or a mainframe; of course, this can be seen as a strength - why should you have to worry about the operating system? It is also a productivity weakness and leads to some very poorly performing applications.

          1. Anonymous Coward
            Anonymous Coward

            @AC 13:55

            I disagree. Bad engineers "remove too much thinking, allow sloppiness and avoidable code verbosity and make for incredibly complicated code organisation". Something that types a name correctly for you, thereby making it easier to use clear names for things, is an aid to good coding. And as for "worsened by a programmer in a hurry going straight to the concerned file to do the quick fix with a normal editor", that's criticising an IDE when it hasn't been used, bit of a tortuous argument.

            I don't have a problem with people that don't like IDEs, I have a problem with people that don't like clear variable/function names because they involve too much typing. Modern IDEs can alleviate the amount of typing, which means you can be clear without having to press all those troublesome buttons.

            Software engineers, learn to touch type!

        2. Tom 13

          Re: Doesn't your IDE complete

          In context I assumed that was more along the lines of the command alone uses half the allotted line space after the IDE expands it.

        3. Pookietoo

          Re: Re:though 40 char+ function names don't help

          It's a line length issue, not a typing one.

          1. Anonymous Coward
            Anonymous Coward

            Re: It's a line length issue

            My IDE shows 165 characters on a line, a function name of 40 can easily fit on that. What are you editing on that 40 characters is too long?

            (it is long, but I prefer that to obscure abbreviations or vagueness.)

            1. Anonymous Coward
              Anonymous Coward

              Re: It's a line length issue

              "What are you editing on that 40 characters is too long?"

              Have you seen the actual Linux kernel source code? They enforce a manual of style there that imposes these two conditions:

              1. Maximum line length 80 characters

              2. Tabs space to 8's.

              This is due to the old text-mode consoles that had those two limitations built into them and unchangeable. The situation is such that BOTH long names AND multiple nesting are discouraged because both reduce the acceptable real estate of a given line. You may be forced to use the ugly backslash-newline continuation symbol which can make the code look pretty ugly.

    3. AndrueC Silver badge
      Meh

      Re: smiles for the 'goto'

      In this case they are basically being a poor man's exception. I don't have a problem with that in moderation if exceptions are not available. It's when gotos jump around inside a function that I get upset - jumping to the 'get me the hell out of here' code at the end is tolerable.

  5. Rule of Thumb
    Joke

    Clearly...

    ... the work of the NSA?

  6. Anonymous Coward
    Anonymous Coward

    "The X Windows System, which today underpins Linux ...."

    Unix, not just Linux

    1. Joe Montana

      Desktop...

      X11 only has any use if you're using a unix system as a workstation, which is actually pretty rare... Most unix systems are used as embedded devices or servers, and are unlikely to be running X11.

      Also, how would an unprivileged user introduce an arbitrary BDF font to the X11 server?

      1. PyLETS
        WTF?

        @Joe Montana Re: Desktop.

        "Also, how would an unprivileged user introduce an arbitrary BDF font to the X11 server?"

        In very few cases a Linux desktop will have multiple logins where the users don't have direct access to the hardware (e.g. using thin clients ? ) and some of these are not allowed to use root and want it badly enough to craft an exploit or use a precrafted one. If you are setting up such a system and expecting it to be secure against users like that with logins, then you're probably a bit bonkers anyway.

        Any user with a login who has access to the hardware can subvert this kind of thing anyway, in the worst case by resetting the BIOS password.

      2. Frank Gerlach #2

        VMS, too

        You can run X11 on almost any operating system that has a somewhat workable C compiler and standard APIs.

        The concept X11 could also be implemented in almost any language, just the concrete X.org implementation is done in C.

        Nobody stops you from reimplementing it in Pascal, Ada, Java or Sappeur.

      3. Frumious Bandersnatch Silver badge

        Re: Desktop...

        X11 only has any use if you're using a unix system as a workstation, which is actually pretty rare... Most unix systems are used as embedded devices or servers, and are unlikely to be running X11.

        Also, how would an unprivileged user introduce an arbitrary BDF font to the X11 server?

        This isn't quite true. Don't forget that one aspect of the X Window system is that it provides a networked client/server architecture. You talk about embedded systems. I have several Pis and other similar systems that I don't run an X display on, yet I still run X applications on the embedded device (eg, AVR programmer) by using 'ssh -X' and have the apps displayed on my workstation.

        I don't know enough about the architecture of X (in terms of whether fonts are local to the client or server side, or whether there's a privileged process at work on the client side when I use 'ssh -X', though probably not) to be able to say, but it looks like the insecurity would also be there if I'm running remote X applications too. As to introducing arbitrary fonts, I'm pretty sure that the font doesn't even have to exist on the system: it seems like all the attacker has to do is to present a specially-crafted filename, and the sscanf will smash the stack before the routine ever gets to checking whether the file actually exists or not...

        1. Vic

          Re: Desktop...

          > I still run X applications on the embedded device

          Yes, but it is the X Server[1] that is vulnerable, since that is what loads the fonts. The X client applications are unaffected by this.

          Vic.

          [1] The terms "server" and "cllient" are frequently misunderstood when it comes to dealing with X; the server is the thing that provides services, and is therefore the windowey bit you're sat in front of. The client is the application program that might well be running on a different continent from you...

    2. HolyFreakinGhost

      Don't know about that - my Macbook one of the most widespread Unix systems out there and doesn't use X, while my phone runs a Linux-based kernel and also doesn't use X.

      1. Anonymous Coward
        Anonymous Coward

        I'm running X11 on my Macbook. Of course, I'm in a minority. But it is supported under OS X.

      2. Hans 1 Silver badge

        > my Macbook one of the most widespread Unix systems out there and doesn't use X

        Look again in /Applications/Utilities - there is this thing called X11 ;-)

        I used to build my own from source on OS X 10.0 and 10.1 back in the day, and apparently those had this bug as well. I think, iirc, 10.2 or 10.3 came with the first Apple X11 ... not 100% sure though which ... memories ... it might be an optional install, BTW.

        1. This post has been deleted by its author

    3. Pookietoo

      Re: "The X Windows System, which today underpins Linux ..."

      Except it doesn't really underpin it, so much as sit on top of it to provide a GUI. You don't need it at all for many server or embedded applications, and there are alternatives if you need a WIMP HCI and don't want X.

  7. vagabondo

    X-Windows or X.org? History

    This is mostly from my somewhat flawed memory, and corrections are welcomed.

    Originally this article's title referred to X Windows. It was changed to X.org following a deleted post from someone who seemed to think that the term "Windows" with respect to GUIs was the exclusive property of Microsoft.

    "Windows" as in WIMP has been in common use for graphical desktops a long time before Microsoft. The X Windowing system achieved prominence in the early eighties. X.org dates from the late nineties, and the current code from since the X.org Foundation c. 10 years ago. Either it is X Windows and 22 years or X.org, it can't be X.org and 22 years.

    libxfont itself appears to be 8 years old, and the X.org code 10-15 years old.

    freedesktop.org

    This particular bug seems to have been known since 2007.

    gentoo.org/security.

    Either there has been a regression, or earlier reports were ignored, I don't know.

    1. T. F. M. Reader Silver badge

      Re: X-Windows or X.org? History

      @vagabondo: "This particular bug seems to have been known since 2007.

      gentoo.org/security.

      Either there has been a regression, or earlier reports were ignored, I don't know."

      Seem to be different bugs,albeit in the same component. This also means that X *has* been audited before, but something slipped through.

  8. fafa1971
    Pint

    X Window, not Windows

    Its official name is singular, X Window System:

    http://en.wikipedia.org/wiki/X_Window_System

    Using the plural form is somehow confusing.

    Just sayin'.

    1. Destroy All Monsters Silver badge
      Paris Hilton

      Re: X Window, not Windows

      I wonder what kind of cretinperson downvotes a perfectly good comment about naming conventions?

      Are we to be spared nothing?

      Or is it because the link to Wikipedia doesn't reach Orlowski levels of hip?

    2. vagabondo

      Re: X Window, not Windows

      > Its official name is singular, X Window System

      And now the title has changed again. s/X.org/X Window/

      It's as if someone actually reads the comments.

  9. T. F. M. Reader Silver badge

    Predictable comments

    I see a lot of predictable comments about "many eyes", "compilers should check", "better tool (than C) should be preferred", "Linux code ridden with bugs", etc. Some are quite correct, e.g., the last one, and btrower's "The main cause is programmers with six to ten years of bad habits under their belts who are just good enough to create havoc." gets an upvote.

    However, in my mind it is not a compiler/tool problem, it is a process problem (what do you do before delivery?). Consider:

    1. The bug *was* in fact found with static analyser (cppcheck) that is available for any Linux system ("yum install cppcheck" or equivalent), not by eye-balling. I just verified that it catches the exact bug - the error message I got was

    (warning) scanf without field width limits can crash with huge input data.

    2. Compilers and other static checkers have different purposes in general. Compilers verify syntactic compliance and references (and detect ambiguities, etc.), but in general they shouldn't overanalyze much beyond that because programmers may do weird stuff intentionally. Lints and static checkers look at usage - with syntax and definitions and resolutions out of the way they may have resources to devote to it than compiler writers can't afford.

    3. Compilers keep improving their warnings. I will not be surprised if scanf field width checks eventually get incorporated, say, into gcc's -Wformat and -Wformat-security (themselves not very ancient).

    4. However, you do not necessarily want every warning that may or may not be relevant for every compilation during the development process, because the compiler's job is primarily syntax. [Some of us (guilty) like -Werror because every warning is a sign that something is wrong with the design or logic or whatever.] It well may be that a two-stage process - first make sure everything compiles and then run a static checker when all the syntax problems have been cleared sway - is more appropriate, but do check stuff before releasing!

    1. vagabondo

      Re: Predictable comments

      Thank you!

    2. Bronek Kozicki Silver badge

      Re: Predictable comments

      Very good post. Here is how it looks from the perspective of language designer : language standards are not for imposing code quality checks. That is what static code analyzers do. If a vendor decides to incorporate static analyzer into the compiler that is quality-of-implementation issue, which does not have to hurt its standard compliance (e.g. because you need to explicitly turn it on with -Werror). Also there are 3rd party tools that can do even better work than the compiler.

      If we learned anything in the past 20 years, it should be that static analyzers are as important as software testing. But yeah, try to teach old dogs new tricks ...

      1. Frank Gerlach #2

        Wrong

        Languages CAN AND SHOULD provide an additional safety net to code reviews, static checks and fuzzing.

        See http://en.wikipedia.org/wiki/Type_safety

        Lame excuses of mentally challenged/lazy C and C++ developers are just that: lame excuses.

        See also:

        http://en.wikipedia.org/wiki/HP_Multi-Programming_Executive

        http://de.wikipedia.org/wiki/MPE_%28Betriebssystem%29

        1. Destroy All Monsters Silver badge
          Holmes

          Re: Wrong

          Man: (paraphrased) Something about C/C++

          Arthur: (uninterested) Yes...

          Man: Something about programmers using C/C++

          Arthur: (perturbed) Yes I see!

          Man: Finally something about the mothers of C/C++ programmers

          Arthur: (mad) Be quiet!

          I may remind the dear correspondent that back in the times when X11 was written, C++ was unstandardized, Ada compilers were expensive, D or golang were not to be found. Yes, you could have written it in Pascal.

          1. Frank Gerlach #2

            Re: Wrong

            Maybe your mother is better at programming than you are. At least when it comes to security.

            1. Destroy All Monsters Silver badge
              Paris Hilton

              Re: Wrong

              Maybe your mother is better at programming than you are. At least when it comes to security.

              Maybe you are a bit of prima donna.

          2. Roland6 Silver badge

            Re: Wrong

            >Yes, you could have written it in Pascal.

            Memory a little poor and Wirth's language reference isn't to hand (and it was a long time ago that I wrote a Pascal compiler). Hence not sure about the validity of your comment with respect to 'pure' Pascal, but if you are referring to the ability to embed assembler like Turbo Pascal then definitely agree and you can do much much more !

  10. Tom 7 Silver badge

    Well on of my distributions had the fix in yesterday

    No need to wait for meatball tuesday....

    1. Anonymous Coward
      Anonymous Coward

      Re: Well on of my distributions had the fix in yesterday

      Which distros are they? How much testing has taken place to release a fix the day of the news about the problem?

      It's all very well making comments like these, but if it's not SLES or RHEL, possibly Ubuntu or Mint, it doesn't really help anyone.

      1. Anonymous Coward
        Anonymous Coward

        Re: Well on of my distributions had the fix in yesterday

        Two downvotes, but no actual answer. Great.

        Now: Can anyone please me which distros were actually fixed yesterday?

        1. vagabondo

          Re: Well on of my distributions had the fix in yesterday

          @AC Thursday 9th January 2014 20:25 GMT

          It only takes 10 seconds with a search engine to realize that the most likely trigger for this story was probably the widely reported Ubuntu security update announcement:

          http://www.ubuntu.com/usn/usn-2078-1/

          1. vagabondo

            Re: Well on of my distributions had the fix in yesterday

            and OpenBSD had a patch in April 2007!

            http://www.openbsd.org/errata40.html#011_xorg

            http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1352

            http://ftp.openbsd.org/pub/OpenBSD/patches/4.0/common/011_xorg.patch

            1. BinkyTheMagicPaperclip Silver badge

              Re: Well on of my distributions had the fix in yesterday

              That's not the same bug. The latest bug was patched 2.5 days ago - check the diff history for bdfread.c

  11. Anonymous Coward
    Anonymous Coward

    Surprise?

    Why is it that when we see the word "exploit" or the phrase "security problems/issues", the article is always about Unix?

    People need to give themselves a shake and stop using products!

    1. Anonymous Coward
      Anonymous Coward

      Re: Surprise?

      "Why is it that when we see the word "exploit" or the phrase "security problems/issues", the article is always about Unix?"

      Well let's not forget that the worst Internet Worm ever was on UNIX based systems...(Morris Worm)

      1. Destroy All Monsters Silver badge
        Trollface

        Re: Surprise?

        "the worst Internet Worm ever was on UNIX based systems..."

        At a time when "Internet" consisted of a few thousand Unix and VAXen strung together by leased lines.

        10/10 would troll with.

      2. Peter Gathercole Silver badge

        Re: Surprise? @AC 12:28

        Yes, it's terrible. Back before the Morris worm, nobody thought to code anything with the level of code care that we now do, because nobody thought that it was possible to do these things because they'd never been done before. I'm sure that there were huge numbers of buffer over-run and similar exploits scattered around every single OS around at that time.

        Every aspect of computing, be it OS design or the primitive networking that was available back then must be looked as being primitive by today's standards.

        As always, isn't hindsight a wonderful thing.

        It's interesting that the arbitrary code execution buffer overrun problems only work if the compiler stores localised variables on the stack, the stack grows downwards rather than upwards, and there are no stack frame barriers imposed by the OS or language runtime. It also helps in the actual potential stack-smashing arbitrary code execution exploit if the calling-conventions and layout of the stack frames and return addresses (which is architecture and OS dependent) are known about in advance.

        This means that gcc compiled binaries running on Intel platforms using the conventional Linux calling conventions can be easily targeted, but otherwise you need to know the target before you start. Of course, corrupting the stack will have unpredictable results regardless of the architecture, but most of these will be denial-of-service type problems, rather than arbitrary code execution. Still a concern, but rather less so,

  12. RyokuMas Silver badge
    Trollface

    What?

    No snappy rebuttal from the more militant linux lovers on here that feel the urge to post some deriding comment every single time something Microsoft is mentioned?

    ... thought not.

    Disclaimer: I am not pro-Microsoft, merely pro-competition. I believe no one company should have a vast monopoly over any one industry or sector, that every large system will have a number of flaws that could be abused by malevolent users, and that I should not have to put disclaimers like this in to avoid being accused of being a "shill".

    1. Alan Bourke

      Re: What?

      Well indeed. But of course all operating systems have holes, so it's academic to take the piss.

      I use Linux every day.

    2. Anonymous Coward
      Anonymous Coward

      Re: What?

      Don;t like trolls unless they're funny and clever.

    3. wikkity

      Re: What?

      Who mentioned Microsoft ?

      1. Destroy All Monsters Silver badge

        Re: What?

        A troll.

      2. Roland6 Silver badge
        Joke

        Re: What?

        >Who mentioned Microsoft ?

        Well they did have Xenix which if memory serves me correctly did have an X.11 server...

  13. AndrueC Silver badge
    Boffin

    I always throw up a little bit in my mouth every time I see 'scanf()' and 'sscanf()'. I'd just far rather parse my own strings. The actual problem ie;lack of overflow checking is just icing on the turd as far as I'm concerned.

    1. Anonymous Coward
      Anonymous Coward

      scanf desirability

      Must say, when I started C development on UNIX in the early 1990s, all the experienced developers, especially those who had worked on the system libraries (we produced a UNIX - BSD based, among other things) declared scanf() persona non grata as it was known to be defective.

  14. Anonymous Coward
    Anonymous Coward

    Because free software is SOOOOOO secure, many eyes and all that.

    Looks like more herps from the derps to me.

    If you want professional quality, you have to pay professional prices. Free cannot compete. This has been proven so many times the discussion is now closed.

    1. Anonymous Coward
      Anonymous Coward

      Re: Because free software is SOOOOOO secure, many eyes and all that.

      > ... the discussion is now closed

      Brilliant! A request to ignore the troll -- from the troll.

    2. Roo

      Re: Because free software is SOOOOOO secure, many eyes and all that.

      "If you want professional quality, you have to pay professional prices."

      In my experience "Professional Quality" means that you get the same kinds of bugs and vulnerabilities, the main distinguishing feature is that your wallet is a lot lighter. Of course those "Professional Prices" include support, which is professional in that the personnel are paid to flannel you for 3-6 months while $vendor recruits a developer fresh out of University to fix it for you (presuming of course they can find the source code of the release you are running in the first place).

      You are quite correct: Free can't compete with the wallet lightening properties of "Professional Quality" software...

      1. Anonymous Coward
        Anonymous Coward

        Re: Because free software is SOOOOOO secure, many eyes and all that.

        "In my experience "Professional Quality" means that you get the same kinds of bugs and vulnerabilities, the main distinguishing feature is that your wallet is a lot lighter"

        Not when you allow for the TCO in most cases. A good example is Munich - ten years to not finish a migration, large numbers of their desktops still have to use non open source systems so they have to support multiple environments - and the additional cost is tens of millions of Euros over what they would have saved moving to an up to date managed stack of paid software...This is why near zero commercial enterprises are heading down this route.

        1. Anonymous Coward
          Anonymous Coward

          Re: Because free software is SOOOOOO secure, many eyes and all that.

          > This is why near zero commercial enterprises are heading down this route.

          Have you heard of Google, Amazon, Facebook, or Rackspace. And that's without even trying hard.

          1. Anonymous Coward
            Anonymous Coward

            Re: Because free software is SOOOOOO secure, many eyes and all that.

            Never realised all their engineers are not paid. No wonder they make so much money. Did I not read somewhere that Android, for example, is not fully "open"?

            Balance is the thing. Even the original UNIX was, sort of, free - I think universities got it, with source, for just the cost of the tape media and hence BSD came out of the original AT&T source.

            But the point is, paid people did most of the actual design, programming, reviews, documentation and so on, whether they were paid as engineers or research staff and lecturers (e.g. X came out of a mixture of acadaemia and companies like Xerox and Digital Equipment Corporation).

            1. T. F. M. Reader Silver badge

              Re: Because free software is SOOOOOO secure, many eyes and all that.

              @AC 14:17 GMT: "Never realised all their engineers are not paid."

              I will attribute any thought that Linux is developed by unpaid armchair amateurs rather than professionals to staggering ignorance and not to malicious trolling.

              Here is your treat: IBM, HP Intel, AMD, RedHat, Google, and scores of other companies, including even Microsoft[*], pay their engineers - thousands of them - to work on Linux (the kernel, when you go to userspace it is even more common).

              [*] You can grep the kernel source code for "@microsoft" to see the engineers' email addresses (and Microsoft's copyright statements) if you don't believe me. [For the curious, "@apple" is not found.] This is one difference compared with closed source: people sign their code for everyone to see - I have always regarded it as very professional behaviour.

              1. Vic

                Re: Because free software is SOOOOOO secure, many eyes and all that.

                I will attribute any thought that Linux is developed by unpaid armchair amateurs rather than professionals to staggering ignorance and not to malicious trolling.

                You would probably be wrong there, though...

                Vic.

              2. Anonymous Coward
                Anonymous Coward

                Re: Because free software is SOOOOOO secure, many eyes and all that.

                [For the curious, "@apple" is not found.]

                What about in the BSD source code, considering they use FreeBSD as their codebase rather than Linux?

            2. Ken Hagan Gold badge

              Re: Because free software is SOOOOOO secure, many eyes and all that.

              "Never realised all their engineers are not paid."

              Ummm, wasn't your argument (a few posts ago) that commercial types didn't *use* free software, not that they didn't *produce* it.

          2. Anonymous Coward
            Anonymous Coward

            Re: Because free software is SOOOOOO secure, many eyes and all that.

            "Have you heard of Google, Amazon, Facebook, or Rackspace. And that's without even trying hard."

            Amazon, Facebook and Rackspace all use Windows desktops....None of them have as far as I am aware or can find any trace of have had large scale migrations from Windows to Open Source desktops.

            The point being made was that pretty much no one on Windows desktops and associated infrastructure stack is migrating or even considering migrating to Open Source. If there was money to be saved, then the fact that we are in a competitive market would mean that everyone would be beating a path en masse to the better mousetrap....But they are not. Therefore the logical conclusion is that the leaders of most companies have looked at the options an decided that at least for now, Microsoft gives the lowest TCO...

        2. Paul Crawford Silver badge

          Re: AC 12:33

          This would be the Munich that saved 11M Euros from migrating 98% of desktops then?

          http://www.pcworld.com/article/2082460/moving-a-city-to-linux-needs-political-backing-says-munich-project-leader.html

          Please try some new trolling, you are becoming tedious.

          1. Anonymous Coward
            Anonymous Coward

            Re: AC 12:33

            "This would be the Munich that saved 11M Euros from migrating 98% of desktops then?"

            That's from the dudes managing it. Hardly going to present the fact that they are a waste of money are they? They already stretched out a desktop migration project to a decade...

            The actual cost of the migration over ten years is currently estimated at about €61 million. Versus the cost of migrating to the latest Microsoft stack (according to Munic Council) of ~ €34 million. e.g. net cost of roughly €30 million. Some of that was eaten by IBM - e.g. costs of developing LIMUX, but clearly this was still a large net cost to Munich...

            1. Chemist

              Re: AC 12:33

              "Hardly going to present the fact that they are a waste of money are they"

              And your authoritative reference is ...........?

        3. Roo

          Re: Because free software is SOOOOOO secure, many eyes and all that.

          "Not when you allow for the TCO in most cases. A good example is Munich"

          Ah yes, Munich, that would be the one where Microsoft commissioned a TCO study that concluded it would have been cheaper to stick with Microsoft stuff, provided you didn't pay any license fees. Their figures were based on Munich paying $0 in CALs etc.

          Presumably you'd know that already because you've been told that already.

          1. Frank Gerlach #2

            Dollarsoft Operatives

            Out here, too. Good to know that their propaganda never sleeps and they allocate all their resources for propaganda instead of doing something useful in security.

            I always knew the smoke-generator was the most important part of a tank's defensive measures !

          2. TheVogon Silver badge

            Re: Because free software is SOOOOOO secure, many eyes and all that.

            "Ah yes, Munich, that would be the one where Microsoft commissioned a TCO study that concluded it would have been cheaper to stick with Microsoft stuff, provided you didn't pay any license fees. Their figures were based on Munich paying $0 in CALs etc."

            I guess you didnt understand what you were reading. There were 2 costs quoted. ~ €17 million to standardise on what Munich already had licenced and not include the cost of an upgrade (so no new license costs), and ~ €34 million to move to Windows 7 and associated toolset.

            1. Anonymous Coward
              Anonymous Coward

              Re: Because free software is SOOOOOO secure, many eyes and all that.

              "to standardise on what Munich already had licenced "

              To be fair if they could manage to use Open Office in a business scenario, then Office XP would probably do just fine....

    3. Dom 3

      Re: Because free software is SOOOOOO secure, many eyes and all that.

      The last few years I've been supporting a client who has a (relatively expensive) licence for a closed-source (and Zend-encrypted) PHP application. A few years back I noticed that the "display random image" feature was starting to get rather slow (client has more than 10^6 photos on site). With much wangling I extracted a non-encrypted version of the file from the vendor and discovered that they were using "ORDER BY RAND() LIMIT 1" in the SQL to select the photo. I rewrote it to ""SELECT COUNT(*)" to get the number of images and then used rand() in PHP to select one. So it ran about ten bazillion times faster.

      I submitted my patch to the vendor.

      More recently I wondered what they'd done with it so I requested an unencrypted version of the code from the latest release. And found this:

      "SELECT FLOOR(RAND() * (COUNT(*) - 1)) + 1 AS offset " in the SQL

      and then

      $selected = rand(0, $num_images-1); in the PHP.

      To save you the hassle I've done the workings; if you have three images then the first will appear three times out of four, the second will appear one time out of four, and the third will never appear.

      There's professional for you - even when *given* a working patch they can screw it up.

  15. majorursa
    Thumb Up

    Already fixed

    Nicest thing is that last night I saw an update for this issue. I don't normally check the updates but the 'X-windows' reference caught my eye. So it was fixed before its existence even reached The Register.

    1. sabroni Silver badge
      Thumb Up

      Re: Already fixed

      Only 22 years after it went in! Sweet!

      1. Paul Crawford Silver badge

        Re: Already fixed

        Its not like you will find a Windows bug going back as far they support something. Oh wait, here is a critical one for IE6 and all more recent versions as of mid-2013:

        http://technet.microsoft.com/en-us/security/bulletin/MS13-059

        OK, that one was only 12 years old.

        1. TheVogon Silver badge

          Re: Already fixed

          "OK, that one was only 12 years old."

          Try finding a commercial version of Linux still supported after 12 years...

    2. Pookietoo

      Re: Already fixed

      Is it not this that was in the Ubuntu changelog on 30th December?

  16. Joerg

    When any C/C++ code includes "goto" you know it sucks...

    This just proves how well written the open-source Linux myth software is written... Ancient code, sloppy design.. just beyond bad.

    Yes, there still is goto in C but anyone using it should have his/her brain checked. Clearly doesn't have a clue how to write proper C/C++ code.

    1. sabroni Silver badge

      Re: any C/C++ code, you know it sucks...

      FTFY....

    2. Anonymous Coward
      Anonymous Coward

      Re: When any C/C++ code includes "goto" you know it sucks...

      Nothing wrong with goto itself.

      Using goto to implement for/while/etc ... /that/ is wrong.

    3. Anonymous Coward
      Anonymous Coward

      Re: When any C/C++ code includes "goto" you know it sucks...

      You are wrong. It should be a rarity; but it can be the cleanest, most obvious way out of some awkward, irrecoverable situation and is better than an alternative I have seen (and even programmed once, oops) - abort(). I suppose abort() is the ultimate goto.

      Anon in shame.

    4. btrower

      Re: When any C/C++ code includes "goto" you know it sucks...

      You are correct. In fact, any unconditional jump in code is a potential source of bugs. In large bodies of code that potential is always realized. Examples:

      goto

      break

      continue

      setjmp/longjmp

      return

      Some usage cannot be avoided in C because it does not contain structured alternatives. When they can't be avoided (say in a switch() statement), they should be carefully used only to accomplish the necessary block exit and nothing else.

      For some reason we still see arguments in favor of 'goto'. Don't use it. It is not necessary and is a rich source of very nasty and difficult bugs. The only reason 'goto' exists in the C language today is for backward compatibility so that old code will not break. New code should never use goto. There is no practical exception to that.

      Any argument from efficiency for stuff like this is a failed argument. It is conceivable that you actually do have a compiler that cannot optimize that well. However, since all non-trivial bodies of code have bugs, you are not likely at an optimization stage of development. The only optimizations that should be done are ones required to meet some real-time constraint that cannot be met otherwise. Maybe a device driver writer can bend a rule to overcome a problem with a device, but even then it is iffy.

      A few simple 'good hygiene' habits ward off a lot of bugs, especially in older code:

      Always make things explicit. Do not do stuff like this:

      if(x)

      dothis();

      Do this instead:

      if(x) {

      dothis();

      }

      When using resources you are expected to release as the caller start with the allocate/release pair first and deal with failure then and there:

      a = allocate(n);

      if( a == NULL) {

      errmsg("Cannot allocate 'a'");

      } else {

      /* Code on successful allocate goes here */

      deallocate(a);

      }

      Note that any unconditional jump out of the part that deallocates will leave a memory leak.

      Eliminating bugs and getting correct behavior is job one. 'Efficiency' should only be a consideration when optimizing and optimizing should be mostly done by the compiler and should only be done by hand if it is actually needed.

      I see a lot of code that looks like this:

      if (cannot(x) ) return;

      if (cannot(y)) return;

      etc.

      It will inevitably develop bugs as time goes on and some of those bugs will be very hard to find and fix.

      Code blocks should have one single point of entry and one single point of exit. They should generally do one thing well and that is it. They should not have side effects and they should not depend upon side-effects. They should not depend on things that don't properly belong in their scope (no globals or 'relative globals'). In practice, my observation has been this: lots of smaller functions nested are easier to debug than fewer/flatter larger functions. Code so that a scoping block may be turned into its own function. For instance, even inside a function, declare variables within the narrowest scope possible.

      High level short-lived code done in languages with things like garbage collection can be forgiven a variety of bad habits. Low level long-lived code upon which many layers of client code depends needs to be coded with strict good habits.

      Good habits alone will not yield bug free code that is non-trivial. On top of good coding habits, you need to unit test with a goal of 100% coverage. You will find building in good unit testing much easier if you follow the rules of thumb above.

      You should assume that an item that has not been tested will fail.

      Chances are good that a modern compiler will be better at optimizing code than you are. Help it do its job by writing clear simple code in small well characterized chunks with no unstructured flow of control to confuse things.

      1. Primus Secundus Tertius Silver badge

        Re: When any C/C++ code includes "goto" you know it sucks...

        @btrower 14:40

        Real designers use flowcharts.

        Yes, I know they were ridiculed by the structured programming brigade, but...

        Flowcharts are two-dimensional, and make it much easier to understand the logic. In particular, to verify that all cases have been dealt with.

        Structured programming if used sensibly and non-dogmatically then imposes reasonable limits on what is permissible in the flowchart. GOTO is defensible if it makes sense in the flowchart.

        1. Destroy All Monsters Silver badge
          Facepalm

          Re: When any C/C++ code includes "goto" you know it sucks...

          > Structured programming if used sensibly and non-dogmatically

          Jesus Christ, the 70s called. They want their debates back.

          1. Anonymous Dutch Coward
            Coat

            70s debates

            At least with the 70s debates you know what the next big solution was that... sparked the debates of the 80s.

            Helps to make your arguments appear well-thought out and such. Give me old debates any day.

          2. RyokuMas Silver badge
            Mushroom

            Re: When any C/C++ code includes "goto" you know it sucks...

            Would prefer the odd goto than the absolute hideousness that is Javascript...

    5. T. F. M. Reader Silver badge

      Re: When any C/C++ code includes "goto" you know it sucks...

      @Joerg: OK, rewrite the following typical C code without goto, see if it turns out clearer or better in any way.

      int foo(void) {

      int rc = EXIT_SUCCESS;

      X* x = NULL; Y* y = NULL; Z* z = NULL;

      if ((x = malloc(sizeof(*x))) == NULL) {

      rc = EXIT_FAILURE;

      goto BAILOUT;

      }

      if ((y = malloc(sizeof(*y))) == NULL) {

      rc = EXIT_FAILURE;

      goto BAILOUT;

      }

      if ((z = malloc(sizeof(*z))) == NULL) {

      rc = EXIT_FAILURE;

      goto BAILOUT;

      }

      if ((rc = do_sth(x,y,z)) != EXIT_SUCCESS)

      goto BAILOUT;

      /* do more stuff... */

      BAILOUT:

      if (!z) free(z);

      if (!y) free(y);

      if (!x) free(x);

      return rc;

      }

      In C++ RAII helps with resource management[*] (exceptions not so much, besides, they are just another way of non-local transfer of control, not really conceptually different), but goto still turns out very useful when, e.g., you need to break from a nested loop when some condition is satisfied (break only breaks from the current level and throwing a custom structure as an exception is usually not the greatest of ideas if it is not, conceptually, an exception). This is not limited to C++, actually (e.g., java has a labelled break that basically is a crippled goto).

      [*] Whoever thinks of telling me to use a language with garbage collection instead of C please do the above exercise but open some files, socket connections, etc. Oh, and make sure nothing points to the objects you created on the heap in the end, or memory *will* leak.

      1. Charles 9 Silver badge

        Re: When any C/C++ code includes "goto" you know it sucks...

        OK, how about this? Only one additional nesting level and a slight inefficiency, but would this do?

        int foo(void) {

        int rc = EXIT_SUCCESS;

        /* Not the most efficient, but this is the time/space tradeoff. */

        X* x = malloc(sizeof(*x)));

        Y* y = malloc(sizeof(*y)));

        Z* z = malloc(sizeof(*Z)));

        /* To proceed, none of the three can be null. */

        if ((x != NULL) && (y != NULL) && (z != NULL)) {

        if ((rc = do_sth(x,y,z)) != EXIT_SUCCESS) {

        /* Everything works. Do whatever else here */

        }

        }

        else {

        rc = EXIT_FAILURE;

        }

        /* Do the cleanup here regardless of result */

        /* Franlkly, I'm of a mind to do an inline or macro here. */

        if (z != NULL) free(z);

        if (y != NULL) free(y);

        if (y != NULL) free(x);

        return rc;

        }

    6. Wilseus

      Re: When any C/C++ code includes "goto" you know it sucks...

      Back in the late 1990s when I worked in the games industry, I helped develop the renderer code for a PlayStation game we were working on. Above all, it needed to be as fast as possible in order to squeeze as much performance as possible out of the console. I optimised the C routine using amongst other things a couple of gotos, which as well as speeding things up greatly, also made the code a lot more readable.

      That didn't stop the idiot of a project manager telling me off for "bad programming" though. He didn't even have a background in programming, whereas I grew up in the 1980s and remember first hand all the goto debates in the magazines of the time! Of course in those days the main problem was that the BASIC implementations on many of the 8-bit micros of the time didn't have a line renumber facility, making gotos a necessary evil if you ran out of line numbers to insert!

  17. Frank Gerlach #2

    Systematic Fix: Type Safe Programming Language

    Now that we know that the Cyber War Domain is a very real, exisiting thing and that some governments actively build+stockpile malware, I don't think it is sufficient to look at source code and fix what we can find.

    Rather, we need to stop using C and C++. Or at least, stop using plain C++ arrays, pointers and quite a few nasty C/C++ "tricks".

    Software engineers and even more so "programmers" will always be under intense pressure to "deliver" and simply won't have the time or resources to look into all possible exploit possibilities. The unsafe features of C and C++ are not really required, conceptually speaking. Compilers could be quite smart about optimizing away bounds checks on arrays (e.g. inside a for loop it must be done only once).

    THIS is the way to go:

    http://en.wikipedia.org/wiki/Type_safety

    http://sourceforge.net/p/sappeurcompiler/code-0/HEAD/tree/trunk/doc/manual.pdf?format=raw

    http://www.rust-lang.org/

    Finally, there have been quite a few operating systems built in other languages than C or C++. See HP's MPE for example. Very successful, very stable, killed not by customer but by MBA.

    1. btrower

      Re: Systematic Fix: Type Safe Programming Language

      Frank Gerlach #2:

      You can make C typesafe by creating types and methods that are safe.

      At the level in question, C is being used as an alternative to Assembly Language, not as an alternative to Ada.

      Although there is not much of a performance hit for a check on the size of a target buffer vs the data being written, you will see performance issues when these things are nested very deep and the checks are done over and over again at each level. Some called functions require the caller to provide safe arguments:

      strncpy(s1, s2, n);

      The above will ensure the length being written will not exceed n. It will not and should not validate that s1 is a valid target or that s2 is a valid source.

      Management hires people who do not have the skills to do it properly and then rush them so they can't even test to find their mistakes. Software development, by its very nature, is something of a research issue. It requires 'enough' time and 'enough' is hard to pin down.

      Management demands project plans whose specificity virtually guarantees failure and the larger the project and more it is micro-managed the more likely it is to fail.

      We have a massive over-abundance of code in all languages, but are painfully short on solid working code even for basic things.

      1. Frank Gerlach #2

        Re: Systematic Fix: Type Safe Programming Language

        I wonder how you would make Array Access typesafe in C (not C++) ?

        Also, properly optimizing compilers can safely remove lots of bounds checking, as overruns are very often known at the beginning of a loop.

        And: do we need to use a portable assembly language for anything "efficient", just because we need it for a very small part of the operating system ? Even the vast majority of kernel code does not need to be type-unsafe. Both MPE and Oberon prove this.

        1. btrower

          Re: Systematic Fix: Type Safe Programming Language

          @Frank Gerlach #2:

          You make good points, particularly when you say '"stop using plain C++ arrays, pointers and quite a few nasty C/C++ "tricks"/.

          Re: "I wonder how you would make Array Access typesafe in C"

          It can be done. Don't use naked pointers where it could be an issue. Make an array type with info as to length, etc of structures. One of the big issues with C, from my point of view is that its maintainers are content to have a souped up assembly language rather than just a real modern language. I have been looking into how one might fix that myself. I think it is possible.

          Re: "properly optimizing compilers can safely remove lots of bounds checking, as overruns are very often known at the beginning of a loop"

          I emphatically agree with this, even in a broader sense. A programming language like Modula or Oberon (or Ada) that gives the compiler lots of information allows the compiler to do all sorts of compile time optimizations. In theory, a language that gives the right type of information to a compiler with sophisticated optimization should be able to beat a human at optimizing the overall code. I have, for many years now, adopted the stance that the compiler gets the first crack at optimization and only if it fails and the optimization is needed do I step in to hand-code.

          Re: "do we need to use a portable assembly language for anything "efficient", just because we need it for a very small part of the operating system ?"

          No. However, it seems to me that C is tantalizingly close to a good general purpose replacement for everything including Assemblers and Scripting. C, on its own, is perfectly capable of supporting very elaborate abstractions. To fix its few problems, it seems to me that it just needs a few tiny nudges to better rationalize and integrate the pre-processor, provide support for Objects, bring functions up to first class objects, some refinement of syntax to allow nesting of functions and a bunch of ancient assumptions ripped out such as the special treatment of source code in disk files. The compiler should worry about finding and integrating called function and the default language run-time should default to values that would allow simple scripts to be written directly. Here is what the famous 'Hello World' program should look like in its entirety:

          "hello, world"

          The proof of utility of the C-language family (including C++, C#, Java, ECMAScript, Objective C, golang, etc) is its ubiquity. The proof that it requires refinement is evident in the proliferation of the C-like languages. Each aims to correct perceived deficiencies in C. I think that a good re-think of the language could allow us to toss C++, C#, Java, Objective C, golang, etc. I have a hunch that done right it would actually decrease the size of the base language.

          Re: "Even the vast majority of kernel code does not need to be type-unsafe. Both MPE and Oberon prove this."

          Don't get me wrong, I am a big believer in the utility of type safety and other facilities that protect programmer's from themselves. Most programmers do not belong in charge of a C compiler. I gave up on Oberon for various reasons, but was a Pascal and Modula 2 programmer in the early 1980s even before I learned C. I preferred Modula to C for many reasons. However, at the end of the day, for a programmer that can handle a C compiler, Pascal and Modula (and from the looks of it Oberon) are like programming with mittens on. Part of its strength in abstracting the machine is also a part of its weakness.

          Good teams can make a pretty good go at modest programs using nearly any language. Bad teams can make a mess of modest programs using nearly any language. We have a lot of extremely well trained and practiced people out there including project managers, build specialists, designers, analysts and coders. We could accomplish a great deal just by funding the good ones and getting the bad ones out of their way. Unfortunately, the people deciding on which teams get assembled are generally pretty hopeless.

          We do not reward technical success very well. One of the very best projects I worked on was with Sybase to produce a replacement billing system for a large leasing company. It was a team of maybe a hundred or so people and virtually every one was a seasoned professional near the top of their game. The project was delivered beyond spec, below budget and slightly ahead of time. That team was eventually disbanded because even though they got better results for (much) less money, the sales process above them could not compete with the bigger more ruthless players.

          For projects like the above, there is not a lot of repeat business if you do your job well. The job is done and systems like that stay in place under low maintenance for many years.

          Love it or hate it, C continues to exert influence because it gets the job done. Warts and all, it is often better than the alternatives. I honestly think that C can be cured of some of its ills, but things like C++, Java or C# are not that cure.

          1. Frank Gerlach #2

            Throwing C#, C and C++ In One Pot

            ...does not make sense. Naming and syntax are quite irrelevant.

            What matters to me is

            A) Type safety. C# and C are in very different camps on this aspect.

            B) runtime efficiency. Again C# in a very different camp. In the "systematically inefficient camp", more precisely

            If you want to categorize things, put C#, Java and Mono in one pot. They are conceputally similar in efficiency and security.

            C and Assembler belong in another pot.

            A third pot might be Ada, Modula 2, Sappeur, Rust.

          2. Roo

            Re: Systematic Fix: Type Safe Programming Language

            "it seems to me that it just needs a few tiny nudges to better rationalize and integrate the pre-processor, provide support for Objects, bring functions up to first class objects, some refinement of syntax to allow nesting of functions"

            Interestingly C++ started life as an C pre-processor, and one of the requirements was that it was backward compatible with C... It sounds like you may be treading the same path - with different set of constraints. You could try working from the other direction, ie: start with BCPL and work your way through to C+Hindsight. ;)

            The thing that surprises me is that you seem to have missed a huge hole in C, explicit support for parallelism. Even doing the bare minimum like supporting a subset of OCCAM constructs like ALT, PAR, PROC & CHAN could help fix an awful lot of broken/unnecessarily complex threaded code.

            "I think that a good re-think of the language could allow us to toss C++, C#, Java, Objective C, golang, etc. I have a hunch that done right it would actually decrease the size of the base language."

            If you go the BCPL first route I think you have a good chance of achieving that aim, it is a *very* simple language that (allegedly) informed the development of C. If it was me undertaking such a project I think I would be starting at BCPL + CSP level and clone the missing bits of C that I feel I really need. The thing about C/C++ is that the standards committees and compiler writers have actually got the languages to the point where they are actually pretty well defined - and the error checking turned up to 11 tends to weed out the majority of bone head bugs.

            We have come a long way from Microsoft's early C compilers that didn't do type checking (thus begetting Hungarian notation - yuck), and compilers that didn't check arguments (anyone else remember wrangling K&R style code ?) ... ;)

    2. Destroy All Monsters Silver badge

      Re: Systematic Fix: Type Safe Programming Language

      "Rust" is the way to go?

      What's your opinion about Rust?

      For all that is holy, no.

      1. Frank Gerlach #2

        Regarding Rust

        Well, maybe they are quite exotic and their ideas have not yet been properly worked out in a non-contradictory fashion.

        BUT, at least Mozilla seems to do something about the issue of security of a very popular web browser. And they don't follow the rather simplistic path beaten by Java.

        That may be because I wrote an email regarding my language Sappeur to Brendan Eich a couple of years ago. They apparently decided that it would be boring to just use my approach, so they added another layer of half-finished concepts to their contraption.

        Again, at least they do something about the C and C++ misery.

        1. Joerg

          Re: Regarding Rust

          The misery is with people.

          There is nothing wrong with C/C++.

          It's most people brains thinking to be so smart programmers that actually don't have a clue what they are doing and should be fired because they are not real programmers at all. Most programmers are just arrogant ignorant people.

          True programmers are a few.

  18. DB2DBA

    z

    This article gives me a greater appreciation for the S0C4.

  19. Jodo Kast

    always a bummer

    always a bummer when straight forward bugs are finally discovered...

    I guess the fun comes to and end for all things.

  20. Anonymous Coward
    Anonymous Coward

    Shouldn't a modern compiler flag such code?

    I haven't written code in decades and then it was Assembler or BASIC but I thought the big selling point for compilers was their automatic flagging of such potential problems?

    Or have I missed something?

    1. Ken Hagan Gold badge

      Re: Shouldn't a modern compiler flag such code?

      If by modern you mean 20 years old, then certainly. Gimpel's PC Lint certainly checked that sort of thing as long ago as last century, and I'm pretty sure I used a C compiler at uni (so, 1990-ish) that checked any visible printf or scanf format strings.

      If this bug is really only 22 years old, it should have been strangled at birth.

      And whilst I'm posting, the hideously unsafe functions in the C standard library were known to be hazardous to health when they were added to C89, but the ANSI/ISO folks had a remit to standardise existing practice so they were forced to rubber stamp all the old shit that had picked up a following in the 1970s. Perhaps some youngsters came along too late to understand that point when they were learning the language.

      1. Frank Gerlach #2

        Don't Whitewash

        All the books on C I read in the 90s didn't ever talk about security risks related to strcpy() and its Evil Sisters.

        And most of today's efforts are very half-hearted, because "IT" is very much a horizontal business of actors who are solely in this for MONEY.

        There are very little conceptual debates going on, instead "latest concept to lure John Dollar" are heavily discussed. Have you said "cloud" today ?

        1. Roland6 Silver badge

          Re: Don't Whitewash

          >All the books on C I read in the 90s didn't ever talk about security risks related to strcpy() and its Evil Sisters.

          In the 80's there were some C books that focused on style, but these tended to talk about risk of buffer overrun and so advise caution about the handling of character arrays as strings etc. I suspect it is only in more recent times that we've begun to understand the security risk angle inherent in buffer overruns etc. when these are held on a common stack, with little or no stack protection.

          Interestingly, I would be interested to know if Linux actually fully utilises the stack and memory protection features that Intel first incorporated in the 286 and were enhanced in later x86 chips.

  21. Peter Gathercole Silver badge

    How times change

    I'm putting my old-foagy hat on here, because there is a lot of history behind X.

    When X was first deployed in the mid 1980s and early 1990s, it used to be that you did not have a graphical login. The sequence was nearly always that you logged in using a text-based login mechanism, and then you started X up with startx or xinit command.

    What this meant was that the X-server was run as you as a user, rather than as root, a privileged user. Indeed, as I write this, I've just switched across to an AIX 7.1 system that does run an X server (it's the enterprise management system for an AIX cluster), and I can see that the /usr/bin/X11/X binary does not even have the set-uid-on-execution bit set, so on a traditional UNIX system using code derived from the MIT X11 code, the X server certainly does not need to be run as root when started using the old methods (I've just tested this as well, and startx still works, and still starts up MWM on an AIX system. How quaint!)

    Whilst this does not alter the fact that an oversight in the code could cause the problem documented here, it would mean that any exposure will not have root access.

    At some point, some bright-spark decided that a graphical login process was a good idea, so they started X (as root) before the user logged in. I would need to check, but I'm fairly certain that the original xdm (X Display Manager) actually re-spawned the X server as the user when you logged in on the console of a system, but it is certain that the CDE dtlogin, and GDM and whatever KDE uses for graphical logins keeps the server running as root, with the correct X cookies in the xauth file to allow the user's X clients to connect.

    This is a broken concept. It was originally intended that the X server process should be running as a non-privileged user. It would have been pretty simple to start the X server as a non-root placeholder user, rather than root, but I guess that nobody thought of it as a problem.

    I'm not sure whether there are any of the X extensions (like DRM) which need to be able to talk directly to the hardware as a privileged user, but the original intention was that the X server would not be privileged.

    But anyway, who uses BDF fonts any more. They're pretty obsolete, and to exploit this, you would have to put a compromised font in the correct place, and then re-start the X server. As the default locations for the fonts are in a directory that an ordinary user does not have access to, as is the initial starting configuration for the X server, it would require root access to put the fonts file in the directories in the first place, which rather negates the value of the exploit! If I already had root access on a system, there are a whole load more back-doors that I could add without going through this rigmarole.

    I suppose it may be possible to place the font file in the users own file space, then trigger a font path change and/or font rehash with the server running. It would be interesting to see whether this would actually crash the X server. I might give it a try.

    1. Frank Gerlach #2

      Dangerous Arguments

      1.) Compromising the X server means compromising a user's keyboard and that implies passwords and cryto passphrases

      2.) A single user's resources (all the files, database connections etc he/she can access) are very often a sufficiently juicy target for an attacker.

      So, your arguments are kind of superficial. Why do I need root access if I can target the one guy with admin access to the Oracle database ? Or to the telecom admin system of Belgium.

      1. Peter Gathercole Silver badge

        Re: Dangerous Arguments

        OK. Lets assume that you can compromise the X server by adding this compromised font to a user writeable directory, and forcing a font rehash.

        To do this you need to run commands as that user anyway! Again, if I can do that as a user with some privilege, I can by-pass the X server exploit because I'm already running commands as the user!

        Please keep up.

        Actually I can think of a way of doing this without needing to run commands as the user, but I would need a valid copy of the xauth magic cookie. But if you've got a copy of the magic cookie, you can do all of the key stroke and screen capture you talk about anyway, so again the exploit is superfluous.

        1. Bronek Kozicki Silver badge

          Re: Dangerous Arguments

          Right, but if you can compromise font in a user writeable directory and then force X server running as a root to read this font, you have just raised your access rights from user to root.

          Which is pretty serious.

          1. Charles 9 Silver badge

            Re: Dangerous Arguments

            The point is that it becomes a Catch-22. In order to make the X server do what you want, you have to gain the same escalations this exploit is supposedly able to provide. To paraphrase Spike Milligan, you'd be trying to open the box with the crowbar you'll find inside.

            Unless you're saying there's a way to insert the malformed BDF AND force the font refresh without any prior privilege escalation or user takeover?

            1. Vic

              Re: Dangerous Arguments

              Unless you're saying there's a way to insert the malformed BDF AND force the font refresh without any prior privilege escalation or user takeover?

              Yes, there is.

              G/L has long supported user-specific fonts - you just make a directory in your home area, stick your fonts in there, and run the appropriate font cache command. This is all part of making the OS "friendlier"...

              Logging out and back in again usually restarts the X server. And there is the exploit.

              This is serious, but probably not nearly as bad as certain people will make it out. Aside from the difficulty in getting an appropriately-crafted BDF font onto the victim machine (since most will just cause a font server crash, rather than actual execution of anything), the most valuable machines invariably run headless, so they won't be running a font server at all.

              Nevrtheless, I'm glad to see upstream fixes already pushed out in the repositories I use.

              Vic.

            2. Bronek Kozicki Silver badge

              Re: Dangerous Arguments

              In order to make the X server do what you want, you have to gain the same escalations this exploit is supposedly able to provide

              Only if that X server was not already configured earlier by an idiot (or clueless distribution default) to read fonts from user-writeable directory. Because if it was, you have your crowbar already lying next to the box, not inside.

  22. Anonymous Coward
    Anonymous Coward

    Holy Mother of Fsckin' God

    A more honest approach

    #define CrashAndBurnAsThisWasCodedByAnIdiot(a,b) sscanf((char *)(a), "STARTCHAR %s", (b))

    if (CrashAndBurnAsThisWasCodedByAnIdiot(line, charName) != 1) {

    ...

    }

  23. mIRCat
    Linux

    That's where we left it.

    It wasn't found sooner because someone forgot...

    //Leaving bug here.

    Comment your code, peoples.

  24. baz rowlingson

    No big deal

    So this exploit lets you crash and possibly code-inject the X server. First, you need to have permission (via the Xauth mechanisms) to the server. So that's usually the screen of the machine you are sitting in front of, unless someone has given you their Xauthority file.

    If its the machine you are sitting in front of then you have physical access and there are easier ways to get root.

    This can only be a problem if your screen is on a long cable or KVM extension from a locked room or cupboard, or if the machine case is locked (although lockpicking exists) and alarmed.

    If you remote login with (X11 forwarding) into another machine and try this exploit, you'll crash the Xserver on your local machine. Epic fail.

    1. diodesign (Written by Reg staff) Silver badge

      Re: No big deal

      Or.

      They could have boundary checked the font file parsing.

      C.

    2. Frank Gerlach #2

      Careful

      This specific bug might be not a security issue. But the X.org server running with UID 0 and processing all user input/ouput is indeed are very sensitive system.

      If X.org has exploitable bugs (which we have to assume) you only need an additional firefox bug (whether that one is sandboxed or not does not matter) to own the kingdom, drive-by-style.

      Maybe that's how Government Criminals Headquarters did it to Belgacom.

      1. Anonymous Coward
        Anonymous Coward

        Re: Careful

        "But the X.org server running with UID 0"

        Why don't they just use constrained delegation like in Windows to limit it's access rights?

        1. Charles 9 Silver badge

          Re: Careful

          Can any user other than root get to-the-metal access (since many modern X systems can use hardware-assisted rendering and need to-the-metal access for performance reasons)?

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2019