16 окт. 2009 г.

Flowplayer и Internet Explorer (IE)

Проблема

Ставил тут Flowplayer на сайт Агуши и столкнулся с непонятным поведением IE относительно этого плеера. Первый раз открываю страницу - всё ок (видео подгуржается и играется), а если сделать refresh (f5) - то на сёрном фоне крутится кружочек загрузки и ничего не происходит.

Поиски

Долго гуглил по этой теме, нагуглил лишь только открытую тему на форуме самого плеера. Стал копаться сам.

Решение

Из гипотез было только либо кеширование плеера, либо кеширование мувика. После первого эксперимента стало понятно, что это кеширование плеера.

Решается это тупо запретом кеширования. Я сделал это путём помещения в .htaccess следующих строк: <IfModule mod_headers.c>
Header append Cache-Control "no-store, no-cache, must-revalidate"
</IfModule>

# Заголовок Expires
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "now"
</IfModule>

Дальнейшие коментарии излишни

13 мая 2009 г.

Еще мысль

Ненавижу, блять, рутинную работу типа проверки правильности вывода миллиона полей. Надо завести для этого специального арапчёнка. Или накодить его.

27 апр. 2009 г.

Мысль

Кодить сайты с нуля, без использования фреймворков - уебанство, которым занимаются дети или взрослые, которые недавно начали кодить.

27 мар. 2009 г.

PaX. Часть 2. ASLR

Ниже пеервод очередной части официальных доков про Pax.

Цель Рандомизации Распределения Адресного Пространства - внесение случайности в адреса, используемые задачей. Это приводит к тому, что целый класс атак заканчивается неудачей с измеримой вероятностью, а также позволяет выявить их, так как неудачные попытки атак скорее всего приведут к "падению" атакуемой задачи. Чтобы лучше понять идеи, стоящие за ASLR, давайте рассмотрим пример задачи и его адрсного пространства: сделаем копию /bin/cat в /tmp/cat, затем отключим все функции PaX на ней и запустим "/tmp/cat /proc/self/maps". Пометки [x] не относятся к исходному выводу задачи, будем использовать их для ссылок на различные строки при обьяснении.

[1] 08048000-0804a000 R+Xp 00000000 00:0b 812  /tmp/cat
[2] 0804a000-0804b000 RW+p 00002000 00:0b 812  /tmp/cat
[3] 40000000-40015000 R+Xp 00000000 03:07 110818  /lib/ld-2.2.5.so
[4] 40015000-40016000 RW+p 00014000 03:07 110818  /lib/ld-2.2.5.so
[5] 4001e000-40143000 R+Xp 00000000 03:07 106687  /lib/libc-2.2.5.so
[6] 40143000-40149000 RW+p 00125000 03:07 106687  /lib/libc-2.2.5.so
[7] 40149000-4014d000 RW+p 00000000 00:00 0
[8] bfffe000-c0000000 RWXp fffff000 00:00 0

Как мы видим, /tmp/cat - ELF приложение с динамической линковкой, её адресное пространство содержит несколько файловых ассоциаций.

[1] и [2] ссылаются на заружаемые ELF сегменты задачи /tmp/cat, содержащие код и данные (как инициализированные, так и не инициализированные) соответственно.

[3] и [4] представляют динамический линковщик, в то время как [5], [6] и [7] - это сегменты runtime библиотеки C ([7] и [8] остаются не инициализированными, потому что достаточно велики, чтобы поместиться в последнюю страницу [6]). [8] это стэк, который растёт вниз.

Существуют различные вариации распределения памяти, которые не отображаются этим простым примером.

Для поставленных целей все эти распределения могут быть разбиты на 3 группы:

  • [1],[2] и, следующая за ними, куча, управляемая brk()
  • [3]-[7] все остальные распределения, созданные mmap()
  • [8], стек

Области первой и третьей группы организованы при помощи execve() и не двигаются, тогда как вторая группа может возникать и исчезать в процессе работы задачи. Так как базовые адреса, используемые для размещения каждой группы не связанны друг с другом, существует возможность применять к каждому из них различную рандомизацию.

Проследим (побочные) эффекты ASLR. Наиболее интересен эффект на тип атак, которые требуют предварительного знания некоторых адресов в атакуемой задаче, например, адрес текущего указателя стека или библиотек. Если нет способа, позволяющего раскрыть информацию об уже рандомизированном распределении адресного пространства задачи, то для атаки есть лишь один способ - предположение или перебор адресов. Предположение используется, когда рандомизация, применяемая к задаче, всегда применяется непредсказуемо. То есть злоумышленник не знает ничего о будущей рандомизации и каждый раз имеет одинаковые шансы на удачную атаку. Перебор применяется, когда злоумышленник может что-либо узнать о будущей ранзомизации и использует это знание в своей атаке. На практике перебор применяется к ошибкам в сетевых демонах, которые вызывают fork() при каждом соединении, так как fork() сохраняет рандомизированное распределение, в противоположность execve(), которая распределение его новым. Это различие между методами атаки становится ничего не значащим, если в системе предусмотрены механизмы реагирования на аварийное завершение задач. Эти реакции могут быть прописаны на столь низком уровне, что эти два вида атак будут иметь одинаковые возможности на (не)успешное завершение.

Чтобы количественно описать вышеописанные постулаты о (не)возможности удачной атаки, рассмотрим, для начала несколько переменных:

Rs: количество бит, рандомизированных в пространстве стека, Rm: количество бит, рандомизированных в пространстве mmap(), Rx: количество бит, рандомизированных в главном исполняемом пространстве, Ls: положение младшего рандомизированного бита в пространстве стека, Lm: положение младшего рандомизированного бита в пространстве mmap(), Lx: положение младшего рандомизированного бита в главном исполняемом пространстве, As: количество рандомизированных бит стека, уязвлённых (угаданных или подобранных) за одну попытку атаки, Am: количество рандомизированных бит mmap(), уязвлённых за одну попытку атаки, Ax: количество рандомизированных бит в главном исполняемом пространстве, уязвлённых за одну попытку атаки.

Например, для i386 дествительны следующие величины Rs = 24, Rm = 16, Rx = 16, Ls = 4, Lm = 12 и Lx = 12 (то есть, в адресах стека 24 бита рандомизировано в разрядах 4-27, а более старшие и более младшие биты не заронуты рандомизацией). Количество атакуемых битов получается из того факта, что в данной ситуации может быть уязвлено более одного бита (очевидно A <= R), то есть, дублирование полезной нагрузки (непосредственно кода) в памяти множество раз может преодолеть младшие рандомизированные биты.

Вероятность успеха при совершении x попыток вычисляется по следующим формулам (для предположения и перебора соответсвенно):

(1) Pg(x) = 1 - (1 - 2^-N)^x, 0 <= x  (для предположения) (2) Pb(x) = x / 2^N, 0 <= x <= 2^N  (для перебора)

где N = Rs-As + Rm-Am + Rx-Ax, количество необходимых рандомизированных бит. Ниже приведены таблицы, основанные на вышеизложенных функциях вероятности удачной атаки от количества испробованных битов за одну попытку (N) и количества попыток (x).

Pg(x)| x
-----+----------------------------------------------------------------------
N   |    1    4   16   64  256 2^10 2^14 2^18 2^20 2^24 2^32 2^40 2^56 2^64
-----+----------------------------------------------------------------------
1   | 0.50 0.94   ~1   ~1   ~1   ~1   ~1   ~1   ~1   ~1   ~1   ~1   ~1   ~1
2   | 0.25 0.68 0.99   ~1   ~1   ~1   ~1   ~1   ~1   ~1   ~1   ~1   ~1   ~1
4   | 0.06 0.23 0.64 0.98   ~1   ~1   ~1   ~1   ~1   ~1   ~1   ~1   ~1   ~1
8   |   ~0 0.02 0.06 0.22 0.63 0.98   ~1   ~1   ~1   ~1   ~1   ~1   ~1   ~1
16   |   ~0   ~0   ~0   ~0   ~0 0.02 0.22 0.98   ~1   ~1   ~1   ~1   ~1   ~1
24   |   ~0   ~0   ~0   ~0   ~0   ~0   ~0 0.02 0.06 0.63   ~1   ~1   ~1   ~1
32   |   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0 0.63   ~1   ~1   ~1
40   |   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0 0.63   ~1   ~1
56   |   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0 0.63   ~1

Pb(x)| x
-----+----------------------------------------------------------------------
N   |    1    4   16   64  256 2^10 2^14 2^18 2^20 2^24 2^32 2^40 2^56 2^64
-----+----------------------------------------------------------------------
1   | 0.50
2   | 0.25    1
4   | 0.06 0.25    1
8   |   ~0 0.02 0.06 0.25    1
16   |   ~0   ~0   ~0   ~0   ~0 0.02 0.25
24   |   ~0   ~0   ~0   ~0   ~0   ~0   ~0 0.02 0.06    1
32   |   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0    1
40   |   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0    1
56   |   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0   ~0    1

Очевидно, что с точки зрения защиты, цель - сделать N как можно большим и при этом уменьшить x насколько это возможно. К сожалению, защита не может влиять на N (перерандомизация адресного пространства в режиме реального времени недостижимо, потому что часть информации, необходимой для перераспределения попросту утеряна), но зависит от квалификации злоумышленника и рода уязвимости. Уменьшение N возможно, если злоумышленник может хранить множество экземпляров полезной нагрузки (например цепочка кадров стека если NOEXEC включена, или shell-код, если выключена) в адресном пространстве атакуемой задачи. Это обычно может быть возможно при тех уязвимостях, когда злоумышленник может заполнять большие области памяти необходимыми ему данными. С превышением размером этой области памяти значения L, отвечающего этой области, все больше и больше рандомизированных бит не влияют на полезную нагрузку атаки. Например, чтобы преодолеть весь R для заданного диапазона на архитектуре i386, атакующий должен отправить 256 MB данных - задача, очень трудновыполнимая (т.к. стек обычно ограничивается пределом в 8 MB и очень редко бывает больше).

26 мар. 2009 г.

PaX. Часть первая.

Ниже перевод официальных доков про PaX - патч безопасности для линукса.

Цель проекта PaX - исследование различных защитных механизмов, направленных против эксплуатации ошибок в программном обеспечении, которые дают атакующему произвольный доступ на запись/чтение адресного пространства атакуемой программы. Этот класс ошибок, помимо прочего, содержит множество форм переполнения буфера (основанных на переполнении стека или кучи), уязвимостей форматной строки и т.п.

Необходимо понять, что основной акцент ставится не на поиске и устранении подобных ошибок, а, в большей степени, на предотвращение и изолирование атак на уязвимые приложения. Все такие атаки могут влиять на атакуемое приложение на трёх различных уровнях:

  1. Внедрение \ исполнение произвольного кода
  2. Исполнение существующего кода вне обычного порядка исполнения программы
  3. Исполнение существующего кода в обычном порядке и произвольными данными

Например, широко известная атака на внедрение shell-кода относится к (1), а так называемые return2libc атаки - к (2)

Внедрение кода в адресное пространство задачи доступно как созданием исполняемой последовательности, так и изменением уже имеющейся записываемой \ исполняемой области. Первый метод может быть предотвращен при помощи контроля содержимого в задачи и выходит за пределы проекта PaX. Правильным решением здесь являются системы котроля доступа. Второй метод может быть предотвращён посредством запрета создания записываемых \ исполняемых областей. Однако, это решение мешает тем приложениям, которм такие области действительно нужны, но пока они не будут переписаны, это лучшее, что мы можем сделать.

Исполнение кода (как внедрённого хакером, так и уже существующего в адресной области приложения) требует возможности изменения порядка исполнения приложения при использовании уже существующего кода. Такие изменения возникают при разыменовывании ссылок на функцию. Атакующий может вмещаться в процесс исполнения, если эта ссылка (указатель) находится в перезаписываемой памяти. Несмотря на привлекательность идеи вообще не хранить указатели на функции в перезаписываемой памяти, это, к сожалению, невозможно, поэтому необходим другой поход. Так как эти изменения должны происходить в общей области памяти, а проект PaX пока что заточен под ядро, они пока не реализованы.

Следующая категория возможностей, предоставляемых PaX - это одна из форм диверсификации: случайное распределение адресного пространства (Address Space Layout Randomization - ASLR). Основная идея этого подхода основана на том наблюдении, что большинство атак требуют предварительного знания различных адресов в атакуемом процессе. Если удастся вносить энтропию в эти адреса каждый раз при создании задачи, злоумышленник будет вынужден предполагать или подбирать эти адреса. Эти атаки довольно "шумные" (заметные), так как большинство неудачных попыток, скорее всего "уронят" атакуемую задачу (вызовут сбой в работе, но не дадут злоумышленнику выполнить код, а ведь сбой в работе привлечёт внимание администратора).

В следующем посте будет информация про последнюю возможность (ASLR) ближе.

3 мар. 2009 г.

Планирование личных дел

Наткнулся на приятный сервис для личного планирования Планарий. Очень удобная штука для планирования плавающих задач. Есть деление на "хаос", "неделю" и "день". Можно планировать дела на сегодня, завтра, эту и следующую неделю, а так же оставлять дела в "хаосе", чтобы просто о них не забыть. А самая большая вкусность - возможность работы сервиса через джаббер. Очень удобно для личного планирования.

26 янв. 2009 г.

с новым годом

Пора заканчивать праздники