Exo 1
=====

Q1. Function foo is not constant-time:
     - control-flow depends on high variables at line 7
     - data access depends on high variable at line 12 

Q2.

1. without AdSan 

An attacker can get the following information:
  - calling foo(i) for increasing positive values of i allows to know position of the 1st strictly
    positive element of T (if any), since function foo terminates and returns i when T[i]>0
  - in case we get a "segmentation fault" when calling foo we may (strongly)
    suspect that y is not a valid index for T
  - if T does not contain any positive elements, and if y is a valid
    index of T, then we can know the value of y, since it wil be returned by
    a 2nd execution of foo in this case (r+x being positive)

2. with Adsan

With Adsan an exception is raised when a memory error occur.
Therefore, we can know "for sure" the size of T if it does contain only negative elements 
(trying increasing positive values of x) and if y is a valid index for T.

Note that T and y are assumed to be stored in *secure* locations, and not in
the execution stack (as global variables), which prevents the attacker to read
their memory contents ...

Note that, strictly speaking,  none of these information are obtained through "timing attacks"
(since the value of index r is explicitely returned by foo).

Q3.  The "nomminal" behavior of foo is twofold:
     (a) returning the 1st index r such that 0<=r<x and T[r] is positive and
       returning x otherwise
     (b) assigning T[y] with r+x (where x is user-controlled).

In the following "solution" we simply update the code to get an execution to
always iterate x times (whatever ils the value of T[i]):

int foo (int x) { 
  int r=0 ;
  for (int i=0; i<x; i++) {
	    r = (T[i]>0) && (r=i) // (1) assigns r when T[i]>0
  }
  T[y]=r+x ; // (2) still non constant-time here!
  return r ;
}

Going further we remark that the loop itself is useless since it always 
terminates with r equal to x. It can therefore be rewritten as follows:

int foo (int x) { 
  T[y]=2*x ; // (2) still non constant-time here!
  return r ;
}


Note anyway that:

- Statement (1), to preserve behavior (a), is not yet constant-time at the
  assembly level (the "&&" operator being translated as a conditionnal branch).  
  This could (probably) be solved using bit-level operations only 
  (inside the loop body ...)

- Statement (2), to preserve behavior (b), is definitely non constant-time,
  and it will be (probably?) not possible to improve it since we need to 
  explicitely modify T[y] without modifying the other values of T 
   (and without depending neither on the size of T).


Exo 2 
======

Q1. A possible example which cannot be exploited is a good-old stack buffer-overflow overwritting the ret address ...
    void foo(char *m) {
       char T[20] ;
       strcpy(T, m); // overwites the return address
    }

Q2. 

Intel CET : 
	possible high memory overhead in case of long sequence calls (due to the shadow stack) 
    execution time overhead depends on the number of calls/ret statements only

ARM PAC :
	higher time overhead than Intel CET (each pointer dereference operation is checked!),
    memory overhead can be limited in practice by storing the signature on
    un-used bits (e.g., 24-address bits in practice for 32 bits pointers)   
	better protection : detect overwrites of function pointer (in the stack and in the heap)

Q3. Writting or reading a local variable through a stack buffer overflow won't be protected 
     by Intel CET, e.g.:

    void foo(char *m) { 
       char buf[10] ;
       int *p ;
       p = (int *)malloc(sizeof(int)) ; // initialize p 
       *p=42 ;
       strcpy(buf, m);  // assigns S without checking the size and may overwrite p
       printf("%d", *p); // may prints a part of the memory ...
    }

	With ARM PAC, the printf statement will be prevented to dereference p if
     it has been changed ...

Remark: ARM PAC does *not* protect against (classical) use-afetr-free, namely
        when a call to malloc returns a previously used address in the stack:
         p1 = malloc(..) ; // returns address @1
		free (p1)
        p2 = malloc(...)  // returns address @1 again (since it has been freed)
		... *p1 ..   //  valid operation since p1 has not been changed ...

Exo 3
=====

Q1. 
    The problem occurs at line 76, when a strictly negative index setting i is used to
     access settings[i] (which is no checked beforehand).
    Hence, the boolean value isAdmin may be overwritten with the provided index value v
    which can be choosen as non-null by the attacker, leading to promoting the user as admin ...  
 
  In practice this can be obtained as folows:

  int main() {
    // Creates a non-admin username called "bob"
    int user = create_user_account(false, "bob");

    // Updates the setting '-1' of user to the number '42'
    update_setting(user, "-1", "42");

    return 0;
}

Note that trying to overflow the field "setting" with a large value v to
overwrite isAdmin is not possible, since function atoi() cannot return a value 
larger than integer, hence v will fit inside setting[i] as long as index i is valid.

Q2. 
	1. Using stack-protector will not prevent this vulnerability to occur 
       (it lies inside a single struct variable, and does not exploit any return address overwritting). 

    2. AdSan should definitely detect the error (protecting each buffer against memory error)

	3. Making the stack non executable will not change anything ...

Q3. To pach this vulnerability we can simply replace line 73 by:

	   if (index==NULL || i >= SETTINGS_COUNT || i<0) { ...
    

      
 
  


lien vers la solution ...