Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

23-Year-Old X11 Server Security Vulnerability Discovered

Unknown Lamer posted about 9 months ago | from the stack-smashing-for-fun-and-profit dept.

X 213

An anonymous reader writes "The recent report of X11/X.Org security in bad shape rings more truth today. The X.Org Foundation announced today that they've found a X11 security issue that dates back to 1991. The issue is a possible stack buffer overflow that could lead to privilege escalation to root and affects all versions of the X Server back to X11R5. After the vulnerability being in the code-base for 23 years, it was finally uncovered via the automated cppcheck static analysis utility." There's a scanf used when loading BDF fonts that can overflow using a carefully crafted font. Watch out for those obsolete early-90s bitmap fonts.

Sorry! There are no comments related to the filter you selected.

Many eyes... (5, Insightful)

Anonymous Coward | about 9 months ago | (#45897705)

...looking elsewhere.

Re:Many eyes... (2, Insightful)

i kan reed (749298) | about 9 months ago | (#45897725)

The real trick of the "With enough eyes all bugs are shallow" is that the function for "enough eyes" is exponential with respect to lines of code, and open source projects don't actually hit it.

Re:Many eyes... (1)

hummassa (157160) | about 9 months ago | (#45897787)

s/open source/no/ TIFIFY

Re:Many eyes... (2)

i kan reed (749298) | about 9 months ago | (#45897819)

"no project don't actually hit it"

I think I've found a bug in your perlscript.

Re:Many eyes... (5, Funny)

Bacon Bits (926911) | about 9 months ago | (#45897849)

With enough Perl, all eyes are bleeding.

Re:Many eyes... (4, Funny)

NoNonAlphaCharsHere (2201864) | about 9 months ago | (#45897915)

With enough Perl, all eyes are bleeding.

Let's see if that's true:

print "$#_ [@_]\n\n";

GAAAAAAAHHHHH!!!!!
OK, point taken.

Re:Many eyes... (0, Flamebait)

RoverDaddy (869116) | about 9 months ago | (#45898099)

Sorry, posting to remove erroneous moderation. Me and my clumsy fingers. Consider yourself getting +1 Funny.

Re:Many eyes... (4, Insightful)

grub (11606) | about 9 months ago | (#45897829)

"Many eyes" is bogus, "the right eyes" is more appropriate.

Re:Many eyes... (1)

i kan reed (749298) | about 9 months ago | (#45898043)

Also bologna. There isn't such a thing as bug-spotting super powers. The most reliable way to detect bugs is testing, of multiple stripes, unit testing, regression testing, all the testing(and I'm a developer, so I detest QAs)

Re:Many eyes... (1)

Warbothong (905464) | about 9 months ago | (#45898541)

"Many eyes" is bogus, "the right eyes" is more appropriate.

In this case "the right eyes" are robotic.

Re:Many eyes... (0)

Anonymous Coward | about 9 months ago | (#45898041)

"many eyes make bugs shallow" only applies to obvious bugs.

For security problems you need skilled knowledgeable eyes. There aren't that many of those, not all are looking at the stuff you use, and even if they are not all of them are on your side ;).

You could have a billion monkeys looking at code and they won't be able to tell you where the security bugs are.

Re:Many eyes... (1)

i kan reed (749298) | about 9 months ago | (#45898085)

won't be able to tell you where the security bugs are.

They're laying maggots in the poo that was flung at screen.

Re:Many eyes... (1)

tibit (1762298) | about 9 months ago | (#45898109)

Not only that - some software just isn't all that racy to begin with. X11 is not really the kind of code I'd find exciting to muck with...

Re:Many eyes... (2)

hairyfeet (841228) | about 9 months ago | (#45898485)

In reality "many eyes" is a myth because for "many eyes" to work you'd need 1.- Eyes willing to look at the ENTIRE code, since no code is used in a vacuum, 2.- those eyes have to have the years of experience in low level coding so as to be able to even spot the bug, and 3.- Those eyes have to be willing to do keep checking because new releases keep coming and with them new bugs.

Anyone can do basic math and see how "many eyes" simply cannot work and I'd bet my last buck that if you looked at the logs you'd find the majority of code? Not being looked at by anybody but the guys actually writing the thing. Being FOSS really only gives you ONE major advantage and that is that nobody can just pull the plug, if you need an old version? You can DIY or pay somebody to do it for you. But security wise? Nope, sorry, because OSes are some of the most complex software on the planet and even Torvalds can't tell you with 100% certainty what goes on and what is called when you launch a piece of software, its just too complex with too many interactions.

Re:Many eyes... (0, Flamebait)

smash (1351) | about 9 months ago | (#45897959)

LINUX PLUS X11 IS MORE SECURE THAN WINDOWS WILL EVER BE AND I WONT HEAR ANYUONE SAY OTHERWISE!!1

... Makes for falling behind everyone else.

Now, i need to fill the text box with lowercase letters to get rid of the caps warning.

Re:Many eyes... (4, Insightful)

hawkinspeter (831501) | about 9 months ago | (#45898131)

I'd recommend running the same tool (cppcheck) on the Windows source code before trying to be ironic.

Re:Many eyes... (0)

Anonymous Coward | about 9 months ago | (#45898201)

No one claimed windows didn't have vulnerabilities. Only that the attitude that linux is super secure and impenetrable is invalid.

Re:Many eyes... (1)

hawkinspeter (831501) | about 9 months ago | (#45898361)

Sounds like a straw man kind of argument. Who is claiming that linux is super secure and impenetrable?

Re:Many eyes... (0)

Anonymous Coward | about 9 months ago | (#45898467)

le reddit

Re:Many eyes... (1)

hawkinspeter (831501) | about 9 months ago | (#45898561)

You'd be better off posting there, then.

Re:Many eyes... (1)

PPH (736903) | about 9 months ago | (#45898287)

Windows source code

Ow! My sides!

Re:Many eyes... (1)

Lumpy (12016) | about 9 months ago | (#45898149)

Well the fact that you would have had to install this old outdated style font in order to trigger this.. Yes it is still secure. It can be used once you have a user login compromised, but windows is a freaking open book once that threshold is crossed.

Re:Many eyes... (1)

MtHuurne (602934) | about 9 months ago | (#45898531)

Just because a lot of people use the compiled product, doesn't mean a lot of people read the source code. One of the X developers had a presentation slide that read "three people on this earth understand X input", followed by a slide "really wish I wasn't one of them" (video [youtube.com] ).

It does really help though to have multiple developers prod at your code. Compiling it with different compilers and for different CPUs and operating systems will unearth bugs. Using it in different scenarios will trigger bugs. Running different static code checkers will find bugs (like the one from TFA). And having people read the code and ask "why do you do that there, it seems weird" will often point to bugs.

So many eyes certainly help code quality, but a lot of code doesn't get all that many eyes.

scary (1)

uglyduckling (103926) | about 9 months ago | (#45897711)

Amazing how an automated tool can spot something like this after so many years.

Re:scary (3, Insightful)

Anonymous Coward | about 9 months ago | (#45897835)

Given that you need to be using obsolete 90s bitmap fonts for this to be an issue, and that X11/X.org is never run as root, I'm not sure that "scary" is the word for this (there's a reason it hasn't come up before in the 23 years since it was introduced).

Nonetheless, I'll be upgrading my X.org package just for thoroughness.

Re: scary (0, Informative)

Anonymous Coward | about 9 months ago | (#45897937)

Uhh bonehead the X binary is suid-root so it can mmap the video RAM and device registers. Even though it drops root after it holds the keys to the kingdom. It can cause the graphics card to DMA over the kernel.

Re:scary (0, Insightful)

Anonymous Coward | about 9 months ago | (#45897969)

Hasn't come up before? The Snowden docs suggest the NSA has been using this (and/or other X bugs) for years.

Re:scary (5, Insightful)

buchner.johannes (1139593) | about 9 months ago | (#45897987)

Given that you need to be using obsolete 90s bitmap fonts for this to be an issue, and that X11/X.org is never run as root, I'm not sure that "scary" is the word for this (there's a reason it hasn't come up before in the 23 years since it was introduced).

Correct in principle, except for two remarks:

  • X runs as root, and has always. Just like getty.
  • If you craft a new bitmap font, running "xset fp+" as a user has the potential to gain you root privileges.

So yes, not "scary". Just a critical security bug.

Re:scary (1)

hawkinspeter (831501) | about 9 months ago | (#45898093)

I'm running on Ubuntu and X is run as root. I'm just glad that the internet servers I set up don't run X.

Re:scary (2)

Bill, Shooter of Bul (629286) | about 9 months ago | (#45897949)

Not amazed at all. Tools are much better at detecting these kinds of bugs than humans, with out limited stack space. And as time goes on, we build better tools. I'm not really surprised at all that humans aren't spending their time poring over the intricacies of an old font loading section.

Especially not surprised that people aren't looking for local privileged escalation vulnerabilities.

Also not surprised as X's security model has been known to be flawed for years.

http://it.slashdot.org/story/13/12/31/2127243/x11xorg-security-in-bad-shape [slashdot.org]

Re:scary (5, Insightful)

PPH (736903) | about 9 months ago | (#45898243)

Right. And this is why its so important to have the source code available. Some argue, "Who actually looks at this stuff?" Well, here's an example of someone who did. Not in the classical sense of some aspie code geek reading it by hand. But just feed it to some automated tools and see what pops out.

Re:scary (1)

noh8rz10 (2716597) | about 9 months ago | (#45898379)

We don't know who found the bug. If it was someone from the development team then this is equivalent to a closed source situation. Not an argument for open = better.

replace it goddamn it (-1)

Anonymous Coward | about 9 months ago | (#45897727)

cmon u billion dollar companies through some money at it - while your at it - lets sort out that god damn nfs.

Privilege escalation is to the server credential (0)

tlambert (566799) | about 9 months ago | (#45897737)

Privilege escalation is to the server credential. Modern X11 is never run as root. This is sensationalism.

Re:Privilege escalation is to the server credentia (4, Insightful)

i kan reed (749298) | about 9 months ago | (#45897797)

Root isn't the only kind of vulnerability. Seizing control of peoples' UIs is a pretty big deal(especially as far as phishing or keylogging goes).

Re:Privilege escalation is to the server credentia (0)

Anonymous Coward | about 9 months ago | (#45898197)

or like up say...apache...or the database or real users... who cares about root anyway - when the stuff doing actual work and has access to data is run by other users. escalation is escalation

Re:Privilege escalation is to the server credentia (1)

davydagger (2566757) | about 9 months ago | (#45897845)

considering my browsing history, and a good chunk of personal information, to include my music collection is not root, someone with access to my non-privliedged user can do a fuckton of damage still.

Re:Privilege escalation is to the server credentia (5, Informative)

10101001 10101001 (732688) | about 9 months ago | (#45897917)

Did you actually even bother checking this? No, most modern X11 servers run as root so they can* have hardware access to GLX and DRM. But, please tell me, which distro or OS do you run that runs your X11 server as non-root? Because I'd love to use a system like that.

*Technically, privilege separation is quite possible on these points, which has been done in OpenBSD AFAIK, but very few people use OpenBSD and I think the whole point of your post was about what the vast majority of people use. Otherwise, you're just quibbling over the point without stating it that most people don't run a "modern" X11 server.

Re:Privilege escalation is to the server credentia (-1)

Anonymous Coward | about 9 months ago | (#45898039)

Did you actually even bother checking this? No, most modern X11 servers run as root so they can* have hardware access to GLX and DRM.

Did you actually bother to check on multiple platforms? It's only on FreeBSD that the X server runs on root (it's actually worse: it is setuid root). On most other platforms, including most Linux distros, X server runs as non-root user.

Re:Privilege escalation is to the server credentia (0)

Anonymous Coward | about 9 months ago | (#45898227)

Number of ./ ignorants like you is staggering.

Re:Privilege escalation is to the server credentia (3, Informative)

drinkypoo (153816) | about 9 months ago | (#45898285)

Did you actually bother to check on multiple platforms? It's only on FreeBSD that the X server runs on root


drink@alexander:~$ cat /etc/issue
Ubuntu 13.10 \n \l

drink@alexander:~$ ps auxw | grep X
root 1267 2.3 1.1 348276 96612 tty7 Ss+ Jan05 105:36 /usr/bin/X -core :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

hmm.

Re:Privilege escalation is to the server credentia (1)

Anonymous Coward | about 9 months ago | (#45898205)

On certain non-x86 architectures X can be run without the kernel aperture driver in the OpenBSD. I have no idea how Linux has implemented these things, though.

Re:Privilege escalation is to the server credentia (1)

serviscope_minor (664417) | about 9 months ago | (#45898469)

Does that matter? With code pages marked as read-only and data pages marked as no execute is it even possible to turn such a buffer overflow into an exploit other than DoS any more?

Re:Privilege escalation is to the server credentia (3, Informative)

ajdlinux (913987) | about 9 months ago | (#45897941)

My Debian unstable installation would beg to differ.

$ ps aux
[...]
root 24768 6.1 0.4 183832 34716 tty7 Ss+ Jan08 14:15 /usr/bin/X :0 vt7 -br -nolisten tcp -auth /var/run/xauth/A:0-86aX4a

Re:Privilege escalation is to the server credentia (0)

Anonymous Coward | about 9 months ago | (#45897945)

Privilege escalation is to the server credential. Modern X11 is never run as root. This is sensationalism.

The X.Org Security Advisory thinks otherwise:

including the Xorg server which is often run with root privileges or as setuid-root in order to access hardware

You may not be vulnerable, but someone (possibly Younger You) is.

Re:Privilege escalation is to the server credentia (1)

Anonymous Coward | about 9 months ago | (#45897971)

Modern X11 servers do run as root. OpenBSD an XQuartz are the exception. Solaris kinda drops privileges, but keeps the root as saved uid. Linux distro's (Fedora, OpenSuSE, Debian, ubuntu, slackware, ...), FBSD, NBSD, hell, even Minix, all run it all as root.

Re:Privilege escalation is to the server credentia (1)

Chemisor (97276) | about 9 months ago | (#45898017)

> Modern X11 is never run as root

On Arch, at least, X is still run as root. I don't know about other distributions, but I would guess it is quite common. Also, because most of us like to actually use graphics for games and stuff, we run binary drivers. Can nVidia's drivers and Catalyst run with a non-root X? Neither supports KMS, so it seems the answer would be no.

Re:Privilege escalation is to the server credentia (1)

dpilot (134227) | about 9 months ago | (#45898451)

I'm under the impression that with KMS the display-side of X no longer needs root, but that there's something about input handling that still does. As you say, non-KMS drivers would still need root.

I would expect that privilege separation could be used here, a small root stub to do the root-only things, and the rest of the server running with dropped privileges. In that situation, could the server even run as "nobody"? After all, content comes through the socket.

Re:Privilege escalation is to the server credentia (1)

organgtool (966989) | about 9 months ago | (#45898107)

You think that giving an unknown untity read, write, and execute access to all of your files and executables is sensationalist? It may not be as bad as getting root, but it is certainly a problem. And given that there are numerous ways of embedding fonts in file formats such as Flash and PDFs, it may be possible to get hit by this just by browsing the web. That doesn't even begin to describe all the damage it could do by downloading custom malware that keeps the door open for authors to upload new malware, especially after the potential exploit scans all of the processes running on the machine running as root and determines which version is running for each process. Cross-reference that with a list of known vulnerabilities for that software version, use your custom server process to upload and execute the new exploit and you've got root. Yeah, it's work, but I imagine getting your foot in the door is the hardest part and that's exactly what this vulnerability could easily do.

Re:Privilege escalation is to the server credentia (1)

aethelrick (926305) | about 9 months ago | (#45898315)

...unknown untity...

is this some sort of mysterious zombie boob?

Re:Privilege escalation is to the server credentia (1)

Anonymous Coward | about 9 months ago | (#45898273)

Privilege escalation is to the server credential. Modern X11 is never run as root. This is sensationalism.

This is why I run X9 still... I wasn't convinced that the bugs in X11 have been worked out yet -- and I was right!

Re:Privilege escalation is to the server credentia (1)

noh8rz10 (2716597) | about 9 months ago | (#45898395)

Any truly epic pwnage these days chains together a string of vulnerabilities like this that aren't earth shattering on their own.

The usual clueless submission... (3, Interesting)

Anonymous Coward | about 9 months ago | (#45897747)

When was the last time you installed a "specially crafted" bdf font from anywhere?

There are *much* worse actual security problems than this one, which in practice, wasn't much of a problem in its day several decades ago, and isn't a problem now...

What's good is that the tools keep improving, and exposing problems...

I sure wish Slashdot's editors would actually apply their brains to submissions, rather than cluttering up slashdot with things that aren't important; there will be security reports that actually matter for people to pay attention to....

Re:The usual clueless submission... (4, Interesting)

NoNonAlphaCharsHere (2201864) | about 9 months ago | (#45897811)

Granted, there aren't a lot of people going to scurry off and "carefully craft" a font in an obsolete format for a new 0-day 'sploit. Actually, it's the "23-years old" and "discovered by a (new) automated test" parts that are interesting. Possibly even slashworthy.

Re:The usual clueless submission... (1)

Anonymous Coward | about 9 months ago | (#45898081)

The auto scanner bit is what I find interesting.

I have used many tools like this. I try to use as many as I can in my projects. It is amazing the number of bugs they find but people dismiss them as 'not a problem'. It took me 2 months to show to fellow co-workers that yes sscanf and sprintf can cause issues. Watch your % operators and make sure you are passing in the type you say you are. Some tools catch this fairly common error, others dont. Overflow and underflow is extremely easy with these two commonly used functions.

Trivial example
uint16_t x = 0;
uint64_t y = 0;
char abc = "123456";

sscanf(abc, "%l", &x);

Depending on your packing and your CRT that may cause an overflow into y;

Re:The usual clueless submission... (1)

tibit (1762298) | about 9 months ago | (#45898283)

I'd hope that modern compilers should catch that. gcc would have, for quite a while now. Maybe a decade?

Re:The usual clueless submission... (0)

Anonymous Coward | about 9 months ago | (#45897855)

When was the last time you installed a "specially crafted" bdf font from anywhere?

When was the last time you manually inspected a font to confirm that it fit all standards properly?

Re:The usual clueless submission... (1)

grnbrg (140964) | about 9 months ago | (#45897865)

When was the last time you installed a "specially crafted" bdf font from anywhere?

You don't have to. Anyone with a writeable ${HOME}/.fonts can.

This could be really big.

Re:The usual clueless submission... (5, Informative)

peppepz (1311345) | about 9 months ago | (#45898029)

Those fonts are read by fontconfig and freetype, while the bug is in the server-side font support, the one where you must run mkfontdir and possibly edit Xorg.conf to install new fonts. I don't think any distribution allows non-root users to do that.

Re:The usual clueless submission... (0)

Anonymous Coward | about 9 months ago | (#45897947)

Several decades? Dude, X11 isn't even 30 years old yet. Please watch the hyperbole.

Re:The usual clueless submission... (1)

Moskit (32486) | about 9 months ago | (#45898069)

> When was the last time you installed a "specially crafted" bdf font from anywhere?

I got a very nice BDF font recently from a guy who said he can't say where he works or doesn't work. It installed very nicely, and it is signed "specially crafted" indeed! Font file also has a "Made by ANToN of eSsAy" attribution. Nice handle!

Re:The usual clueless submission... (0)

Anonymous Coward | about 9 months ago | (#45898075)

When was the last time you installed a "specially crafted" bdf font from anywhere?

Not related to X11, but more & more websites are using the technique of crafting a custom font containing icons & symbols.

It's a bad idea - there have been many security issues caused by font parsers with invalid font files.

Accordingly, many people block downloaded fonts in their web browser, which makes the website look like crap.

ah well (0)

Anonymous Coward | about 9 months ago | (#45897785)

plenty of other vulnerabilities wide open :-)

Dangerous function (4, Informative)

jones_supa (887896) | about 9 months ago | (#45897793)

There's a scanf used when loading BDF fonts that can overflow using a carefully crafted font. Watch out for those obsolete early-90s bitmap fonts.

And watch out for scanf(). There's a reason Microsoft brought scanf_s() and others [microsoft.com] , which the official C11 standard adopted later too.

Perhaps it's just that I'm ignorant... (1)

Red_Chaos1 (95148) | about 9 months ago | (#45897823)

...of the specifics, but can someone tell me why it's even possible for something like a fucking font to cause a security issue? I'm not a coder, it's not something I can wrap my head around. I can sometimes get the gist of what a bit of code is doing when I look at it, but that's beside the point. It just seems to me so many things that should not be able to pose a security risk somehow get manipulated into being such risks, and it just blows my mind how it's even possible.

Re:Perhaps it's just that I'm ignorant... (1)

Anonymous Coward | about 9 months ago | (#45897913)

A specific font has special characteristics and might not even be a font, it could be just a file. The font processor processes the font file. A piece of code in the file results in a buffer overflow. Then suddenly code in the font is executed as a program and takes over.

Re:Perhaps it's just that I'm ignorant... (1)

mlts (1038732) | about 9 months ago | (#45897921)

In 1991, buffer overflows were just becoming to be an issue when it came to security. Back then, a lot of X servers came with no security, so any client could attach to the screen (no xhost or MIT magic cookie authentication.) Back then, the goal was to get functionality working in the first place. If you wanted a word processor, you had vi in an xterm, or fire up Xemacs. The only word processor would have probably been a variant of Wordperfect or possibly FrameMaker, and those were mainly living on the NeXT platform.

The X11 font bug is obscure enough to not be something that an attacker would be able to easily use. It is still a hole, but it has limited use, because to use it, one would have to have access as a user (unrestricted by policies like AppArmor or SELinux), and access to the X server's font path. This is about as hard as trying to place a ~user/ls in hopes that root runs something in the current directory over /bin/ls.

Re:Perhaps it's just that I'm ignorant... (1)

SirGarlon (845873) | about 9 months ago | (#45897923)

The short answer is that carelessly written code anywhere in the system can create a vulnerability. A font needs to be loaded into memory, and in this case the code that loads it makes it possible to stick portions of the font into a part of memory where it doesn't belong. So if the "font" is actually a set of data constructed by the attacker, it can include an executable program that runs when the font is loaded.

Back in 1991, the idea that someone would ever want to do this did not enter the imagination of a typical programmer.

Re:Perhaps it's just that I'm ignorant... (1)

ledow (319597) | about 9 months ago | (#45897929)

You allocate 100 bytes on the stack for a string.

The file you are reading a string from contains a string with more than 100 bytes of text before it's closing "NULL" (\0) character. The program reads in the 100 bytes and then, because the programmer didn't tell it to check or to stop (in this instance), it keeps going.

This puts whatever is in the file into whatever is NEXT TO the place you were storing the string. Often this is harmless data that happens to be near the string but, because of the nature of C and just programming in general, if you don't have appropriate protections, it COULD write over "the stack" (which happens to contains the memory addresses of where the code has to go next). As such, with lots of clever manipulation, an absence of checks and an absence of various security technologies, loading anything even as harmless as a text file, or font, or anything in a packet from the net could result in abitrary code execution as the user.

In this case, the user is root.
In this case, the overflow occurs but it's not yet been demonstrated that you can do anything dangerous with it (i.e. execute code).
In this case, protections like DEP and stack-checking actually block the attack and just make the program crash.

In ALL cases, if the programmer is awake and just checks ALL input that could come from an untrusted source, the question is moot.

Re:Perhaps it's just that I'm ignorant... (2)

TheLink (130905) | about 9 months ago | (#45898319)

And I've long seen that as a stupid design- mixing addresses and data in the same stack. You don't have to do that.

It's funny how Intel/AMD make CPUs with billions of transistors and yet we are still mixing data and program addresses on the same stack.

If you have separate stacks for parameters/data and return addresses, the attacker could clobber other data with data, but the program would still be running its intended code instead of arbitrary code of the attacker's choice - so it's more likely to throw errors or crash rather than get trivially pwned.

Keeping separate stacks might even help with CPU performance - when you know that one stack always contains return addresses it could be easier to do optimization tricks - prefetching, cache prioritizing etc.

Of course you will still be able to exploit certain programs by overflowing and overwriting other parameters - for example a program ends up seeing "OK" in a parameter instead of "NO" and so it does something differently. But hackers won't be able the other common stuff they do nowadays.

Re:Perhaps it's just that I'm ignorant... (0)

Anonymous Coward | about 9 months ago | (#45898481)

If you have separate stacks for parameters/data and return addresses, the attacker could clobber other data with data, but the program would still be running its intended code

You're funny:

struct show_me_the_money {
        char string_read_from_user_input[8];
        uint64_t (*money_func)(int show_me);
};

Remind me again which stack that struct goes on in your world? Seems to me that if I overflowed "string_read_from_user_input" I could easily overwrite the "money_func" function pointer to execute code at whatever address I liked.

The Wikipedia articles on "Harvard architecture" and "von Neumann architecture" will shed some light on the topic.

Re:Perhaps it's just that I'm ignorant... (1)

SuricouRaven (1897204) | about 9 months ago | (#45897939)

In a letter: C.

It's a language that works very close to the metal. That allows programers to squeeze the most out of the hardware - which matters now, and mattered a lot more 23 years ago. It's fast, it's lean, it'll let you run a fast-paced 3D(ish) FPS like Doom on a 486* with fifty monsters lobbing fireballs at the player. The down-side to this is that it's very easy for a programmer to screw up - you need to be aware of exactly how everything fits together in memory and always be thinking about exceptions and failure scenarios, otherwise this happens.

The exact problem is a buffer overflow: The font loading code allocates n bytes for some information, on the assumption that any sane and standards-compliant font will have at most n bytes there. A maliciously crafted font can have more than that n - and the code, upon reaching that limit, just carries on reading. The extra ends up somewhere, likely in a section of memory that was supposed to contain executable code, resulting in a code execution vulnerability.

A good part of the history of programming languages involves trying to find ways to restrict the capabilities of a language just enough to stop a programmer from making a mistake of that nature, but without restricting them so much that capabilities or performance suffer.

*I understand it could run on a 386, but that was pushing things a bit so you'd have to run it with reduced viewing size.

Re:Perhaps it's just that I'm ignorant... (1)

tibit (1762298) | about 9 months ago | (#45898347)

I don't think it's the problem with the language proper, just with the hopeless standard C library. Nobody is forced to use it naked, though. Either roll your own wrapper, or use something already made like Dave Hanson's code from C Interfaces and Implementations [google.com] .

Re:Perhaps it's just that I'm ignorant... (1)

jones_supa (887896) | about 9 months ago | (#45897943)

Any time you load some file format there is a risk of unexpected behavior happening due to buffer overflows. I guess that it's ultimately the von Neumann architecture computer that we can blame (mixing code and data on adjacent memory areas). That, and using unsafe C functions...

Even still, we should be able to do better. I agree that it's extremely cringe-worthy that a simple font can compromise the security of the system.

Re:Perhaps it's just that I'm ignorant... (0)

Anonymous Coward | about 9 months ago | (#45897951)

Reading strings from files in C is Hard (tm).

Re:Perhaps it's just that I'm ignorant... (1)

wildstoo (835450) | about 9 months ago | (#45897973)

Buffer overflow. [wikipedia.org]

Re:Perhaps it's just that I'm ignorant... (1)

Alioth (221270) | about 9 months ago | (#45897997)

That's alright - it won't be easy to understand if you're not a coder. In fact many coders won't understand it - unless you've done quite a lot of system level C code or possibly assembly language, many categories of these exploits will look a bit like black magic.

But in short, many categories of what should be pure data being used to exploit a security hole are things like buffer overflow exploits. A system level program written in C allocates some memory for a purpose, and due to a bad or missing length check, someone can put more data in there that fits. As the data runs off the end of this allocated space, it can end up overwriting something else. Consider a small buffer that's allocated on the stack. The stack also contains where in memory the program should return to after the subroutine it's running has ended. If you find that the code that fills this buffer has a bad or no length check, you can put data larger than the buffer in here and overwrite the routine's return address and make this return address be somewhere in your buffer (and contain more executable code). When the routine finishes, it gets the return address you put there instead of what should be there and your exploit code gets executed instead.

There's many defences against this at the system level these days (such as non-executable stacks, address space randomization etc) but ways have been found to get around some of these defences.

Re:Perhaps it's just that I'm ignorant... (1)

hawkinspeter (831501) | about 9 months ago | (#45898027)

Imagine, if you will, a car that has all the latest security features conceivable (biometrics up to and including your eyeballs). Also, imagine that there is a flaw with the radio aerial that enable someone to easily unscrew it and gain access to the engine compartment. By getting to the engine compartment, you can then exploit an electrical flaw to start the car and open the doors.

Now, why would it be even possible for an aerial flaw to allow your car to be stolen?

Re:Perhaps it's just that I'm ignorant... (1)

EmperorArthur (1113223) | about 9 months ago | (#45898095)

Quick guide to binary files. Mostly from my and others work on game saves.
Almost all of them store the size of an array right before the data. This is even true for things like null terminated strings. What gets fun is when you have an array of structs, which then holds an array. Most of those are read in using standard for loops, but an off by one error is still possible. Another (admittedly stupid) possibility is using a string read function that looks for the '\0' character while working with a fixed sized array instead of a true string object. Actually it's really easy for a malformed binary file to have a program attempting to read in gigabytes of data, or for a program that's not perfect to interpret some random number as an array size.

About font files:
Remember that font files tend to be ridiculously complicated. The new ones at least actually run code in a special virtual machine. Given everything that I've said about binary files an just how many Java/Flash/Javascript VM flaws we've seen it's not really surprising.

About X:
Hell, X11 is so complicated I wouldn't be surprised if an arbitrary function could load random fonts via a function call that no toolkit ever uses. At that point you're talking about a normal function with any of the normal error cases.

Pick your poison. There are many possibilities for errors.

The amazing thing is that cppcheck caught it. That means it had to be some static problem with the code.

cppcheck says this code is fine. Try to see why I disagree:

char f(int i,char * data)
{
        char array[6];
        array[i] = data[i];
        return array[0];
}

Re:Perhaps it's just that I'm ignorant... (1)

bluefoxlucid (723572) | about 9 months ago | (#45898145)

In generic technical terms...

Program flow is controlled by instrumentation data on what is called the "stack". The stack grows up or down; up-growing stack attacks are somewhat more esoteric, but very doable. Down-growing stacks are readily-understood, which has lead to many people blaming the direction of stack growth on x86 for its vulnerability to these attacks (they're wrong). We'll use down-growing stacks for our explanation here.

Each function sets up, from right to left (high address to low), return address, stack frame pointer, stored registers, and then local function variables. Local variables, as an implementation detail, are stored on the stack. Array variables are stored as a range, so if you allocate an integer of 4 bytes and a character array of 5 bytes may look like [CCCCC][IIII][SFP.][RETP]. Remember, the integer is allocated first; the character array allocated second. In reality, %esp just has the total aligned or unaligned (it doesn't matter from a compatibility standpoint, but it's specified in the binary standard) size of the stack variables subtracted from it. alloca() does the same thing, because malloc() is expensive (takes too much CPU time) and requires later free()ing the RAM while alloca(n) just subtracts n from %esp.

If a program loads data into a pre-allocated buffer of, say, 75 bytes, or if it calls alloca() to allocate a stack-local temporary buffer of 75 bytes, you can overwrite other stuff by writing more than 75 bytes. Above, if you wrote 17 bytes into the 5 byte character array, you would overwrite SFP and RETP. So if a program assumes an input field is under 75 bytes, or if it reads a numeric value from input and allocates that much, and then reads more than that, it can overwrite control data. This may happen if, for example, the program allocates a 75 byte buffer and then accepts that a data file says "FIELD X IS 255 BYTES LONG" and copies 255 bytes into it, or if it accepts "FIELD X IS 10 BYTES LONG" and allocates 10 bytes, then copies an ASCIIZ string (a bunch of bytes terminated by a 0 byte--the length is everything up to the 0).

In any such case, the overflow can spill into RETP. If you specially craft it to align a repeating set of values containing an address on the stack somewhat above the RETP, then dump in a bunch of AAAAAAAAAAAAAAA characters (inc %eax on x86, essentially nothing), then dump in a piece of program code, the function will return to the program code you just wrote into the stack. More directly, it will probably land sloppily into your NOP slide, increment an unimportant counter repeatedly, and then begin running your code.

So there you have it. A program copies a big piece of data into a little place next to instrumentation data, overwrites instrumentation data, and the program does unexpected things when the CPU tries to use that instrumentation data to direct program flow. If you're very careful about it, you can write specific instrumentation data in and add code to the program, and the program will execute your code because it's directed to return to it instead of to the previous call point.

Re:Perhaps it's just that I'm ignorant... (0)

Anonymous Coward | about 9 months ago | (#45898183)

The code to load the font will read the file as input. If you aren't careful with how you handle copying that into memory, weird things can happen. The actual executable code will be copied into memory right along with any variables you might have. Of course, pointers aren't exactly laid out as you might expect but that's beyond the scope of this explanation. Consider this:

[code goes here]
[various data; declared variables]
[array reserved for font file content]
[more code to process file]

Pretend that the file you are using contains some nasty code to do terrible things, such as give your computer syphilis. It is also long enough that when it is copied into memory, the very end of it spills into the "more code to process file" section. If you were to pop a JMP (tell the processor to "jump" and start executing code elsewhere) in there, you can now make the target software (X11 in this case) run that nasty code as root!

Re:Perhaps it's just that I'm ignorant... (1)

Derek Pomery (2028) | about 9 months ago | (#45898203)

You might also find this article interesting.
http://hackademix.net/2010/03/24/why-noscript-blocks-web-fonts/ [hackademix.net]

Personally, I find stuff like web fonts a bit more worrying since the content is served remotely, unlike installing this font, which you'd need root to do in the first place.

Re:Perhaps it's just that I'm ignorant... (1)

larry bagina (561269) | about 9 months ago | (#45898229)

here [github.com] is the code in question.

Re:Perhaps it's just that I'm ignorant... (1)

Kjella (173770) | about 9 months ago | (#45898233)

Well, the first thing you should understand is that "code" and "data" are entirely human distinctions, for a computer they're all zeros and ones. Computers have an instruction pointer which points to the memory address of the next instruction it's going to perform. If an attacker can replace the contents of that memory location, it ceases control of the system. Let's take a very basic example:

Program:
1. Load file into memory from $base to $base + $size
2. Read $offset from file
3. Read $value from file
4. Write $value to position $offset in the file.

That's what the code think it does, at least. But what if there's is no bounds checking and $base + $offset > $base + $size? Now you're writing outside the file to some other place in memory, like for example where the instruction pointer is. You trick the software into writing your data to a memory location it shouldn't be and the data gets executed as machine code. Of course this is absolutely brain dead code that will write anything to anywhere in memory and I haven't discussed any of the countermeasures that make this difficult, but that's the gist of it.

Re:Perhaps it's just that I'm ignorant... (1)

drinkypoo (153816) | about 9 months ago | (#45898303)

Well, the first thing you should understand is that "code" and "data" are entirely human distinctions, for a computer they're all zeros and ones.

Some computers do understand such a distinction at the hardware level. They are slightly more hassle, so we mostly don't use that kind of functionality. That is looking like a mistake.

Yay for free software! (0, Troll)

Anonymous Coward | about 9 months ago | (#45897859)

If this was closed source, this bug would probably still be undiscovered.

Qubes OS unlikely to be affected (1)

Burz (138833) | about 9 months ago | (#45897889)

It was designed assuming X11 (and Linux itself) had big security holes to begin with. [qubes-os.org]

In fact, after acclimating to the Qubes desktop architecture the whole monolithic kernel + X server arrangement looks like a raft full of holes waiting to exploited. Both the X11 layer *and* the Linux kernel need to be demoted to providing features only, not relied upon for overall system security.

Re:Qubes OS unlikely to be affected (1)

Junta (36770) | about 9 months ago | (#45898317)

Basically Qubes OS is as likely to be affected as a modern linux distribution. Xorg does not run with special privilege and thus the scope of the attack is things for said user.

While that means the underlying integrity of the system and other users is intact, it does little to comfort the vast majority of desktop users, as xkcd succinctly expresses: http://xkcd.com/1200/ [xkcd.com]

Re:Qubes OS unlikely to be affected (2)

Burz (138833) | about 9 months ago | (#45898513)

Incorrect. An exploited Qubes X11 has control over only the apps and data assigned to the exploited Xen domain; it would remain blocked from any baremetal administrative functions.

An exploited baremetal Linux/X11 has control over user I/O for everything done by the exploited user, so they are SOL as soon as they try to perform a system-wide admin function.

Keeping sensitive data under different user accounts would provide virtually no protection for threat models that apply to typical desktops.

Let's see how the "dead" NetBSD handles this... (1)

fisted (2295862) | about 9 months ago | (#45897957)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

                NetBSD Security Advisory 2014-001

Topic: Stack buffer overflow in libXfont

Version: NetBSD-current: source prior to Tue 7th, 2014
                NetBSD 6.1: affected
                NetBSD 6.0 - 6.0.2: affected
                NetBSD 5.1 - 5.1.2: affected
                NetBSD 5.2: affected

Severity: privilege escalation

Fixed: NetBSD-current: Tue 7th, 2014
                NetBSD-6-0 branch: Tue 7th, 2014
                NetBSD-6-1 branch: Tue 7th, 2014
                NetBSD-6 branch: Tue 7th, 2014
                NetBSD-5-2 branch: Tue 7th, 2014
                NetBSD-5-1 branch: Tue 7th, 2014
                NetBSD-5 branch: Tue 7th, 2014

Teeny versions released later than the fix date will contain the fix.

Please note that NetBSD releases prior to 5.1 are no longer supported.
It is recommended that all users upgrade to a supported release.

Abstract

A stack buffer overflow in parsing of BDF font files in libXfont was
found that can easily be used to crash X programs using libXfont,
and likely could be exploited to run code with the privileges of
the X program (most nostably, the X server, commonly running as root).

This vulnerability has been assigned CVE-2013-6462

Technical Details

- From the X.org advisory:

Scanning of the libXfont sources with the cppcheck static analyzer
included a report of:

      [lib/libXfont/src/bitmap/bdfread.c:341]: (warning)
              scanf without field width limits can crash with huge input data.

Evaluation of this report by X.Org developers concluded that a BDF font
file containing a longer than expected string could overflow the buffer
on the stack. Testing in X servers built with Stack Protector resulted
in an immediate crash when reading a user-provided specially crafted font.

As libXfont is used to read user-specified font files in all X servers
distributed by X.Org, including the Xorg server which is often run with
root privileges or as setuid-root in order to access hardware, this bug
may lead to an unprivileged user acquiring root privileges in some systems.

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

Solutions and Workarounds

Workaround: restrict access to the X server.

Solutions: a fix is included in the following versions:

xorg: xsrc/external/mit/libXfont/dist/src/bitmap/bdfread.c
HEAD 1.3
netbsd-6 1.1.1.2.2.1
netbsd-6-1 1.1.1.2.6.1
netbsd-6-0 1.1.1.2.4.1
netbsd-5 1.1.1.1.2.2
netbsd-5-2 1.1.1.1.2.1.4.1
netbsd-5-1 1.1.1.1.2.1.2.1

xfree: xsrc/xfree/xc/lib/font/bitmap/bdfread.c
HEAD 1.4
netbsd-6 1.2.8.1
netbsd-6-1 1.2.14.1
netbsd-6-0 1.2.10.1
netbsd-5 1.2.2.1
netbsd-5-2 1.2.12.1
netbsd-5-1 1.2.6.1

To obtain fixed binaries, fetch the appropriate xbase.tgz from a daily
build later than the fix dates, i.e.
http://nyftp.netbsd.org/pub/NetBSD-daily/ [netbsd.org] ///binary/sets/xbase.tgz
with a date 20140108* or larger, and your release version and architecture,
and then extract the libXfont shared library files:

for X.org environments, netbsd-6* and HEAD:
cd / && tar xzpf /path/to/xbase.tgz ./usr/X11R7/lib/libXfont.so \ ./usr/X11R7/lib/libXfont.so.3 \ ./usr/X11R7/lib/libXfont.so.3.0

for X.org environments and netbsd-5*:
cd / && tar xzpf /path/to/xbase.tgz ./usr/X11R7/lib/libXfont.so \ ./usr/X11R7/lib/libXfont.so.2 \ ./usr/X11R7/lib/libXfont.so.2.0

and for xfree environments:
cd / && tar xzpf /path/to/xbase.tgz ./usr/X11R6/lib/libXfont.so \ ./usr/X11R6/lib/libXfont.so.1 \ ./usr/X11R6/lib/libXfont.so.1.5

To build from source, update bdfread.c to the appropriate version and then
"./build.sh -x" from the top of the src tree.

Thanks To

X.Org thanks the authors of the cppcheck tool for making their static
analyzer available as an open source project we can all benefit from.
http://cppcheck.sourceforge.net/ [sourceforge.net]

NetBSD would like to thank X.org for looking for and fixing this
vulnerability.

Revision History

        2014-01-07 Initial release

More Information

Advisories may be updated as new information becomes available.
The most recent version of this advisory (PGP signed) can be found at
    http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2014-001.txt.asc [netbsd.org]

Information about NetBSD and NetBSD security can be found at
http://www.netbsd.org/ [netbsd.org] and http://www.netbsd.org/Security/ [netbsd.org] .

Copyright 2014, The NetBSD Foundation, Inc. All Rights Reserved.
Redistribution permitted only in full, unmodified form.

$NetBSD: NetBSD-SA2014-001.txt,v 1.2 2014/01/07 21:04:33 tonnerre Exp $

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (NetBSD)

iQIc[dammit, slashdot junk filter]Hkf
=wseV
-----END PGP SIGNATURE-----

This is not a story (0)

Anonymous Coward | about 9 months ago | (#45898003)

Unix based file ownership and X not running as root despite somehow a font(?) can take over a UI (kek) this is not a story but it is amusing. If anything this submission is scareware. If I was running at a default administrator level on a Microsoft operating system Windows environment I would be very afraid. But I'm not.

Re:This is not a story (1)

Anonymous Coward | about 9 months ago | (#45898279)

Unbelievable how many idiots post here...

Affects Win7 too, in a different but similar way? (0)

Anonymous Coward | about 9 months ago | (#45898055)

I know Win7 is a different codebase, but just yesterday on my work Win7 machine I started getting an error about installing fonts in Adobe Reader when trying to start Access. The error was about installing a font I've never heard of. Also, not long before that error occurred, one column in one query returned the results in a chinese character set.

Re:Affects Win7 too, in a different but similar wa (0)

Anonymous Coward | about 9 months ago | (#45898165)

Interesting...there could be a bug there somewhere.

Go ahead, just TRY a buffer overflow on my VAX (4, Funny)

thomasdz (178114) | about 9 months ago | (#45898077)

I'm running OpenBSD on my VAX. Go ahead. Try to exploit a buffer overflow on my home VAX cluster. If you can, then you deserve a prize because you've learned VAX machine code.

Re:Go ahead, just TRY a buffer overflow on my VAX (3, Funny)

Burz (138833) | about 9 months ago | (#45898345)

I'm tempted but the carbon footprint of the resulting 0wnage would probably be too great.

Isn't the XServer what runs on the user's side? (0)

Anonymous Coward | about 9 months ago | (#45898089)

I am pretty sure the Xserver which runs on the user's end and accepts connections from X clients like like xterm and gnome.

Or has the terminology changed?

Re:Isn't the XServer what runs on the user's side? (1)

Burz (138833) | about 9 months ago | (#45898387)

Its how the user communicates with and controls the system, so in a sense it doesn't matter if X is 'unprivileged'.

Discovered... (1)

gmuslera (3436) | about 9 months ago | (#45898461)

... by the developers. That a bug or vulnerability is found and announced in certain moment, be in closed or open source programs, don't ensure that the bad guys (working for the NSA or other places) haven't found and been exploiting it for some time already. That the bug can be found in automated ways (in this case was static source analysis, but could be checking for undocumented open ports or sql injection [owasp.org] ) makes almost certain that it could had been exploited before.

Exploitable UIs (1)

Danzigism (881294) | about 9 months ago | (#45898577)

I find this interesting since most of us gave Microsoft flack for so many years because of their terrible vulnerabilities. Turns out that nearly 90% of all Windows updates are for patching security issues with the UI. That is why Microsoft is convincing admins to use Server 2012 with just Server Core and PowerShell simply because it makes the whole system more secure. Who needs more than a console anyway? If you ask me you can get plenty of work done with vim, lynx, and entertain yourself with 0verkill. ;-)
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?