2013

О "списках уязвимостей в программах"

Увидел в поиске по блогам вот это (первоисточники на западе, эти только перевели, но мне поиск нашел у них) и призадумался о качестве всех прочих подобных уведомлений.

Читаем:

LibRaw версии до 0.15.1

LibRaw-demosaic-pack-GPL2 версии до 0.15.1

LibRaw-demosaic-pack-GPL3 версии до 0.15.1

Имею сказать:
  • Не являясь специалистом в области ИБ, не могу сказать, является ли выход за пределы массива по фиксированному(!) адресу +4GB-1 (потому что там всегда 0xffffffff в индексе) возможностью выполнения произвольного кода. Возможно. Равно как является ли проблемой такой псевдокод a = malloc(..); free(a); free(a);. Возможно.
  • Эти проблемы в LibRaw 0.15.0 - были. Возможно, они серьезные, хотя мне так не кажется. Представить, что "удаленного пользователя" допустят до кода коррекции экспозиции - не могу.
  • Вот что я знаю точно:
    • Этих ошибок нет в LibRaw-demosaic-pack-GPL3, оно тут никоим боком.
    • этих ошибок нет в "версии до 0.15.1". Они есть в 0.15.0, а ветки 0.7...0.14 - не подвержены (по причине отсутствия соответствующего кода).
    Что позволяет мне предполагать, что никакого анализа никто не делал.

    SecurityFocus пишет что дескать vendor reported. Но ни одна скотина не пыталась сконтактировать с вендором и узнать подробностей.

Я собственно к чему - что теперь читая всякие security reports буду делить минимум на десять.

Upd: я не хочу спорить с наличием ошибок (они были, программы, как минимум падали). Мой поинт в том что

  • Если вы вендор - не надо репортить проблемы подробно (double call to free), все что вы написали - будет использовано против вас. Пишите просто "исправлена ошибка в обработке битых файлов Foveon"
  • Авторы этих репортов - не анализируют что сделано на самом деле, в каких версиях была ошибка и т.п. Соответственно нужно к этим репортам относиться: наличие репорта не означает проблемы (а отсутствие - отсутствия проблемы).

Про LibRaw C API

Граждане разработчики!

Кто-то, не помню когда, не помню где (в почте - не нашел!) просил у меня сделать аналог LibRaw::COLOR(row,col) (т.е. номер канала байера у конкретного пиксела) в C-API

Т.к. почты спрашивающего не нашел, могу только сделать объявление. А единственное место для объявлений у меня тут.

Я его вам сделал. libraw_COLOR(...). Есть в master (девелоперском) бранче на GitHub.

RawDigger 0.9.17

RC1 качали, но не жаловались. Значит - работает, значит надо релизить.

Изменения (Changelog)

Новое

  • Новый параметр настроек:

    Data Processing -> Selection/Sample stats: discard abnormal pixel values

    Если настройка включена, то при подчете статистики по selection или Sample отбрасываются 10% самых больших и 10% самых маленьких значений. Это позволяет фильтровать шум (грязь, небольшие блики) на снимках мишеней.

  • Поддержка новых камер:
    • Canon 100D (Rebel SL1), 700D (Rebel T5i)
    • Fujifilm: X20 и X100S,SL1000, HS50EXR
    • Sony SLT-A58
    • Nikon 1 J3, 1 S1, Coolpix A, Coolpix P330, D7100
    • Olympus XZ-10
    • Panasonic G6
    • Pentax MX-1
  • Exiftool обновлен до версии 9.30
  • sRAW/mRAW файлы Canon обрабатываются библиотекой RawSpeed т.е. открываются быстрее.

RawDigger 0.9.17 RC1

Граждане фотографы!

Если вы за компьютерами - потестируйте пожалуйста RawDigger 0.9.17 RC1: берите настоящую 0.9.17, тестирование RC1 закончено.

Изменения:

  • Новый параметр настроек:

    Data Processing -> Selection/Sample stats: discard abnormal pixel values

    Если настройка включена, то при подчете статистики по selection или Sample отбрасываются 10% самых больших и 10% самых маленьких значений. Это позволяет фильтровать шум (грязь, небольшие блики) на снимках мишеней.

  • Поддержка новых камер:

    Canon: 100D (Rebel SL1), 700D (Rebel T5i)
    Fujifilm: X20 и X100S,SL1000, HS50EXR
    Sony SLT-A58
    Nikon: 1 J3, 1 S1, Coolpix A, Coolpix P330, D7100
    Olympus XZ-10
    Panasonic G6
    Pentax MX-1

  • Exiftool обновлен до версии 9.30
  • sRAW/mRAW файлы Canon обрабатываются библиотекой RawSpeed т.е. открываются быстрее.
Исправлены ошибки:
  • Исправлена проблема с автоматической установкой уровня черного на 12-битных файлах Sony (A900 и подобные)
  • Исправлена ошибка: при изменении Preferences и нажатии кнопки Apply, обновление содержимого экрана работало только один раз, повторное изменение того же параметра и нажатие Apply не имело эффекта.
  • При обработке большого количества файлов (drop на иконку многих файлов на Mac) exiftool не запускается, если уже есть запущенный exiftool.

Подземный стук возвращается!

Две недели после установки таймера в HPET все было хорошо. А вчера подземный стук вернулся, а сегодня - повторился.

С теми же симптомами:

  • Cron встал.
  • "часы стоят" - при запуске top и подобного что рефрешится по таймеру - не рефрешится.
  • named: POKED TIMER в логах
  • cat /dev/urandom >/dev/null не поднимает частоту процессора, так и лежит на 200 (это, вероятно, оттого, что таймер стоит и powerd не просыпается)
  • Пакеты роутятся
  • при подаче нагрузки (утренние бэкапы) - оно не просыпается нормально. Вот сегодня туда вылилось ~40Gb бэкапа (из 90) и скорость записи по smb упала практически до нуля, пришлось ребутить эту FreeBSD.
Ну добавил еще:
kern.eventtimer.timer=HPET
kern.eventtimer.periodic=1
Но надежды мало - больше двух недель не менялось ничего - и тут вдруг началось.

Ну память еще поменяю, хотя в данной машине это делается лапароскопией.

Но что делать то? По всем прочим признакам - машина нормальная, процессор процессорит, следов битой памяти (вроде падений на компиляции) не видать.

Кто виноват и что делать? Linux - не предлагать!

LibRaw 0.15.1

Вот кто видел версию .0, чтобы сразу работала? Правильно, никто!

LibRaw 0.15.1:

  • Исправлен неверный расчет максимума данных для файлов Panasonic
  • Проверка на выход за пределы буфера в коде коррекции экспозиции

Берут где всегда

Вопрос: фильтрация данных со снимков мишеней

А вот проведу опрос (в каментах)

На снимках мишеней для профилирования бывает лишнее. Грязь на мишени, грязь на матрице и так далее. Это дело принято фильтровать и в RawDigger такая фишка запланирована.

Понятно как фильтровать: оценить все значения в квадратике, посчитать среднее/дисперсию, все пиксели, не влезающие в "окно" значений - выкинуть, пересчитать по невыкинутым.

Есть два варианта определения окна:

  1. Все что не влезает в окошко по "сигмам". Ну там ±2σ - пущаем, остальное - не пущаем.
  2. Установить лимит в штуках. Ну там по 10% верхних и нижних значений - отрезаем.
Результат будет - в нормальных условиях (пылинка не занимает больше 10% площади патча) - примерно одинаковым.

А вот как понятнее?

LibRaw 0.15.0 Release

LibRaw 0.15 уже давно используется в боевых проектах (скажем, в RawDigger), собственно я ее ради RawDigger и правил на ходу и она всегда была "релизного качества".

Пришла пора эту релизность формально закрепить, а версию 0.14 начать предавать забвению.

Вот наиболее важные изменения, суммированные по всем бетам:

Поддержка новых камер

  • Adobe DNG: поддержка Fast Load DNG (LightRoom 4.x), поддержка lossy-compressed DNG (LR 4.x, необходима сборка с libjpeg 6+)
  • Canon: G1 X, SX220 HS, EOS 5D Mark III, EOS 650D, EOS 1D-X, 100D (Rebel SL1), 700D (Rebel T5i),6D,EOS M,G15, S110, SX50
  • Casio: EX-ZR100,EX-Z8
  • Fujifilm: X-E1,X20, X100S,SL1000, HS50EXR,F800EXR, XF1, X-S1, HS30EXR, X1-Pro
  • Imacon Ixpress 39Mpix: Multishot-файлы
  • Leica: D-LUX6 и V-LUX4
  • Nikon: D4, D3200, D800, D800E,1 J2, 1 V2, D600,1 J3, 1 S1, Coolpix A, Coolpix P330, Coolpix P7700, D7100
  • Olympus: E-M5, XZ-2, XZ-10, E-PL5, E-PM2
  • Panasonic: G5, G6, DMC-GF5, FZ200, GH3, LX7
  • Pentax: MX-1, K-5 II, K-5 IIs, K-30, Q10
  • Samsung: EX2F, NX20, NX210, поддержка нового firmware NX100
  • Sigma: SD15,SD1, SD1 Merill, DP1, DP1S, DP1X, DP2, DP2S, DP2X (только в Demosaic-pack-GPL2)
  • Sony: SLT-A58, RX-1, SLT-A99, NEX-5R, NEX-6, NEX-F3, SLT-A37, SLT-A57

Изменения в API

Об одном известном макроассемблере

Вот есть такая dcraw.c, а в ней есть такие вот две строчки кода:
  unsigned int *data,pad[128],p;
  ...
  while (len--)
      *data++ ^= pad[p++ & 127] = pad[(p+1) & 127] ^ pad[(p+65) & 127];
И все было ничего в gcc 2.x...4.7, а вот 4.8 компилирует это место неправильно.

Я даже посмотрел генерируемые ассемблеры, увидел что разные, но за 30 секунд не разобрался (потому что константы 1 и 65 у 4.8 становятся 2 и 66 и надо внимательно смотреть в каком порядке там что инкрементится).

Переписал так:

  while (len--)
    {
      *data++ ^= pad[p & 127] = pad[(p+1) & 127] ^ pad[(p+65) & 127];
      p++;    
    }
Помогло. Но осадок - остался.

Вопросов у меня, собственно, два три:

  1. Куды жаловаться на gcc Действительно UB? Но ведь есть такое естественное знание, что сначала вычисление правой части, а потом уже присваивание к левой. Это ж поимеет в куче мест.
  2. Правильно ли я понимаю, что пересечение множеств "Linux с пакетами собранными 4.8" и "Фотограф в RAW" крайне мало отличается от пустого множества?
  3. А не отличается ли это место в C и в C++?
P.S. Помимо баланса белого, который поминается в в багрепорте, отваливается еще и декодирование файлов с Sony DSC-V3, Sony F828 и, возможно, еще каких-то (у меня таблички декодер - камера нету)

P.P.S. Если отвалится какая-нибудь криптуха или там MPEG-декодер - я совершенно не удивлюсь.

И еще про GPON

Спрашивали? Отвечаем!

Позвонил сегодня в МГТС-овский call-центр, на предмет пробный интернет перевести в настоящий и узнать пин-код от их "личного кабинета", дабы с тарифами потом самому играться.

Несмотря на то, что формально (как написано на сайте) нужны паспортные данные телефоновладельца, а иначе за пин-кодом велено идти в офис, эти паспортные данные у меня не спросили (а я их, блин, узнавал, трудился). А спросили:

  • Номер договора (он есть в тех бумажках, которые дают при подключении к GPON)
  • Адрес установки телефона
Такие дела.

Upd: личный кабинет у них а-ля МТС. И даже еще более чудовищный.

Upd2: сменить телефонный тарифный план из кабинета нельзя. Только в офисе. Пропала моя идея поэкономить 59 рублей в месяц (безлимитный телефон + 200Mbit стоят дешевле, чем 400-минутный телефон + 200Mbit), я разорен.

Pages