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

О проекте

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

MySQL

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

Хостинг

Другое








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

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

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

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

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

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

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

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

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

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

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

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






 
 
| Добавить в избранное | Сделать стартовой 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