User: Password:
|
|
Subscribe / Log in / New account

Xorg flaw

Xorg flaw

Posted Aug 19, 2010 5:35 UTC (Thu) by smurf (subscriber, #17840)
In reply to: Xorg flaw by nybble41
Parent article: An ancient kernel hole is closed

How exactly do you prevent stack overflows? Call a check_for_stack_limit() function from everywhere, which checks how big the stack is vs. how big it should be? (It would need to scan /proc/self/maps to figure out where the last shared memory segment happened to be placed.)

"The application is responsible" is a cop-out because there are zillions of programs out there, but only one kernel. Therefore, fixing the problem once (in the kernel), with a guard page (no need for expensive user-mode checks), is the right solution.

Of course, X should not recursively overrun its stack. It's (probably) still a bug in the X server. So?

"Security by forcing the programmer to write correct code" does not work. As a further example of this principle, witness the large number of PHP-based web sites with SQL injection holes.


(Log in to post comments)

Xorg flaw

Posted Aug 19, 2010 6:20 UTC (Thu) by avik (guest, #704) [Link]

What's the algorithm that requires unbounded (or user-bounded) recursion in X? Is it impossible to write it in a way that uses an external allocation rather than the stack?

Cf. quicksort.

The kernel should provide a guard page to prevent against unknown flaws, but known flaws should be corrected.

recursion

Posted Aug 19, 2010 16:33 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

AFAIU It is always possible to transform a recursive algorithm into an equivalent iterative one which stores intermediate state on the heap.

In some cases the recursive algorithm will be clearer, which makes maintenance easier (and reduces the chance of security relevant bugs). In some cases the iterative algorithm will be faster (particularly if your programming language or compiler suck)

recursion

Posted Aug 22, 2010 3:31 UTC (Sun) by jeremiah (subscriber, #1221) [Link]

>AFAIU It is always possible to transform a recursive algorithm into an equivalent iterative one which stores intermediate state on the heap.<

you don't write much XSLT do you...;)

Xorg flaw

Posted Aug 19, 2010 15:27 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> How exactly do you prevent stack overflows?

This is not exactly a new problem. There is plenty of software out there (e.g. real-time embedded systems; the Linux kernel itself) which manages not to crash or misbehave when faced with a fixed-size stack and no special VM protection. The tools are simple:

1. Do not permit unbounded stack recursion.
2. Static analysis - know your worst-case stack requirements.

There may be "zillions" of application programs, but most of them don't run as root and simultaneously share memory with untrusted clients. As a privileged server process, Xorg should be designed to be more secure than most, since *any* code-execution vulnerability in Xorg is a (potentially remote) privilege-escalation vulnerability.

> Of course, X should not recursively overrun its stack.... So?

So it's not a kernel bug. It may be easier in this case to block one known exploit vector by changing the VM behavior of the kernel, and I'm not arguing against the patch, but it's not the kernel's job to prevent you from mapping untrusted memory right below your stack, or from overflowing said stack.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds