23-Year-Old X11 Server Security Vulnerability Discovered

← Back to Stories (view on slashdot.org)

23-Year-Old X11 Server Security Vulnerability Discovered

Posted by Unknown on Wednesday January 8, 2014 @03:11AM from the stack-smashing-for-fun-and-profit dept.

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.

213 comments

Min score:

Reason:

Sort:

Many eyes... by Anonymous Coward · 2014-01-08 03:17 · Score: 5, Insightful

...looking elsewhere.
1. Re:Many eyes... by i+kan+reed · 2014-01-08 03:18 · Score: 2, Insightful
  
  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.
2. Re:Many eyes... by hummassa · 2014-01-08 03:24 · Score: 1
  
  s/open source/no/ TIFIFY
  
  --
  It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
3. Re:Many eyes... by i+kan+reed · 2014-01-08 03:27 · Score: 2
  
  "no project don't actually hit it"
  I think I've found a bug in your perlscript.
4. Re:Many eyes... by grub · 2014-01-08 03:28 · Score: 4, Insightful
  
  "Many eyes" is bogus, "the right eyes" is more appropriate.
  
  --
  Trolling is a art,
5. Re:Many eyes... by Bacon+Bits · 2014-01-08 03:30 · Score: 5, Funny
  
  With enough Perl, all eyes are bleeding.
  
  --
  The road to tyranny has always been paved with claims of necessity.
6. Re:Many eyes... by NoNonAlphaCharsHere · 2014-01-08 03:36 · Score: 4, Funny
  
  With enough Perl, all eyes are bleeding.
  
  Let's see if that's true:
  
  print "$#_ [@_]\n\n";
  
  GAAAAAAAHHHHH!!!!!
  OK, point taken.
7. Re:Many eyes... by smash · 2014-01-08 03:41 · Score: 0, Flamebait
  
  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.
  
  --
  I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
8. Re:Many eyes... by Anonymous Coward · 2014-01-08 03:48 · Score: 0
  
  "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.
9. Re:Many eyes... by i+kan+reed · 2014-01-08 03:48 · Score: 1
  
  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)
10. Re:Many eyes... by i+kan+reed · 2014-01-08 03:52 · Score: 1
  
  won't be able to tell you where the security bugs are.
  They're laying maggots in the poo that was flung at screen.
11. Re:Many eyes... by RoverDaddy · 2014-01-08 03:54 · Score: 0, Flamebait
  
  Sorry, posting to remove erroneous moderation. Me and my clumsy fingers. Consider yourself getting +1 Funny.
  
  --
  RETURN without GOSUB in line 1050
12. Re:Many eyes... by tibit · 2014-01-08 03:55 · Score: 1
  
  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...
  
  --
  A successful API design takes a mixture of software design and pedagogy.
13. Re:Many eyes... by hawkinspeter · 2014-01-08 03:57 · Score: 4, Insightful
  
  I'd recommend running the same tool (cppcheck) on the Windows source code before trying to be ironic.
  
  --
  You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
14. Re:Many eyes... by Lumpy · 2014-01-08 04:00 · Score: 1
  
  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.
  
  --
  Do not look at laser with remaining good eye.
15. Re:Many eyes... by Anonymous Coward · 2014-01-08 04:05 · Score: 0
  
  No one claimed windows didn't have vulnerabilities. Only that the attitude that linux is super secure and impenetrable is invalid.
16. Re:Many eyes... by PPH · 2014-01-08 04:12 · Score: 1
  
  Windows source code
  Ow! My sides!
  
  --
  Have gnu, will travel.
17. Re:Many eyes... by hawkinspeter · 2014-01-08 04:18 · Score: 1
  
  Sounds like a straw man kind of argument. Who is claiming that linux is super secure and impenetrable?
  
  --
  You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
18. Re:Many eyes... by Anonymous Coward · 2014-01-08 04:29 · Score: 0
  
  le reddit
19. Re:Many eyes... by hairyfeet · 2014-01-08 04:31 · Score: 2
  
  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.
  
  --
  ACs don't waste your time replying, your posts are never seen by me.
20. Re:Many eyes... by MtHuurne · 2014-01-08 04:36 · Score: 1
  
  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).
  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.
21. Re:Many eyes... by Warbothong · 2014-01-08 04:38 · Score: 1
  
  "Many eyes" is bogus, "the right eyes" is more appropriate.
  In this case "the right eyes" are robotic.
22. Re:Many eyes... by hawkinspeter · 2014-01-08 04:40 · Score: 1
  
  You'd be better off posting there, then.
  
  --
  You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
23. Re:Many eyes... by garyebickford · 2014-01-08 04:51 · Score: 4, Informative
  
  Actually it was shown back in the late 1970s that it is essentially impossible for 'black box' testing to discover more than about 30% of the bugs in a sufficiently large code base. It's based on the NP-complete problem of following all possible variations of the branches using all possible combinations of input, both valid and invalid. It's fairly easy to build a one page program that can not effectively be completely tested. It was also shown that, given good programming practice, roughly 70% of the bugs are built into the design (before a line of code has been written). Then, finally, a significant number/percentage of bugs are of the sort where it's a judgement call whether it's a bug or a feature.
  Source: I used to run a Software Quality Assurance Workshop for my then-company, and did the research. A few programming practices have changed, and the repertoire of automated tools has greatly increased in both quantity and sophistication, but average program size and the list of asynchronous externalities has ballooned by two or three orders of magnitude, so there we are.
  
  --
  It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
24. Re:Many eyes... by Anonymous Coward · 2014-01-08 04:54 · Score: 0
  
  http://tech.slashdot.org/comments.pl?sid=4645733&cid=45898149
25. Re:Many eyes... by NotQuiteReal · 2014-01-08 04:57 · Score: 2
  
  "Good" test data is often an issue... in this case, I am sure your test suite includes some "carefully crafted fonts", right?
  
  --
  This issue is a bit more complicated than you think.
26. Re:Many eyes... by garyebickford · 2014-01-08 04:58 · Score: 1
  
  Having never been a significant C coder (I skipped that phase), I'll argue that by my observation the vast majority of problems would be eliminated if C programs were incapable of buffer overflows. This is less simple than it seems. It would require not only some language features, but library changes, and would slow things down (imperceptibly?).
  There is no reason an application developer should ever encounter a segfault in a modern language. Many of today's languages are essentially immune to this problem, except when there is an error ... wait for it ... in the underlying C implementation of the compiler or runtime environment! :D
  
  --
  It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
27. Re:Many eyes... by garyebickford · 2014-01-08 05:00 · Score: 2
  
  Is this still true? IANA windows person, but I was under the impression that the newer versions of the OS had more and better compartmentalism and enforcement of user space.
  
  --
  It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
28. Re:Many eyes... by ericloewe · 2014-01-08 05:05 · Score: 1
  
  It'd be interesting to compare the source for Linux and the NT kernel.
  Bureaucracy vs. a very irritable Finn.
29. Re:Many eyes... by i+kan+reed · 2014-01-08 05:09 · Score: 4, Insightful
  
  It should include bogus fonts with randomized data to test for crashes, data validation, and the like, yes.
30. Re:Many eyes... by ewibble · 2014-01-08 05:16 · Score: 2
  
  Many eyes does work, so much in that it helps a bit, same with static analysis it helps but not perfect and just because you have run your tool over your code does not mean you are safe.
  FLOSS give you the following:
  1. an independent programmer may have looked at it.
  2. nobody can pull the plug.
  3. If it doesn't do what you want you can add it. My favorite.
  4. When a bug does occur they don't generally try to hide the fact.
  FLOSS is no way a guarantee of adequate code, any idiot can write start a project, but from what I have see of closed source code, that is definitely no better.
  E.g. utility function to move a file:
  char buff[256];
  sprintf(buff, "mv %s %s", src, dst);
  system(buff);
  problems ,buffer overruns and moving the file "; rm -rf /" can be problematic. And its was not just a one off either.
  If you are looking for guarantees about code quality just because you are FLOSS you are going to be disappointed.
31. Re:Many eyes... by Obfuscant · 2014-01-08 05:24 · Score: 1
  
  It would require not only some language features, but library changes, and would slow things down (imperceptibly?).
  Having dealt with some fascinating FORTRAN code that ran perfectly under one compiler and failed with horrible segfaults under another, I can approve of languages that include bounds checking at execution time -- as long as it can be disabled when desired.
  The specific example is a bit of FORTRAN that was processing input parameters from a file, parsing lines of text for colon delimited parameter/value pairs. Ran fine under one compiler (gfortran, as I recall), but died every time when compiled with PGI. The programmer had ignored the case of COMMENTS in the text where no colon was found, and was trying to copy the parameter name from "start of string" through "colon-1" to another variable. No colon, the index is 0, so copying 1 through -1 is, well, a problem. One FORTRAN library caught the invalid parameter and silently ignored the operation, the other passed it on to memcpy directly.
  Now, in this case, there was no real speed penalty in checking the input parameters by the library, and it really was the programmer's fault for not checking the return from index. But as a general library function, it could be a serious speed penalty especially when a good programmer already includes a test, and certainly if this is in code that is already a bottleneck.
  
  There is no reason an application developer should ever encounter a segfault in a modern language.
  That I disagree with. A segfault is just another error message that shows that something is not being done properly. It would have saved me an ENORMOUS amount of time had the original programmer been forced to write proper code before distributing it to the world and I had to debug why it was failing. I mean, it was my mistake for assuming that someone could parse text properly, but that assumption was made because the code worked even when it was obvious it shouldn't. I mean, it doesn't fail using compiler X so it must be valid, let's look somewhere else for the error.
  What SHOULD be a feature of every compiler/runtime library is a switch that says "no runtime bounds checks, please". That would allow compiling code to run as fast as possible (as is required for modelers, e.g.) in production. But then another switch to say "check and report everything" for the initial test runs so that bugs can be found and eliminated more easily. The option of silently ignoring really stupid input parameters to a library call should go away. Crash and burn, or bitch and moan, ok, but "I'll ignore your stupidity so you never learn how to be a better programmer and can show the world how bad you are", no.
32. Re:Many eyes... by Anonymous Coward · 2014-01-08 05:26 · Score: 0
  
  With enough Perl, all eyes are bleeding.
  What has Perl got to do with X11?
33. Re:Many eyes... by Anonymous Coward · 2014-01-08 05:35 · Score: 0
  
  Range checking isn't insignificant in a performance hit.
34. Re:Many eyes... by Anonymous Coward · 2014-01-08 05:38 · Score: 0
  
  good one
35. Re:Many eyes... by Anonymous Coward · 2014-01-08 05:42 · Score: 0
  
  C is not that vulnerable. There are a few old "standard" functions you shouldn't use, that's all. You already have modern replacements that don't overflow. Instead of strcpy(), use strncpy() and so on.
  The programmer is the worse problem. Many programmers simply don't consider that someone might paste an entire website into a "last name" field, or that the "camera name" field in a jpeg might contain over a gigabyte...
36. Re:Many eyes... by Tough+Love · 2014-01-08 06:08 · Score: 1
  
  All you said is that sometimes we don't have enough eyes on the code. You failed to substatiate your thesis that "many eyes" is a myth. This particular bug was discovered precisely because we got some new eyes looking at the code, buffed up with a dose of technological superpower. The X11 project has traditionally been a rather small project with significant barriers to entry like cvs commit access owned jealously by a small club. It's somewhat better after being pried loose from Open Group's stultifying domination, but its still a small project relative to its importance. More eyeballs are always better.
  
  --
  When all you have is a hammer, every problem starts to look like a thumb.
37. Re:Many eyes... by Lumpy · 2014-01-08 06:30 · Score: 1
  
  Once you gain actual access the game is over. IF you have a Domain controller and have some real restrictions in place, then things get a bit harder for the attacker with a compromised login. But the added security only really comes from the PDC and the domain environment. Local security hive is still pretty easy (for an attacker) to circumvent when you have direct user access.
  
  --
  Do not look at laser with remaining good eye.
38. Re:Many eyes... by Anonymous Coward · 2014-01-08 06:32 · Score: 0
  
  The X11 developers are fully aware the codebase has a massive footprint written in old-school C, which means it's probably riddled with security holes. They don't have the will to rewrite the the thing due to all the other fundamental design problems, and that's why they're pushing Wayland.
39. Re:Many eyes... by Anonymous Coward · 2014-01-08 06:36 · Score: 0
  
  How many eyes are willing to look at X11 server code?
40. Re:Many eyes... by garyebickford · 2014-01-08 06:47 · Score: 1
  
  Long ago I worked in a Pascal dialect (for the Perq workstation) that included several systems programming extensions. One was that ability to grab a block of memory as raw data, then work within that block to create and manipulate named variables as usual with full protection by the compiler. I don't recall the other extensions.
  I still think that for the vast majority of the code in most applications, the performance impact of runtime checking is minimal. So it's feasible to isolate the very few components where this is not the case, squeeze them down to the absolute minimum size and complexity, so that those pieces can be thoroughly vetted and maybe even 'proved'.
  Running in 'strict' mode is something I do during the entire dev and test cycle, then *usually* turn down for release - sometimes it has been beneficial to run internal-use programs (cron jobs) in mostly-strict, verbose logging mode to assist in debugging two years later when nobody knows how it works any more.
  I'm thinking that a smart compiler or maybe a runtime profiler might be able to figure out where runtime bounds checks are appropriate and where they are not, to a great extent. So maybe the default would be checks, with an option to turn off for particular variables (at run time).
  A related question comes from the principal of web programming, "Be strict with output, lenient with input" - a web browser should be as correct as possible with everything it puts out, and try to figure out what it receives to do something sensible with it. I'm not sure this is still considered the 'right way', as it tended to encourage (or at least not discourage) a lot of bad things.
  
  --
  It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
41. Re:Many eyes... by Rhacman · 2014-01-08 07:17 · Score: 1
  
  C is a very low level programming language. If you ever look at the assembly listing for a C program you will generally find that each line of code maps to a relatively short sequence of assembly instructions. This virtue of C is what makes it so attractive for its original (and continued) use as a tool for writing operating systems, OS drivers, embedded systems, or anything where the developer needs or desires fine control of exactly what operations will be performed. Adding bounds checks lessens that control and for many applications where C is an appropriate language choice, would have a very real performance impact.
  
  That said, many C compilers, debuggers, and code analysis tools (such as cppcheck as mentioned in the summary) offer features to detect memory access violations (and other types of bugs) during development and testing but without adding permanent run-time checking to release builds.
  
  --
  Account -> Discussions -> Disable Sigs
42. Re:Many eyes... by fatphil · 2014-01-08 07:26 · Score: 1
  
  Ooooh, how about the guys behind SE-Linux ("SE" = "securty enhanced" or somesuch)?
  
  --
  Also FatPhil on SoylentNews, id 863
43. Re:Many eyes... by hawkinspeter · 2014-01-08 07:34 · Score: 1
  
  Surely they're the least likely to claim that as they're actually working to improve the security of linux. If it was already secure, then there wouldn't be much demand for enhanced security.
  
  --
  You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
44. Re:Many eyes... by operagost · 2014-01-08 08:03 · Score: 1
  
  Everyone on Slashdot?
  
  --
  
  Gamingmuseum.com: Give your 3D accelerator a rest.
45. Re:Many eyes... by hawkinspeter · 2014-01-08 08:06 · Score: 1
  
  Okay, who, except for Lumpy, is claiming that linux is super secure and impenetrable?
  
  --
  You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
46. Re:Many eyes... by hawkinspeter · 2014-01-08 08:09 · Score: 1
  
  ***puts hands up***
  You got me, it's a fair cop. I'll go quietly
  
  --
  You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
47. Re:Many eyes... by operagost · 2014-01-08 08:11 · Score: 2
  
  Your reference to a "PDC" and the conspicuous lack of a reference to Active Directory or the SAM (used on standalone servers) tells me your knowledge is a bit out of date... which would explain why your statement is incorrect. Privilege escalations are taken as seriously on Windows as on other modern operating systems. And the SAM has not been particularly vulnerable since encryption (NT 4.0), and the ability to remove LM hashes (present since NT 3.1, default in Vista and 2008) were added. We're not L0PHTcrackin' like it's 1999 anymore.
  
  --
  
  Gamingmuseum.com: Give your 3D accelerator a rest.
48. Re:Many eyes... by garyebickford · 2014-01-08 08:21 · Score: 2
  
  Yes. I've basically argued that C should not be used for application programming in general - device drivers, kernels, maybe some other high performance OS tasks, and the occasional small high performance functions in larger programs.
  I can further argue that the extent to which even those domains need to be in a low-level language like C at present is really a testament to the limitations of compilers - IMHO it is high time to apply AI and machine learning techniques to compiler design and code translation. Watson could do some interesting things with language processing and a good knowledge base. In some cases the top-level symbolic program design could go right to custom silicon.
  It's significant that the 'infamous' APL, a very highly abstracted mostly-functional interpreted language that looks at everything pretty much as arrays, was often as faster at doing things like matrix inversions faster than most compiled implementations in other languages. This is because the interpreter did almost no work, and the underlying code for a given function could be tuned to the very restricted domain that it was operating in, in the assembly language. I believe there was even a microcoded APL interpreter, which would basically make an APL virtual machine.
  
  --
  It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
49. Re:Many eyes... by Anonymous Coward · 2014-01-08 08:41 · Score: 0
  
  This is less simple than it seems. It would require not only some language features, but library changes, and would slow things down
  Sure, but it still seems very simple. Just noone dares break with the herd.
  
  There is no reason an application developer should ever encounter a segfault in a modern language
  Doesn't matter really. You can prevent any and all segfaults, but the other way around is to make them non-fatal. If an isolated program segfaults, takes down no other processes, the kernel and other processes remain, all resources are cleaned up, etc. does anyone really care?
  That can arguably be a good thing too -- better the application developer knows their program is buggy, than some wrapper/handler mysteriously fixes it up, and they have no idea they have bugs because they are all mysteriously fixed behind their back and they don't bother reading logs or cranking up the log verbosity. They may notice a slight speed decrease if they are looking for speed, but that would be a side effect from researching that.
  
  Many of today's languages are essentially immune to this problem, except when there is an error ... wait for it ... in the underlying C implementation of the compiler or runtime environment! :D
  Makes you wonder why so many of "today's languages" are content and perfectly resigned to sitting atop ancient languages.
  I have no love for C but its (still) here. Why cant any one fix it, either within itself or outside of itself?
  A kernel and OS and standard library not written in C is too risky, too daring, too many drivers to write I guess.
  It is strange, C is too conservative to ever fix such a thing (or noone would ever bother, how are you going to get the world to move to it?) but the high level languages are pretty much the same, content to always be running atop of ancient run-times.
  C is a victim of its own success.
50. Re:Many eyes... by TangoMargarine · 2014-01-08 09:36 · Score: 1
  
  Randomized data may not account for cases where the font has to be invalid in a particular way to trip the overflow.
  
  --
  Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
51. Re:Many eyes... by TangoMargarine · 2014-01-08 09:44 · Score: 1
  
  "more secure" != "impenetrable"
  
  --
  Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
52. Re:Many eyes... by Anonymous Coward · 2014-01-08 10:41 · Score: 0
  
  .. looking for porn.
53. Re:Many eyes... by Anonymous Coward · 2014-01-08 11:30 · Score: 0
  
  I think that was supposed to be an NSA joke.
54. Re:Many eyes... by Anonymous Coward · 2014-01-08 12:08 · Score: 0
  
  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)
  No, testing is always woefully incomplete. By far the best way to find bugs is to design the system so that class of bugs are simply not possible or at least makes the bugs highly visible. There's way too many programmers who think testing can replace good design and as a result we have huge numbers of unnecessarily buggy systems out there. As just one example among many we have huge numbers of GUI's that were not properly designed and have lots of easily avoidable race conditions. Like if the user clicks something too fast. It's just ridiculous.
55. Re:Many eyes... by hairyfeet · 2014-01-08 13:49 · Score: 1
  
  Do I REALLY need to link to the wikipedia on the Mythical Man-Month? Really? Because that is EXACTLY what "many eyes" is, its Mythical Man-Month applied to code.
  
  --
  ACs don't waste your time replying, your posts are never seen by me.
56. Re:Many eyes... by smash · 2014-01-08 20:03 · Score: 1
  
  As opposed to, you know... using c# which has actual memory protection built into the language...
  
  --
  I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
57. Re:Many eyes... by smash · 2014-01-08 20:05 · Score: 1
  
  Thankyou, somebody on the internet understands the concept of sarcasm.
  
  --
  I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
58. Re:Many eyes... by hawkinspeter · 2014-01-08 21:08 · Score: 1
  
  Shame they don't use c# for all of Windows, then. Most of it is written in C for speed and low-level access.
  
  --
  You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
59. Re:Many eyes... by Barsteward · 2014-01-08 21:32 · Score: 1
  
  "Most of it is written in C for speed and low-level access." - do you mean remote access? :o)
  
  --
  "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
60. Re:Many eyes... by fatphil · 2014-01-08 22:35 · Score: 1
  
  Better to be understood by one AC than by nobody, I guess...
  
  --
  Also FatPhil on SoylentNews, id 863
61. Re:Many eyes... by smash · 2014-01-09 03:43 · Score: 1
  
  They're replacing various bits of it gradually. I suspect its a big reason why they're trying to kill win32, yet muppets seem to be intent on running bullshit insecure copies of Windows like XP from 2001.
  
  --
  I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
62. Re:Many eyes... by stoatwblr · 2014-01-09 07:51 · Score: 1
  
  All assuming that someone else spotted the bugs first.
63. Re:Many eyes... by smash · 2014-01-09 14:00 · Score: 1
  
  So basically you are saying that if you expend a minimal amount of effort to secure a Windows environment, you can secure it. Yet if you have to spend some time to secure Linux (which has had this vulnerability for longer than the OS has existed), that's OK.
  
  --
  I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
64. Re:Many eyes... by Tough+Love · 2014-01-10 15:12 · Score: 1
  
  Argument by analogy. Wow, you are slipping.
  
  --
  When all you have is a hammer, every problem starts to look like a thumb.
scary by uglyduckling · 2014-01-08 03:17 · Score: 1

Amazing how an automated tool can spot something like this after so many years.
1. Re:scary by Anonymous Coward · 2014-01-08 03:29 · Score: 3, Insightful
  
  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.
2. Re: scary by Anonymous Coward · 2014-01-08 03:39 · Score: 0, Informative
  
  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.
3. Re:scary by Bill,+Shooter+of+Bul · 2014-01-08 03:39 · Score: 2
  
  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
  
  --
  Well.. maybe. Or Maybe not. But Definitely not sort of.
4. Re:scary by Anonymous Coward · 2014-01-08 03:42 · Score: 0, Insightful
  
  Hasn't come up before? The Snowden docs suggest the NSA has been using this (and/or other X bugs) for years.
5. Re:scary by buchner.johannes · 2014-01-08 03:43 · Score: 5, Insightful
  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.
  --
  NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
6. Re:scary by hawkinspeter · 2014-01-08 03:54 · Score: 1
  
  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.
  
  --
  You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
7. Re:scary by PPH · 2014-01-08 04:09 · Score: 5, Insightful
  
  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.
  
  --
  Have gnu, will travel.
8. Re:scary by noh8rz10 · 2014-01-08 04:20 · Score: 1
  
  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.
9. Re: scary by edoules · 2014-01-08 04:53 · Score: 0
  
  This took three reads before I realized you were being silly. More coffee.
10. Re:scary by garyebickford · 2014-01-08 05:02 · Score: 1
  
  Also automated systems will find _different_ types of bugs than humans. Just like computer chess players use different strategies than human players. I anticipate that the next step will be automated systems for learning new automated bug-finding methods that humans may never have considered.
  
  --
  It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
11. Re:scary by Anonymous Coward · 2014-01-08 05:20 · Score: 0
  
  OpenBSD, at least, hacked rudimentary privilege separation into X11 years go. The bulk of the X11 server runs as an unprivileged user.
12. Re:scary by Anonymous Coward · 2014-01-08 05:27 · Score: 0
  
  Pedro Ribeiro reported the issue; he's not from the development team but if he was he would very likely be there because its open...
  Open is pretty much always better than Closed form a Security Standpoint.
13. Re:scary by Anonymous Coward · 2014-01-08 05:48 · Score: 0
  
  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.
  Only if his/her assignment was to review legacy code for bugs. Not if the coder was investigating to satisfy his/her own itch, as that would be grounds for reprimand and inappropriate use of time in closed-commercial settings.
14. Re:scary by Unordained · 2014-01-08 07:45 · Score: 1
  
  Amazing that when they run this kind of automated tool on a project of this importance and breadth, this is ... the only vulnerability it found?
  This doesn't invalidate "many eyes" at all (as some are claiming here) -- the fact that a bunch of reviewers didn't find this one bug is unfortunate, but if "many eyes" had really failed, I would have expected automation to find dozens or hundreds of bugs.
15. Re:scary by Anonymous Coward · 2014-01-08 09:05 · Score: 0
  
  I don't know what is the case with X11, but here is a small part of the bugs, which the Cppcheck development team has reported to various open source projects: http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Found_bugs
  Debian archive is also being checked by the Cppcheck ( http://lwn.net/Articles/420252/ ) , so a lot of open source projects get covered that way.
16. Re:scary by TangoMargarine · 2014-01-08 09:48 · Score: 1
  
  At least now it's getting fixed. I'd call that better than not knowing about it.
  
  --
  Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
17. Re:scary by Anonymous Coward · 2014-01-08 10:00 · Score: 0
  
  We all are the development team.
18. Re:scary by Anonymous Coward · 2014-01-08 11:59 · Score: 0
  
  especially when it took 23 years to find it.
19. Re:scary by Anonymous Coward · 2014-01-08 18:08 · Score: 0
  
  Open is pretty much always better than Closed form a Security Standpoint.
  In theory yes, in reality no. Not that the opposite is true but your assertion is false, just look at how bad X11 is and it's open.
20. Re:scary by Anonymous Coward · 2014-01-09 23:41 · Score: 0
  
  X doesn't need to run as root any more. There are other ways due to people like this guy.
Privilege escalation is to the server credential by tlambert · 2014-01-08 03:19 · Score: 0

Privilege escalation is to the server credential. Modern X11 is never run as root. This is sensationalism.
The usual clueless submission... by Anonymous Coward · 2014-01-08 03:20 · Score: 3, Interesting

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....
1. Re:The usual clueless submission... by NoNonAlphaCharsHere · 2014-01-08 03:26 · Score: 4, Interesting
  
  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.
2. Re:The usual clueless submission... by Anonymous Coward · 2014-01-08 03:31 · Score: 0
  
  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?
3. Re:The usual clueless submission... by grnbrg · 2014-01-08 03:33 · Score: 1
  
  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.
4. Re:The usual clueless submission... by Anonymous Coward · 2014-01-08 03:39 · Score: 0
  
  Several decades? Dude, X11 isn't even 30 years old yet. Please watch the hyperbole.
5. Re:The usual clueless submission... by peppepz · 2014-01-08 03:47 · Score: 5, Informative
  
  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.
6. Re:The usual clueless submission... by Moskit · 2014-01-08 03:51 · Score: 1
  
  > 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!
7. Re:The usual clueless submission... by Anonymous Coward · 2014-01-08 03:51 · Score: 0
  
  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.
8. Re:The usual clueless submission... by Anonymous Coward · 2014-01-08 03:52 · Score: 1
  
  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;
9. Re:The usual clueless submission... by tibit · 2014-01-08 04:12 · Score: 1
  
  I'd hope that modern compilers should catch that. gcc would have, for quite a while now. Maybe a decade?
  
  --
  A successful API design takes a mixture of software design and pedagogy.
10. Re:The usual clueless submission... by digsbo · 2014-01-08 05:00 · Score: 1
  
  I've loaded special bitmap fonts several times, because I'm nuts about the old 6x13 bitmap font the was the default on the old SGI Irix systems I used in the 90s (no preferable font exists at my current DPI, and I've even carried it into Visual Studio). Granted, it wasn't BDF, but there are some folks out there who make niche fonts available.
11. Re:The usual clueless submission... by wiredlogic · 2014-01-08 07:08 · Score: 1
  
  Last week I installed the custom BDF font contained in my HP 1670D logic analyzer which is needed to support a remote client display. There are people that still rely on the "obsolete" facilities of X11.
  
  --
  I am becoming gerund, destroyer of verbs.
12. Re:The usual clueless submission... by Anonymous Coward · 2014-01-08 07:49 · Score: 0
  
  would you same the same thing if it was instead a problem related to some component in windows?
  if it was some piece of software from microsoft, acquired or not, you'd have hundreds coming out of the woodwork decrying how shitty microsoft is and if they had opened their code up this wouldn't have been a problem
13. Re:The usual clueless submission... by TangoMargarine · 2014-01-08 10:04 · Score: 1
  
  'MANT NSA'?
  
  --
  Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
ah well by Anonymous Coward · 2014-01-08 03:23 · Score: 0

plenty of other vulnerabilities wide open :-)
Dangerous function by jones_supa · 2014-01-08 03:24 · Score: 4, Informative

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, which the official C11 standard adopted later too.
1. Re:Dangerous function by Viol8 · 2014-01-08 05:00 · Score: 2
  
  The scanf() suit of functions are pretty horrid regardless of security issues. They never do quite what you expect and have endless little quirks that frankly are just a PITA. 99% of the time its a lot easier to roll your own parsing code than get *scanf() kicking and screaming to do what you want , and with C++ you have streams anyway. Its a pity they weren't just put of their (our?) misery years ago and dumped from the C standard altogether.
2. Re:Dangerous function by Anonymous Coward · 2014-01-08 05:03 · Score: 0
  
  C++?
  More like C--
3. Re:Dangerous function by Anonymous Coward · 2014-01-08 12:35 · Score: 0
  
  roll your own
  write your own. What is with these stupid analogies? It's just confusing to other people and just makes it appear different from what it is. It's no different from the idiotic marketing gimps that use terms like "in the cloud".
4. Re:Dangerous function by Viol8 · 2014-01-08 21:24 · Score: 1
  
  Fair point - though rolling implies designing it as well as writing.
5. Re:Dangerous function by fatphil · 2014-01-08 22:23 · Score: 1
  
  That's not true at all - if you want to read a number, then sscanf is your *best* option, as it doesn't have in-band error reporting, the return value is in addition to the read value.
  
  --
  Also FatPhil on SoylentNews, id 863
Re:Privilege escalation is to the server credentia by i+kan+reed · 2014-01-08 03:24 · Score: 4, Insightful

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).
Perhaps it's just that I'm ignorant... by Red_Chaos1 · 2014-01-08 03:27 · Score: 1

...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.
1. Re:Perhaps it's just that I'm ignorant... by Anonymous Coward · 2014-01-08 03:36 · Score: 1
  
  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.
2. Re:Perhaps it's just that I'm ignorant... by mlts · 2014-01-08 03:38 · Score: 1
  
  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.
3. Re:Perhaps it's just that I'm ignorant... by SirGarlon · 2014-01-08 03:38 · Score: 1
  
  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.
  
  --
  [Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
4. Re:Perhaps it's just that I'm ignorant... by ledow · 2014-01-08 03:38 · Score: 1
  
  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.
5. Re:Perhaps it's just that I'm ignorant... by SuricouRaven · 2014-01-08 03:39 · Score: 1
  
  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.
6. Re:Perhaps it's just that I'm ignorant... by jones_supa · 2014-01-08 03:39 · Score: 1
  
  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.
7. Re:Perhaps it's just that I'm ignorant... by Anonymous Coward · 2014-01-08 03:39 · Score: 0
  
  Reading strings from files in C is Hard (tm).
8. Re:Perhaps it's just that I'm ignorant... by wildstoo · 2014-01-08 03:42 · Score: 1
  
  Buffer overflow.
9. Re:Perhaps it's just that I'm ignorant... by Alioth · 2014-01-08 03:44 · Score: 1
  
  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.
  
  --
  Oolite: Elite-like game. For Mac, Linux and Windows
10. Re:Perhaps it's just that I'm ignorant... by hawkinspeter · 2014-01-08 03:47 · Score: 1
  
  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?
  
  --
  You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
11. Re:Perhaps it's just that I'm ignorant... by EmperorArthur · 2014-01-08 03:54 · Score: 1
  
  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];
  }
  
  --
  So lets pretend that we've just completed writing this code, as opposed to having just completed sabotaging it -Altera
12. Re:Perhaps it's just that I'm ignorant... by bluefoxlucid · 2014-01-08 03:59 · Score: 1
  
  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.
  
  --
  Support my political activism on Patreon.
13. Re:Perhaps it's just that I'm ignorant... by Anonymous Coward · 2014-01-08 04:02 · Score: 0
  
  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!
14. Re:Perhaps it's just that I'm ignorant... by Derek+Pomery · 2014-01-08 04:05 · Score: 1
  
  You might also find this article interesting.
  http://hackademix.net/2010/03/24/why-noscript-blocks-web-fonts/
  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.
  
  --
  -- perl -e'print pack"H*","6e656d6f406d38792e6f7267"' /. ate my old sig. Bastards.
15. Re:Perhaps it's just that I'm ignorant... by larry+bagina · 2014-01-08 04:07 · Score: 1
  
  here is the code in question.
  
  --
  Do you even lift?
  These aren't the 'roids you're looking for.
16. Re:Perhaps it's just that I'm ignorant... by Kjella · 2014-01-08 04:08 · Score: 1
  
  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.
  
  --
  Live today, because you never know what tomorrow brings
17. Re:Perhaps it's just that I'm ignorant... by drinkypoo · 2014-01-08 04:14 · Score: 1
  
  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.
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
18. Re:Perhaps it's just that I'm ignorant... by TheLink · 2014-01-08 04:15 · Score: 2
  
  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.
  --
  
  Too many replies beneath your current threshold
19. Re:Perhaps it's just that I'm ignorant... by tibit · 2014-01-08 04:18 · Score: 1
  
  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.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
20. Re:Perhaps it's just that I'm ignorant... by Anonymous Coward · 2014-01-08 04:30 · Score: 0
  
  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.
21. Re:Perhaps it's just that I'm ignorant... by Anonymous Coward · 2014-01-08 04:44 · Score: 0
  
  And there are tons of such structs in the programs you write?
22. Re:Perhaps it's just that I'm ignorant... by Anonymous Coward · 2014-01-08 04:53 · Score: 0
  
  Intel and AMD have billions of transistors that they are seemingly running out of ideas to use (they tend to give us more and more cores and cache). Why can't they figure a way to use some of those transistors to work around such deficiencies in C and still have things run fast?
  
  And yes "executing code at whatever address the attacker likes" whenever something gets overflowed is a deficiency.
  
  In the bad old days there wasn't stuff like memory protection, and some people even liked it. But we've grown past that.
23. Re:Perhaps it's just that I'm ignorant... by Anonymous Coward · 2014-01-08 05:01 · Score: 0
  
  You don't need root to install fonts.
24. Re:Perhaps it's just that I'm ignorant... by DMUTPeregrine · 2014-01-08 05:04 · Score: 1
  
  That's only true for Von-Neumann architecture, but not for a (pure) Harvard architecture.
  
  Of course, the Harvard architecture has some issues, like not being able to store code on the same device as data, which make it impractical for normal use. And mitigating those issues recreates the possibility of the security holes that Von-Neumann machines have.
  
  --
  Not a sentence!
25. Re:Perhaps it's just that I'm ignorant... by segin · 2014-01-08 05:11 · Score: 1
  
  You can craft your data (it doesn't have to be a font, well, in this specific case it does, but the technique in general doesn't care what format) so that the function loading data will keep loading data past the end of the chunk of memory it allocated for that data. And if you keep on going, you start overwriting other bits of data, such as the address where code execution should resume once the loader function finishes. Now you just replace that address with one pointing to your "data", and make your data actually be code.
  Volia, you now have this program running random code you included as part of a "data" file, which can do anything that program can do with it's given credentials. This is a buffer overflow exploit.
26. Re:Perhaps it's just that I'm ignorant... by soundman32 · 2014-01-08 06:04 · Score: 1
  
  Doesn't C++ allocate classes with virtual functions, similar to this? class show_me_the_money { private: char string_read_from_user_input[8]; public: virtual uint64_t money_func(int show_me); };
  
  --
  No sharp objects, I'm a programmer!
27. Re:Perhaps it's just that I'm ignorant... by SuricouRaven · 2014-01-08 11:23 · Score: 1
  
  This particular example may have been due to misuse of a library function, but eventually every program is going to need something coded that isn't in the standard library. It can't all be glue code.
28. Re:Perhaps it's just that I'm ignorant... by tibit · 2014-01-17 04:28 · Score: 1
  
  Sure, but the standard C library has promoted a certain groupthink where you don't care about pesky details like buffer lengths. Sometimes an API can have negative didactic impacts. I think a successful API design is a mixture of software design and pedagogy - after all, APIs are very often used by people much less skilled than the library developers.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
Re:Privilege escalation is to the server credentia by davydagger · 2014-01-08 03:30 · Score: 1

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.
Yay for free software! by Anonymous Coward · 2014-01-08 03:31 · Score: 0, Troll

If this was closed source, this bug would probably still be undiscovered.
Qubes OS unlikely to be affected by Burz · 2014-01-08 03:34 · Score: 1

It was designed assuming X11 (and Linux itself) had big security holes to begin with.
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.
1. Re:Qubes OS unlikely to be affected by Junta · 2014-01-08 04:15 · Score: 1
  
  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/
  
  --
  XML is like violence. If it doesn't solve the problem, use more.
2. Re:Qubes OS unlikely to be affected by Burz · 2014-01-08 04:35 · Score: 2
  
  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.
Re:Privilege escalation is to the server credentia by 10101001+10101001 · 2014-01-08 03:37 · Score: 5, Informative

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.

--
Eurohacker European paranoia, gun rights, and h
Re:Privilege escalation is to the server credentia by ajdlinux · 2014-01-08 03:39 · Score: 3, Informative

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 by Anonymous Coward · 2014-01-08 03:39 · Score: 0

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.
Let's see how the "dead" NetBSD handles this... by fisted · 2014-01-08 03:40 · Score: 1

-----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////binary/sets/xbase.tgz
with a date 20

--
CLI paste? paste.pr0.tips!
Re:Privilege escalation is to the server credentia by Anonymous Coward · 2014-01-08 03:42 · Score: 1

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.
This is not a story by Anonymous Coward · 2014-01-08 03:44 · Score: 0

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.
1. Re:This is not a story by Anonymous Coward · 2014-01-08 04:11 · Score: 1
  
  Unbelievable how many idiots post here...
Re:Privilege escalation is to the server credentia by Chemisor · 2014-01-08 03:46 · Score: 1

> 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.
Affects Win7 too, in a different but similar way? by Anonymous Coward · 2014-01-08 03:49 · Score: 0

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.
Go ahead, just TRY a buffer overflow on my VAX by thomasdz · 2014-01-08 03:51 · Score: 4, Funny

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.

--
Karma: Excellent. 15 moderator points expire sometime.
1. Re:Go ahead, just TRY a buffer overflow on my VAX by Burz · 2014-01-08 04:17 · Score: 3, Funny
  
  I'm tempted but the carbon footprint of the resulting 0wnage would probably be too great.
2. Re:Go ahead, just TRY a buffer overflow on my VAX by littlewink · 2014-01-08 05:22 · Score: 1
  
  "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."
  I learned it decades ago. There must be near hundreds of thousands of others that also know it. That's can be a problem with a once-popular architecture like VAX.
3. Re:Go ahead, just TRY a buffer overflow on my VAX by phorm · 2014-01-08 05:48 · Score: 1
  
  The bad news: The VAX server has been owned
  The good news: The hackers are asking for $5000, but they've agreed to take the $75k/year VAX admin position you posted instead.
4. Re:Go ahead, just TRY a buffer overflow on my VAX by danomac · 2014-01-08 06:03 · Score: 3, Funny
  
  Just buy some carbon credits and you'll be back in the green.
5. Re:Go ahead, just TRY a buffer overflow on my VAX by ckatko · 2014-01-08 07:17 · Score: 1
  
  By the same degree, wouldn't that imply a C64 (MOS 6510), and Tandy Model 100 (Intel 80C85) server would be just as secure?
  
  You really want to screw a hacker over, use an operating system with an "archaic" memory management system. Aww, you overran the buffer? That's cute, too bad it hit the end of the 16-bit data segment.
6. Re:Go ahead, just TRY a buffer overflow on my VAX by thomasdz · 2014-01-08 08:38 · Score: 1
  
  Those hundreds of thousands of people who know VAX machine code are now retired and watching the weather channel on TV... not attempting to 0wn my server so they can get k4rm4 from their 'leet hacker peeps.
  
  --
  Karma: Excellent. 15 moderator points expire sometime.
Isn't the XServer what runs on the user's side? by Anonymous Coward · 2014-01-08 03:53 · Score: 0

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?
1. Re:Isn't the XServer what runs on the user's side? by Burz · 2014-01-08 04:22 · Score: 1
  
  Its how the user communicates with and controls the system, so in a sense it doesn't matter if X is 'unprivileged'.
2. Re:Isn't the XServer what runs on the user's side? by Cacadril · 2014-01-08 05:00 · Score: 1
  
  You are right, the X server runs on the user "terminal", i.e. the computer having a screen that the user sees. The X client runs on any computer, the same as the X server runs on, or a different one. Back in the early nineties some of us used "thin client" style dedicated X servers. They were pure user terminals with no disk. They would typically load fonts from an nfs (network file system) server. But a vulnerability could in principle allow an attacker to gain control over the sessions, log the key presses, etc. To get there, the attacker would have to trick you into loading a modified bitmap font that (s)he provided. Back then that would have been quite hard, most of the time. Applications seldom installed fonts, they just supplied a font selector string specifying some parameters of the desired font. But with some social engineering, and providing the victim with an application to install, that application could load a font included in the application installation. Presto.
  
  --
  There is no substitute for common sense. Especially, no body of rules will do.
3. Re:Isn't the XServer what runs on the user's side? by fisted · 2014-01-08 05:08 · Score: 1
  
  I don't know why it matters to you, but no, terminology didn't change. The X server is what does the actual displaying, X clients are GUI-programs [which need not run on the same host]
  
  --
  CLI paste? paste.pr0.tips!
4. Re:Isn't the XServer what runs on the user's side? by Billly+Gates · 2014-01-08 05:52 · Score: 1
  
  I don't know why it matters to you, but no, terminology didn't change. The X server is what does the actual displaying, X clients are GUI-programs [which need not run on the same host]
  Which are irrelevant in that we dumped dumb terminals decades ago and 98% of us run both locally. This is part of the big push to Wayland.
  
  --
  http://saveie6.com/
Re:Privilege escalation is to the server credentia by organgtool · 2014-01-08 03:55 · Score: 1

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:Affects Win7 too, in a different but similar wa by Anonymous Coward · 2014-01-08 04:01 · Score: 0

Interesting...there could be a bug there somewhere.
Re:Privilege escalation is to the server credentia by Anonymous Coward · 2014-01-08 04:04 · Score: 0

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 by Anonymous Coward · 2014-01-08 04:05 · Score: 1

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 by Anonymous Coward · 2014-01-08 04:07 · Score: 0

Number of ./ ignorants like you is staggering.
Re:Privilege escalation is to the server credentia by Anonymous Coward · 2014-01-08 04:11 · Score: 1

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 by drinkypoo · 2014-01-08 04:12 · Score: 3, Informative

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.

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Re:Privilege escalation is to the server credentia by aethelrick · 2014-01-08 04:15 · Score: 1

...unknown untity...
is this some sort of mysterious zombie boob?
Re:Privilege escalation is to the server credentia by noh8rz10 · 2014-01-08 04:22 · Score: 1

Any truly epic pwnage these days chains together a string of vulnerabilities like this that aren't earth shattering on their own.
Re:Privilege escalation is to the server credentia by dpilot · 2014-01-08 04:28 · Score: 1

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.

--
The living have better things to do than to continue hating the dead.
Discovered... by gmuslera · 2014-01-08 04:29 · Score: 1

... 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) makes almost certain that it could had been exploited before.
Re:Privilege escalation is to the server credentia by serviscope_minor · 2014-01-08 04:29 · Score: 1

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?

--
SJW n. One who posts facts.
Exploitable UIs by Danzigism · 2014-01-08 04:41 · Score: 1

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

--
*plays the Apogee theme song music*
1. Re:Exploitable UIs by Billly+Gates · 2014-01-08 05:49 · Score: 1
  
  Majority of updates on my centOS vm are for security updates as well. Your point?
  
  --
  http://saveie6.com/
2. Re:Exploitable UIs by jandrese · 2014-01-08 06:25 · Score: 1
  
  It didn't help that for years and years the console was nigh useless on your typical Windows box. Microsoft has made big strides in improving it, but it's still clearly a redheaded stepchild in Redmond.
  
  --
  
  I read the internet for the articles.
3. Re:Exploitable UIs by Danzigism · 2014-01-08 07:07 · Score: 1
  
  Not sure I understand your statement. What did your security updates actually update? My point was that MS's updates were specifically for GUI related issues. Considering this article is about X11/X.org, it just goes to show you that GUI's of all sorts are ironically the least secure but the one thing that has innovated operating systems over the years.
  
  --
  *plays the Apogee theme song music*
4. Re:Exploitable UIs by Anonymous Coward · 2014-01-08 10:37 · Score: 0
  
  How is it clearly a redheaded stepchild? The console in windows for the last few versions of windows can perform every single task that the UI can do, in many cases it has considerably more functionality than the UI. You can't even fully admin a SharePoint, Exchange, AD, DNS, DHCP or many other server roles without the console. i.e. you can admin a server without the UI, you can't admin it without the console. If that is a redheaded step child then I guess you have a different definition of one to the rest of us.
5. Re:Exploitable UIs by jandrese · 2014-01-08 10:55 · Score: 1
  
  The horrible primitiveness of cmd.exe is one example of neglect. The documentation available from a console only interface is also quite lacking. I'm not sure if Microsoft even ships a remote commandline access solution for Windows.
  
  --
  
  I read the internet for the articles.
6. Re:Exploitable UIs by Anonymous Coward · 2014-01-08 21:54 · Score: 0
  
  What year is there? 1999?
Re:Privilege escalation is to the server credentia by Anonymous Coward · 2014-01-08 04:48 · Score: 0

i dont run x as root. i accidentally type 'startx' in the login box nearly every damn day >
Re:Privilege escalation is to the server credentia by armanox · 2014-01-08 05:02 · Score: 3, Informative

Really? A quick look at Solaris11, Scientific Linux, and Fedora all say root. If I had my IRIX box up and running I'd bet it would say root too (granted, it's XSGI, not XOrg, so this probably doesn't apply). My HP-UX and AIX boxes don't appear to be running any form of X
From SL 6.4:
[armanox@dionysus ~]$ cat /etc/issue
Scientific Linux release 6.4 (Carbon)
Kernel \r on an \m
[armanox@dionysus ~]$ ps auxw | grep X
root 2413 1.1 0.8 150984 34360 tty1 Ss+ 04:05 8:04 /usr/bin/Xorg :0 -nr -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-Ms7KTS/database -nolisten tcp vt1
armanox 14804 0.0 0.0 103252 848 pts/2 S+ 15:52 0:00 grep X
[armanox@dionysus ~]$ ps -ef | grep X
root 2413 2410 1 04:05 tty1 00:08:04 /usr/bin/Xorg :0 -nr -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-Ms7KTS/database -nolisten tcp vt1
armanox 14825 14767 0 15:53 pts/2 00:00:00 grep X
[armanox@dionysus ~]$
and Fedora 18:
[armanox@hecate ~]$ cat /etc/issue
Fedora release 18 (Spherical Cow)
Kernel \r on an \m (\l)
[armanox@hecate ~]$ ps -ef | grep X
root 596 1 0 00:13 ? 00:00:00 /usr/bin/abrt-watch-log -F Backtrace /var/log/Xorg.0.log -- /usr/bin/abrt-dump-xorg -xD
root 935 797 0 00:13 tty1 00:00:18 /usr/bin/Xorg :0 -background none -verbose -auth /var/run/gdm/auth-for-gdm-nsglUa/database -seat seat0 -nolisten tcp vt1
armanox 25526 1866 0 11:54 pts/1 00:00:00 grep --color=auto X
[armanox@hecate ~]$
Solaris on Sparc:
Last login: Mon Jan 6 17:28:37 2014 from lab-files-001.l
Oracle Corporation SunOS 5.11 11.0 November 2011
admin@solarisvmsrv1:~$ ps -ef | grep X
root 1308 1303 0 Nov 06 vt/7 102:15 /usr/bin/Xorg :0 -nolisten tcp -br -novtswitch -auth /tmp/gdm-auth-cookies-pEay
admin 41176 41171 0 11:35:42 pts/1 0:00 grep X
admin@solarisvmsrv1:~$

--
I'm starting to think GNU is the problem with "GNU/Linux" these days.
My XServers run on Windows by johanwanderer · 2014-01-08 05:27 · Score: 1

It's kinda funny, but all my XServers run on Windows these days, and only run once in a blue moon, so I can access that one or two stubborn applications that requires X. Not that it makes it less of an issue.
huh by Anonymous Coward · 2014-01-08 05:31 · Score: 0

If only 3 people(they wont live forever) understand and maintain the underlining technology of x11 isn't it about time to replace it with wayland(which is community driven unlike mir) as soon as possible. I don't understand why nvidia and amd wont develop drivers for wayland and leave the x11 headache behind.
1. Re:huh by Anonymous Coward · 2014-01-08 05:59 · Score: 0
  
  I'm liking the look of things with Wayland in the future.
Who is checking fonts? by naughtynaughty · 2014-01-08 05:31 · Score: 1

The vulnerability is interesting. I'd be more interested in someone writing a tool to exam fonts for any that exploit this flaw and then seeing how many trace back to the NSA
Re:Privilege escalation is to the server credentia by broken_chaos · 2014-01-08 05:35 · Score: 1

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.
It's possible on almost any Linux distribution if you're using a KMS-based (modern open-source) driver. Actually has been like that for a couple years now. There are some lingering permissions problems (need write access to the tty it's running on, a few other device nodes, and the log files -- most of these are solved by using SGID to a dedicated group rather than SUID to root, the rest require minor patches or config changes) but the big hurdles are gone.
It's not the default anywhere because it's mildly fiddly to setup and requires that you're using the open source Intel, ATI, or Nouveau drivers. Probably has some problems with using a display manager (KDM, GDM, XDM, etc.) too, as those login to the already-running X server rather than starting a new one for the user.
Thanks, by Anonymous Coward · 2014-01-08 05:40 · Score: 0

Obama.
Another reason to switch to Wayland by Billly+Gates · 2014-01-08 05:46 · Score: 1

The fact it uses bitmapped fonts and can't do modern rendering and use the gpu and handle font hinting unless run as root is an epic failure and showing its age. The geeks who started Linux after 2003 had no clue how much of a hog x was on a 32 meg system. It would take 80% of your freaking ram! Somehow it is popular now to love xorg yet its ugly past keeps rearing its head.

--
http://saveie6.com/
Re:Privilege escalation is to the server credentia by Anonymous Coward · 2014-01-08 05:47 · Score: 0

You are kind of correct. The Xserver is actually run under the user's ID. Now there may be a listener like gdm that may run as root, but the X11Server is actually the client and runs as the user and the clients are actually apps that run on the server, like xterm and gnome.
Re:Privilege escalation is to the server credentia by tlambert · 2014-01-08 05:57 · Score: 1

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.
I think you and I have different definitions of "modern": XQuartz, OpenBSD, KMS all perform privilege separation.
It's actually trivial to do privilege separation of FreeBSD and NetBSD as well, if you are willing to apply patches, but there are known bugs in their non-POSIX saved IDs implementations that are problematic in this case. Linux has similar credentials implementation problems surrounding supplementary groups.
In terms of tty ownership, there are POSIX calls which can be used to take and drop ownership pretty trivially, if they are used in the correct order, and the non-root credential you run as doesn't have to be the same as the logged in user, nor does the XServer need to have write access to its own configuration files.
Trojanning authentication dialogs and so on are still an issue in the case that the buffer overflow is used, in the absence of a font server, and with local write access to the fonts directory, using this bug, but the advisory is a serious exageration at best; if they have write access to your fonts directory, you're pretty much already screwed.
Who is still using X anyway ? by Anonymous Coward · 2014-01-08 05:58 · Score: 0

X is no longer shipped with the default installation since 10.8 (Mountain Lion).
Just like they did for the floppy disk, Firewire, optical disks, and so on. It is most likely going to disappear within a year or two.
SystemD by Anonymous Coward · 2014-01-08 06:40 · Score: 0

Bet systemd will have similar problems. Minimally complex code and programs are the unix way.
My point being... by Junta · 2014-01-08 07:06 · Score: 1

Through exploiting Xorg then it can likely exploit more *important* things like credit card numbers, bank account information, and so on and so forth. The likelihood is very high that the exploited X server is going to host an input of some great importance.
If the user is very fastidious in sorting every single little thing into distinct AppVMs, then the attack surface can be meaningfully reduced. However such a fastidious user is unlikely to do activities that would cause bitmap fonts to be read in from an untrusted source.
Qubes OS is a fascinating tool to help the careful be more effective in their effort, but the practical reality is that the people most afflicted by these attacks would not create a more secure environment in Qubes than a normal environment.

--
XML is like violence. If it doesn't solve the problem, use more.
1. Re:My point being... by Burz · 2014-01-09 10:14 · Score: 1
  
  Through exploiting Xorg then it can likely exploit more *important* things like credit card numbers, bank account information, and so on and so forth. The likelihood is very high that the exploited X server is going to host an input of some great importance.
  I think having a few separate user domains labelled "banking" and such is all most people need to greatly reduce their risk from remote attacks, even though it takes just seconds to create new domains already populated with an OS.
  As for the implication of getting attacked while accessing your banking sites, well...
  
  If the user is very fastidious in sorting every single little thing into distinct AppVMs, then the attack surface can be meaningfully reduced. However such a fastidious user is unlikely to do activities that would cause bitmap fonts to be read in from an untrusted source.
  Qubes OS is a fascinating tool to help the careful be more effective in their effort, but the practical reality is that the people most afflicted by these attacks would not create a more secure environment in Qubes than a normal environment.
  I disagree completely. Even just separating banking/finance from everything else would make a big difference. There is no need to consider the strawman case of every single thing being siloed; it is similar to the argument against taking privacy measures because no one can be absolutely private.
  And data separation is not the only point of Qubes: After a system has been compromised, there is far less chance under Qubes that the PC has been subverted in some fundamental way... you at least have the means to remove the malware without facing a spoiled bootloader, kernel or BIOS.
  Keeping exploits unprivileged is still a very big deal, though separating unprivileged domains certainly adds to that value. To say "only for fastidious people" as a caveat is disingenuous snobbery... there's no reason to believe an average user could not understand and use Qubes' window-framed domains to enhance their security. That leaves user motivation as a possible barrier, and I think the correct approach is to match the public's concern over cybercrime and spying with a system that makes security-by-isolation easy to identify and use.
Re:Privilege escalation is to the server credentia by benjymouse · 2014-01-08 07:09 · Score: 1

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?
Yes it is. The technique is referred to as "return oriented programming". That is why you need strong ASLR to make DEP/NX effective. Windows and OS X (IIRC) are the only OSes with strong and complete ASLR.

--
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
NSA by LookIntoTheFuture · 2014-01-08 07:35 · Score: 1

I wonder how long the douche-bags at the NSA have known about this one.

--
Brave Sir Robin ran away. ("No!") Bravely ran away away. ("I didn't!")
Re:Privilege escalation is to the server credentia by fatphil · 2014-01-08 07:51 · Score: 1

You can use the "return to" exploit paradigm instead (that may be be return-to-libc or something else, all that matters is that you return to somewhere executable.)

--
Also FatPhil on SoylentNews, id 863
Re:Who is still using X anyway ? by Anonymous Coward · 2014-01-08 09:03 · Score: 0

Anybody who uses Linux, Unix, *BSD, Solaris
Re:Privilege escalation is to the server credentia by TangoMargarine · 2014-01-08 09:53 · Score: 1

I.e. push a different address onto the stack before you return, basically changing it to an unconditional jump?

--
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Re:Privilege escalation is to the server credentia by TangoMargarine · 2014-01-08 10:01 · Score: 1

Interestingly, it's been X11 since 1985/6, according to Wikipedia. If this was a Google product, we would be on ~X190 by now, going off of Chrome's numbering.

--
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Re:Who is still using X anyway ? by TangoMargarine · 2014-01-08 10:25 · Score: 1

How can you know what the X Windows System is and not know that Linux runs it?

--
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
On deaf ears by Anonymous Coward · 2014-01-08 18:40 · Score: 0

Hundreds of free-software supporters are presently struggling with whether to cover their eyes and exclaim "LALALALALA" or whether to immediately start their "but Windows..." misdirection campaign.
Re:Privilege escalation is to the server credentia by DarwinSurvivor · 2014-01-09 02:58 · Score: 1

I also run startx (will xinit) from terminal as a non-root user and my X server still runs as root (this is on arch linux). Seems strange to me as well.
outdated fonts... by Lurking+Dude · 2014-01-09 10:01 · Score: 1

Thats idiotic... If the old fonts had built in exploits, you might have noticed by now (not so sure anymore) .. Nasty software however, can generate a malicious file and attempt to load it as a font...
VPS hosting.. by Lurking+Dude · 2014-01-09 10:04 · Score: 1

I hope my VPS hosting provider doesn't run X...