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 …
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.
> 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?
@ 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.)
@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.
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)
"(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.
(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 :)
@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".
@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.
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?
"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!
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.
"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.
"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....
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...
""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....
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 defacers is the CVE-2010 – 3301, that was fixed in 2007 and was mysteriously reintroduced in 2008, in a large pile of kernel versions x86_64."
Hey look, someone who's heard of CVE. How often does that happen round here ?
Have a lot of fun.
"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.
"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.
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.
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.
"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.
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.
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.
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)
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.
This post has been deleted by its author
>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...
> 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.
"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.
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.
'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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
