Re: My project

[Soubhik Bhattacharya <soubhik at cse dot iitk dot ac dot in>]

i'm no expert in security...... however, your project seems very exciting
to me and naturally, has given rise to a few questions.

i want to know about security-related issues that are visible to a
compiler or a programmer... ie about the secure coding standard. can you
give me useful references?

also, can you tell me how a buffer overflow or an 'untrusted' format
string of printf compromises systems security?



:** Buffer overflows
:
:Of course a possible solution to the buffer overflows problem is one
:of the "bounds-checking" patches that are currently being developed,
:but, as I understand, the added checks can sensibly affect the program
:performance.  In order to make less severe such a loss of performance,
:I added a new control structure.  Let me introduce it with an example
:
:    void
:    sum_vect (double *res, double *a, double *b, int dim)
:    {
:      int n;
:
:      loop (n=0:dim-1 ;; dst ?- res [[n]] ; A ?- a [[n]] ; B ?- b [[n]])
:
:        {
:          dst = A+B;
:        }
:    }
:
:I know, the syntax is quite ugly, but I will change it (if I can think
:something better...:-)
:
:In the code the loop, as you can guess, is executed `dim' times with n
:assuming the integer values between 0 and dim-1.  "Variables" `dst',
:`A' and `B' declared inside the loop structure are called "loop
:macros".  For example, with "dst ?- res[[n]]" I say to the compiler
:that every instance of "dst" in this loop must be replaced by
:"res[n]".  The advantage of this structure is that the compiler knows
:in advance which elements will be accessed and it can check the bounds
:before the loop starts.  Inside the loop the elements of `res', `a'
:and `b' will be accessed without any check, saving time.
:


what exactly is this bound checking? how does it work if the pointers are
dynamically allocated, or even, statically allocated in some other module?


:** Critical parameters
:
:Some functions of the C library are quite critical from a security
:point of view since if some of their parameters are controlled by the
:user, a security hole can be introduced.  The most trivial example is
:the system() function, a less obvious example are the functions in the
:printf() family which could be used to mount an attack if the `format'
:parameter is controlled by the user.  Although the printf() case is
:handled by another gcc patch, my proposal introduces a more general
:approach to the problem.
:
:In order to avoid this type of problem, I introduced the new keyword
:`trusted'.  Let me explain with an example.  If one declare the
:printf() prototype as follows
:
:  printf(trusted char *fmt, ...)
:


it seems that a rewrite of c library functions (or at least, redefinition
of their prototypes) will be necessary for this scheme to
work... otherwise something like 'printf("%s", s);' will make 's'
'untrusted'... am i right?


bye
soubhik.