Re: machine independent protection from stack-smashing attack

[der Mouse <mouse () RODENTS MONTREAL QC CA>]

> > Our understanding is that the biggest reason why StackGuard hasn't
> > been ported to more architectures is that there's not really a
> > portable source of randomness available, such as a /dev/random.

> Not true!  There sure are and have always been sources of randomness
> on all the platforms.  It just always comes down to proper
> implementation.  Sure you would need to add processor-dependent code
> for each platform, but there sure is a portable source of randomness
> available.

If you will reread the text you replied to, I believe you will find
that it refers to a _portable_ source of randomness.  Adding
processor-dependent code for each platform is hardly portable -
especially when you have no assurance that the facility you're
depending on exists on the next platform someone wants to port to.

> It's called RDTSC on Intel, %tick on SPARC, etc. and it's a base for
> /dev/random anyway.

This is very implementation-dependent.  The NetBSD /dev/random, for
example, is not based on RDTSC, %tick, or whatever you're imagining for
other platforms (some of which, I suspect you will find, do not have
any such thing).  Indeed, I'm not even sure that "SPARC" (as opposed to
certain SPARC variants, such as v9) has %tick; when I try to assemble a
simple file using "rd %tick, %o0" the assembler says

"foo.s", line 2: Error: Architecture mismatch on "rd".
"foo.s", line 2:  (Requires v9|v9a; requested architecture is sparclite.)

which certainly indicates that whoever wrote the assembler thinks that
not all SPARCs can support that instruction.  (The assembler in
question identifies itself as "GNU assembler 2.9.1".)

> However, the authors of /dev/random didn't conduct any research on
> its behaviour, missing out on its true power.

Or perhaps they did, and found that a clock counter isn't sufficiently
random to produce high-quality randomness.  (I haven't researched it
either, but I would take a lot of convincing before believing that
something as tightly tied to the instruction stream as a clock counter
could produce even semi-decent randomness.)

> In any case a portable source of randomness is not the reason why
> StackGuard hasn't been ported to more architectures.

What is your basis for this statement?  Have you been discussing the
matter with the StackGuard people?

> And if a reliable source of randomness is really such a problem, I'm
> ready to share with you my (you can call it more random than
> /dev/random) random number generator based on the real power of the
> clock counter.

I recommend against using this generator for any application more
demanding than games or statistical simulations - anything requiring
real entropy, basically.  Here are some of the reasons why:

> Although strong on its own, I'd recommend adding a hash function of
> your choice and uncommenting bigrand to have a cryptographically
> strong RNG.  Otherwise returns truly random 64-bit numbers any time.

This paragraph makes me highly dubious of the whole thing.  If the
thing produces "truly random" numbers, the hash function is
unnecessary; if not, it doesn't help.  (The only time a hash function
helps is when the generator produces bits containing true entropy,
but less than one bit of entropy per bit produced, in which case a
quality one-way hash is good for distilling down the entropy.)

> /* To compile on Sun: gcc -m32 -msupersparc -mcpu=v8 -g -O3 -finline-functions -Wa,-xarch=v8plusc -Winline -lrt */

I tried that on the Sun on my desk (a SPARCStation-2 running
NetBSD/sparc 1.4T) and got

"yarrow.c", line 21: sched.h: No such file or directory

I commented out the offending #include and tried again, and got

Assembler messages:
Error: invalid architecture -xarch=v8plusc

Perhaps you're confusing "Sun" with "sufficiently recent Sun running
sufficiently recent Solaris"?

> /* To compile on Intel, MSVC with /G6 /Gr /O2 and with either /MT or /MD is recommended */

This sounds as though you think all Intel machines are running Windows.
This is not the case.

> /* if you make clock_counter return all 0's, still produces a stream indistinguishable from random. */

This sounds as though you are using "random" in the sense it's used by
people doing things like Monte Carlo simulations, meaning (very
roughly) "no self-correlation relevant to this application".  While
such numbers have value, this sense is much weaker than what's needed
for cryptographic applications, such as those /dev/random is designed
for.  Crypto needs real unpredictability, not just numbers whose
self-correlations don't happen to match anything in the application.

                                        der Mouse

                               mouse () rodents montreal qc ca
                     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B