Przepełnienie bufora - ataki na programy użytkownika


Wartą odrębnego omówienia techniką obrony jest sprawdzanie poprawności odwołań (code pointer integrity checking). Polega ona wykrywaniu sytuacji, w której ktoś podmienił adres powrotu na stosie. Znane mi metody:
  1. implementacja libc - Snarskii, szybka, ale działa tylko dla funkcji z libc, szczegóły http://gcc.fyxm.net/summit/2003/Stackguard.pdf.
  2. StackGuard - patch na gcc, który sprawdza poprawność adresów powrotu poprzez odkładanie na stosie tuż za adresem powrotu kanarka (ang. canary), czyli słowa, które będzie sprawdzone przed skokiem pod adres odłożony na stosie. Krytyczne jest zabezpieczenie kanarka przed podrobieniem. Osiąga się to poprzez:
    1. umieszczenie w kanarku znaków terminacyjnych typu NULL, CR, LF, EOF
    2. losowanie kanarka przy każdym wywołaniu programu
    Red Hat 5.1 został napisany przy użyciu tego narzędzia i jest on odporny na większość ataków przez podmianę adresu powrotu funkcji. Testowanie serwera apache pokazało około 10% spadek wydajności po użyciu StackGuarda.
  3. PointGuard - uogólnienie StackGuard na wszystkie wskaźniki. Widać jednak "gołym okiem" problemy, chociażby z tym, że trzeba alokować pamięć, dla zgodności z istniejącym oprogramowaniem, nie można po prostu zwiększyć rozmiaru chronionej zmiennej, należy ten obszar traktować jakoś specjalnie. Problematyczne jest również kwestia kiedy sięgamy do pamięci i powinniśmy sprawdzić poprawność wskaźnika. Projekt jest jeszcze daleki od kompletnego, ostateczny będzie umożliwiał umieszczanie kanarków również przy zmiennych statycznych.
W praktyce należy stosować mieszane taktyki obrony, kombinacja niewykonywalnego stosu i StackGuard jest proponowana jako skuteczna ochrona przed przepełnieniem bufora.


dalej