Re: stackguard-like embedded protection

[Michael Wojcik <Michael.Wojcik () MERANT COM>]

> From: Hiroaki Etoh [mailto:ETOH () JP IBM COM]
> Sent: Wednesday, September 13, 2000 6:21 AM

> I tested GCC aix, xlC aix, and Microsoft Visual C++. They don't place the
> 'volatile' variable next to the RET.  Could someone test the following
> program in the other compilers. I am very interested in such information.

I'm using a slightly modified version of your program:

   #include <stdio.h>
   #include <stdlib.h>
   int main(void)
   {
      volatile int x=0;
      char buf[20];
      printf("%s!! x:%x buf:%x\n", ((char*)&x>buf)?"ok":"no", (long)&x,
             (long)buf);

      return EXIT_SUCCESS;
   }


AIX 4.2.1 (PowerPC), xlc 3.1.4.0 (common-mode code generation)
--------------------------------------------------------------
no options:     no!! x:2ff22920 buf:2ff22924
with -g:        no!! x:2ff22920 buf:2ff22924
with -O:        no!! x:2ff22920 buf:2ff22924


AIX 4.2.1 (POWER), xlc 3.1.4.0 (common-mode code generation)
------------------------------------------------------------
no options:     no!! x:2ff22a30 buf:2ff22a34
with -g:        no!! x:2ff22a30 buf:2ff22a34
with -O:        no!! x:2ff22a30 buf:2ff22a34


HP-UX 10.10 (model 715), HP ANSI C B.10.10 + PHSS_14326
-------------------------------------------------------
no options:     no!! x:7b03a728 buf:7b03a730
with -g:        no!! x:7b03a728 buf:7b03a730
with -O:        no!! x:7b03a728 buf:7b03a730


HP-UX 11.0 (model C360), HP C (version unknown)
-----------------------------------------------
no options:     no!! x:7f7f0800 buf:7f7f0808
with -g:        no!! x:7f7f0800 buf:7f7f0808
with -O:        no!! x:7f7f0800 buf:7f7f0808


FreeBSD 3.2-RELEASE i386, gcc 2.7.2.1
-------------------------------------
no options:     ok!! x:bfbfdc6c buf:bfbfdc58
with -g:        ok!! x:bfbfdc6c buf:bfbfdc58
with -O:        ok!! x:bfbfdc6c buf:bfbfdc58


UnixWare 2.1.3, SCO CCS 3.0
---------------------------
no options:     ok!! x:8047dc0 buf:8047dac
with -g:        ok!! x:8047dc0 buf:8047dac
with -O:        ok!! x:8047dc4 buf:8047db0


SCO OpenServer 5.0.4, SCO UDS 5.1.0Ha
-------------------------------------
no options:     ok!! x:7ffffb90 buf:7ffffb7c
with -g:        ok!! x:7ffffb90 buf:7ffffb7c
with -O:        ok!! x:7ffffb90 buf:7ffffb7c


Solaris SPARC 2.6 (Ultra), Sun WorkShop C 4.2.1
-----------------------------------------------
no options:     ok!! x:effffaf0 buf:effffadc
with -g:        ok!! x:effffaf0 buf:effffadc
with -O:        ok!! x:effffaf4 buf:effffae0


Unfortunately, both of my AS/400s are unavailable at the moment; they would
be an interesting case.  (Note that on the AS/400 casting a C pointer to a
long is an information-losing process, as pointers are 128 bits, so the
second and third fields in the output would be suspect.  The %p conversion
specifier should really be used to print a representation of a pointer
value, but it's not guaranteed to be meaningful.  Also, stack-smashing and
similar attacks may not work on the AS/400, as it's very aggressive about
validating memory access.)  I may take the time one of these days to build
the program on OS/390 and report the results there, but it'd require
remembering a bunch of JCL, which is not my native habitat.


Comments: The slightly different results on the two AIX machines surprised
me; that may be a result of differences in the environment.  The x86 and
Solaris SPARC platforms ordered the variables the way Etoh's program wants
them, regardless of (the tested) compilation options.  On SPARC and
UnixWare, -O affected the absolute locations of the variables but not their
order; on the other platforms, options had no effect.  On most platforms the
two variables were adjacent (either 4 or 20 bytes apart, depending on
order), but not on HP-UX, which apparently used 8-byte alignment.


Michael Wojcik             michael.wojcik () merant com
MERANT
Department of English, Miami University