П О Р Т А Л                            
С Е Т Е В Ы Х                          
П Р О Е К Т О В                        
  
Поиск по сайту:
                                                 
Главная

О проекте

Web-мастеру
     HTML & JavaScript
     SSI
     Perl
     PHP
     XML & XSLT
     Unix Shell

MySQL

Безопасность

Хостинг

Другое








Самое читаемое:

Учебник PHP - "Для Чайника".
Просмотров 178150 раз(а).

Иллюстрированный самоучитель по созданию сайтов.
Просмотров 75598 раз(а).

Учебник HTML.
Просмотров 74082 раз(а).

Руководство по PHP5.
Просмотров 45009 раз(а).

Хостинг через призму DNS.
Просмотров 51936 раз(а).

Подборка текстов стандартных документов.
Просмотров 45112 раз(а).

Учебник PHP - Самоучитель
Просмотров 51345 раз(а).

Документация на MySQL (учебник & справочное руководство)
Просмотров 51796 раз(а).

Внешние атаки...
Просмотров 41938 раз(а).

Учебник PHP.
Просмотров 37281 раз(а).

SSI в примерах.
Просмотров 27849 раз(а).






 
 
| Добавить в избранное | Сделать стартовой Project.Net.Ru | Помощь





Использование динамических буферов

Переполнение буфера основанно на содержимом стека, перезаписывая переменную и меняя адрес возврата функции. Атака имеет отношение только к автоматическим данным, которые расположены в стеке. Способ избавиться от проблемы - заменить массивы символов, расположенные в стеке, на динамические переменные, находящиеся в куче. Чтобы сделать это мы заменяем последовательность

  #define LG_STRING    128
  int fonction (...)
  {
    char array [LG_STRING];
    ...
    return (result);
  }
на:
  #define LG_STRING    128
  int fonction (...)
  {
    char *string = NULL;
    if ((string = malloc (LG_STRING)) == NULL)
        return (-1);
    memset(string,'\0',LG_STRING);
    [...]
    free (string);
    return (result);
  }
Эти строки увеличивают код и опасность утечки памяти, однако мы должны извлечь преимущество от этих изменений, чтобы изменить подход и избавиться от внушительных ограничений на длину. Надо добавить, что вы не должны ожидать того же результата, используя alloca(). Код получается похожим, однако alloca размещает данные в стеке процесса и это приводит к той же проблеме, что и автоматические переменные. Инициализирование памяти нулем, используя memset(), позволяет избежать некоторых проблем с неинициализированными переменными. Снова, это не решает проблему, эксплоит просто станет сложнее. Те, кто хочет продолжить рассмотрение темы, могут почитать статью о переполнениях кучи от w00w00.

В заключение, скажем, что возможно при некоторых обстоятельствах быстро избавиться от дыр в безопасности добавлением ключевого слова static перед определением буфера. Компилятор разместит эту переменную в сегменте данных далеко от стека процесса. Станет невозможным вызвать оболочку, однако это не решит проблему атаки DoS (Denial of Service - отказ в обслуживании). Естественно, это не будет работать, если процедура вызывается рекурсивно. Это "лечение" должно рассматриваться как смягчающее, используемое только для устранения дыры в безопасности в критическом положении без изменения большого количества кода.

Назад | Содержание | Вперед



Если Вы не нашли что искали, то рекомендую воспользоваться поиском по сайту:
 





Copyright © 2005-2016 Project.Net.Ru