Created attachment 7986 [details]
1st iDefense draft advisory

Created attachment 7987 [details]
Proof of concept for 1st advisory

POC for 1st advisory

Created attachment 7988 [details]
2nd draft advisory

Created attachment 7989 [details]
poc for 2nd advisory

Created attachment 7990 [details]
3rd draft advisory

Created attachment 7991 [details]
Poc for 3rd advisory

Here are CVE ids allocated by Josh Bresser:

CVE-2006-6101 iDefense X.org ProcRenderAddGlyphs
CVE-2006-6102 iDefense X.org ProcDbeGetVisualInfo
CVE-2006-6103 iDefense X.org ProcDbeSwapBuffers

Created attachment 8007 [details] [review]
Proposed patch

Any suggestion for a disclosure date? before or after 7.2 release?

(In reply to comment #8)
> Created an attachment (id=8007) [edit]
> Proposed patch
> 
> Any suggestion for a disclosure date? before or after 7.2 release?

Any update on this one? SUSE/Novell would be ready for a release with the 
proposed patch.

From Sun's point of view, we'd prefer one week prior notice to disclosure and
to not announce between Dec. 23 & Jan 1.   Other than that, we're open to 
whenever the community and other vendors are ready.

I haven't seen any proposed dates, so I'll nominate one:
Tuesday, January 9, 2007

Lets everyone get back from the holidays for a week to get everything ready 
to go.  This work for everyone?


Also, I had to make one small adjustment to the proposed patches on older
Solaris releases - I changed the include blocks to:

 +#if HAVE_STDINT_H
 +#include <stdint.h>
 +#elif !defined(UINT32_MAX)
 +#define UINT32_MAX 0xffffffffU
 +#endif

On releases older than Solaris 10, UINT32_MAX was defined in <inttypes.h> based
on a draft of the C99 spec before C99 switched to <stdint.h>, so they don't have
stdint.h, but give a redefined macro warning if you try to define UINT32_MAX
anyway.

ok for me. 14:00 UTC ?

I was waiting for feedback from ajax or daniel on the 7.2 release date, but they
seem to be buzy enough with the release process.

I'll send that to iDefense and vendor-sec tomorrow. 

Jan 9 is fine for Red Hat.

7.2 _should_ be baked before then, and we'll just have to do a 0-day release. 
These things happen.

I'm appending comments from iDefense to my patch. I'm not sure what the impact
of turning off alloca is, and other areas may have problems too since the 
3 places where iDefense spotted the integer overflows are not the only places
where ALLOCATE_LOCAL is passed a size that comes from the client.


Matthieu,

These patches do not properly fix the vulnerabilities.  In addition to
the integer overflow vulnerabilities, there are also vulnerabilities
present when ALLOCATE_LOCAL is #define'd to use alloca().   This is the
default on all of the platforms I verified these vulnerabilities on.
The following behavior:

alloca(some_user_controlled_value);

is inherently insecure.  GNU versions of alloca() merely subtract the
size argument from the current stack pointer after rounding the size up
to a 16 byte bounds.  This lets the stack pointer be shifted down to
point to other segments.

A possible "fix" would be to check if the parameter being passed to
alloca() is greater than some value.  This is still not a valid fix.
AFAIK, it is not possible know the bounds of the stack segment, or if
there is another segment mapped directly below it.  An attacker could
grow the stack low enough, perhaps using some recursive function or by
padding the environment, so that it lays directly above another mapped
segment.  If the current stack pointer is only a few hundred bytes above
the bottom of the stack, then even a small value passed to alloca() can
shift the pointer into a different segment.  Simply put there is not a
portable and secure way to use the alloca() function.  In order to fix
these vulnerabilities I would recommend using malloc().

Sean Larsson

Created attachment 8309 [details] [review]
Updated patch for git master

No one commented on Alan's proposition to turn off alloca globally in the X
server.
I'm a bit uncomfortable with doing this without torough testing of possible
performance impacts, so I'm proposing a patch that just turns the involved
alloca's into heap allocations.
This one is for git's master branch

Created attachment 8310 [details] [review]
patch for xserver 1.2 branch

And here's a patch for the 1.2 branch.

Patches committed.