Re: WordPad/riched20.dll buffer overflow

[casper () HOLLAND SUN COM (Casper Dik)]

> The kernel patch makes no such compromise.  As near as I can tell, it is
> completely performance neutral, and largely transparent.  The only compromise
> is that special handling for signal delivery is required, which the kernel
> patch provides.

Is it possible with the Linux kernel patch to still mprotect() parts
of the stack to read-write-execute?  My understanding is that that isn't
possible when using x86 segment descriptors (i.e., you get all or nothing)

> > Also, using segmentation pretty much guarantees that your OS cannot be
> > made to run on anything other than the x86 architecture (which is
> > about the worst of the bunch; no sane person would use x86 if wasn't
> > for the compatibility issues).
>
> Other, more sane, processors provide for read & no-execute pages, so you use a
> different kernel MMU mechanism to make the stack non-executable.  Thus, Casper
> Dik has a similar kernel enhancement for Solaris that makes the stack
> non-executable.

The feature I wrote as a script for Solaris 2.5.1 and before that hotpatched
kernel memory and code (and disassembled SPARC instructions in /bin/sh)
was later added as a feature to Solaris 2.6

Many MMUs/processors do not support this.  Older SPARC (sun4/sun4c kernel arch)
do not; even UltraSPARC doesn't provide MMU support; it supports non-executable
pages only because it has a split TLB.  When RW- pages get examined in the
iTLB handler, a fault is generated.  That also was added in Solaris 2.6,
so my script doesn't work for UltraSPARC in 2.5/2.5.1 either.

Casper