Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Vulnerability Development: stackguard-like embedded protection

stackguard-like embedded protection

From: antirez <antirez_at_linuxcare.com>
Date: Mon, 4 Sep 2000 10:08:05 +0200

Hi,

This is trivial, maybe also world-wide known, anyway:
a stackguard-like protection can be implemented
in a quite portable way:

/* This code is Copyright (C) 2000 by Salvatore Sanfilippo
 * and is shipped under the GPL license.
 * comments to: <antirez_at_linuxcare.com>
 */

#include <stdio.h>
#include <unistd.h>

int __save_rand;

#define RANDNUM 0x33992288
#define safe_enter int aux = get_rand()
#define safe_leave \
do { \
        if (aux != __save_rand) { \
                printf("bof\n"); \
                _exit(1); \
        } \
} while(0)

int get_rand()
{
        __save_rand = RANDNUM; /* WARNING: not reentrant */
        return RANDNUM; /* /dev/urandom can be ok */
}

int main(int argc, char **argv)
{
        safe_enter;
        char buffer[10];

        if (argc == 1)
                exit(1);
        strcpy(buffer, argv[1]);

        safe_leave;
        return 0;
}

example:

$ ./a.out aaaaaaaa
$ ./a.out aaaaaaaaaaaaaaaaaaaaa
bof

This works at least under i386 and under sparc (probably _a lot_ of others),
as you can see the major portability problem is the order of variables
in the stack.
The reentrancy problem may be solved using dynamic allocation
for the saved pseudo-random number.
This can be extended I think, anyway there are some advantages:

- Doesn't require patched compiler

- It's less intrusive and more portable.

- Protects the sensible functions, not all functions.
  this prevents performance degradation of trivial-to-audit
  functions.

Obviously the version presented is NOT secure as stackguard.
This want not be a stackguard replacement -- it's just an idea.

As suggested by Alessandro Rubini there is also a problem
with this approach: it seems directed to the programmer.
The programmer should not think in terms of stack protection tricks,
but in terms of good programming.

Agreed at all, even if from the state of view of
the redundancy this helps.
So, sorry for this bad coding example.

regards,
antirez

--
Salvatore Sanfilippo, Open Source Developer, Linuxcare Italia spa
+39.049.80 43 411 tel, +39.049.80 43 412 fax
antirez@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.
Received on Sep 04 2000
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos