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.
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.
@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.
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...
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!
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...)
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.
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!
"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.
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.
"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.
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.
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...
> 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...
> 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.
This post has been deleted by its author
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.
This particular bug seems to have been known since 2007.
Either there has been a regression, or earlier reports were ignored, I don't know.
@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.
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!
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 ...
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
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.
>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 !
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.
@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:
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,
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".
"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...
"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.
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).
@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.
"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...
"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...
"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.
"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.
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.
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.
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.
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.
@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.
@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.
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;
}
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!
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.
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.
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.
@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.
...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.
"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 ?) ... ;)
"Rust" is the way to go?
What's your opinion about Rust?
For all that is holy, no.
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.
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.
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.
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 ?
>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.
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.) 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.
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.
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?
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.
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.
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
