The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Уязвимость в пакетном менеджере APT, позволяющая подменить загружаемый пакет

22.01.2019 22:19

В пакетном менеджере APT выявлена уязвимость (CVE-2019-3462), позволяющая злоумышленнику инициировать подмену устанавливаемого пакета, если атакующий получил контроль за зеркалом репозитория или способен вклиниться в транзитный трафик между пользователем и репозиторием (MITM-атака). Проблему выявил исследователь безопасности Max Justicz, известный обнаружением уязвимостей в пакетном менеджере APK (Alpine) и репозиториях Packagist, NPM и RubyGems.

Проблема вызвана некорректной проверкой полей в коде обработки HTTP-редиректов, что позволяет атакующему подставить собственное содержимое в данные, передаваемые в рамках HTTP-сеанса (по умолчанию Debian и Ubuntu используют при обращении к репозиторию HTTP, а не HTTPS, полагая, что достаточно цифровой подписи метаданных и проверки соответствия размера пакета).

Выявленная уязвимость позволяет подменить передаваемый пакет, после чего APT воспримет его как полученный с официального зеркала и инициирует процесс установки. Через включение во вредоносный пакет скриптов, запускаемых во время установки, атакующий может добиться выполнения своего кода в системе с правами root.

Для загрузки данных из репозитория APT запускает дочерний процесс с реализацией конкретного транспорта и организует взаимодействие с этим процессом при помощи простого текстового протокола с разделением команд пустой строкой. Суть проблемы в том, что обработчик транспорта HTTP при получении от HTTP-сервера ответа с заголовком "Location:" запрашивает у родительского процесса подтверждение редиректа, целиком передавая содержимое этого заголовка. Из-за отсутствия чистки передаваемых спецсимволов, атакующий может указать в поле "Location:" значение, содержащее перевод строки (например, "Location: /payload%0A%0A201%20URI%20Done...").

Так как данное значение будет декодировано и передано через канал связи с родительским процессом, атакующий имеет возможность симулировать иной ответ от обработчика транспорта HTTP и после блока "103 Redirect" подставить фиктивный блок "201 URI Done" с сопутствующими фиктивными метаданными. Например, если при запросе пакета "cowsay_3.03+dfsg2-3_all.deb" атакующий подставит ответ с "Location: /payload%0A%0A201 %20URI%20Done%0AURI%3A%20 http%3A//deb.debian.org ... Checksum-FileSize-Hash%3A%2020070%0A", такая подстановка приведёт к передаче родительскому процессу следующего блока данных:


   103 Redirect
   URI: http://deb.debian.org/debian/pool/main/c/cowsay/cowsay_3.03+dfsg2-3_all.deb
   New-URI: http://deb.debian.org/payload

   201 URI Done
   URI: http://deb.debian.org/payload
   Filename: /var/lib/apt/lists/deb.debian.org_debian_dists_stretch_Release.gpg
   Size: 20070
   Last-Modified: Tue, 07 Mar 2017 00:29:01 +0000
   MD5-Hash: 27967ddb76b2c394a0714480b7072ab3
   MD5Sum-Hash: 27967ddb76b2c394a0714480b7072ab3
   SHA256-Hash:  858d5116a60ba2acef9f30e08c057ab18b1bd6df5ca61c233b6b7492fbf6b831
   Checksum-FileSize-Hash: 20070

в котором все данные после строки "New-URI: http://deb.debian.org/payload" были закодированы в переданным злоумышленником ответе "Location:...".

Вычислением хэшей для загруженных файлов занимается обработчик транспорта, а родительский процесс просто сверяет эти данные с хэшами из базы подписанных пакетов. В числе метаданных атакующий может указать любые значения проверочных хэшей, привязанные в БД к реальным подписанным пакетам, но фактически не соответствующие хэшам переданного файла.

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

Загрузка вредоносного пакета производится через прикрепление пакета к файлу Release.gpg, во время его передачи. Данный файл имеет предсказуемое местоположение в ФС и прикрепление пакета к его началу не влияет на извлечение из данного файла цифровой подписи репозитория. Атакующий модифицирует передаваемый Release.gpg примерно таким образом:


   подставленное содержимое deb-пакета
   -----BEGIN PGP SIGNATURE-----
   ...
   -----END PGP SIGNATURE-----

Уязвимость устранена в выпуске APT 1.4.9, а также в обновлениях пакетов в Ubuntu и стабильных ветках Debian (Jessie и Stretch), но в экспериментальных ветках Debian пока остаётся неисправленной. Если имеется опасность проведения целевых MITM-атак, в качестве обходного пути защиты можно при выполнении операций с apt/apt-get явно отключать поддержку редиректов (например, "apt -o Acquire::http::AllowRedirect=false update"). Подобное отключение может привести к нарушению работы автоматического проброса на ближайшее зеркало, поэтому в sources.list следует заменить security.debian.org на конкретное зеркало (например, cdn-fastly.deb.debian.org).

  1. Главная ссылка к новости (https://justi.cz/security/2019...)
  2. OpenNews: Уязвимость в пакетном менеджере APT, проявляющаяся в конфигурациях с зеркалами
  3. OpenNews: Выпуск пакетного менеджера Apt 1.3
  4. OpenNews: В пакетном менеджере APT выявлена новая уязвимость
  5. OpenNews: Уязвимость в пакетном менеджере APT, позволяющая обойти проверку пакетов
  6. OpenNews: Уязвимость в пакетном менеджере APK, позволяющая удалённо выполнить код в Alpine Linux
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/50007-apt
Ключевые слова: apt
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (103) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Gagauz (?), 23:23, 22/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Так так... Ну что страдайте апт гетчики?
     
     
  • 2.9, Michael Shigorin (ok), 23:57, 22/01/2019 [^] [^^] [^^^] [ответить]  
  • –14 +/
    Ну поломайте же наконец меня. :]
     
     
  • 3.15, Qwerty (??), 00:13, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +24 +/
    Нет, Джо.
     
  • 3.117, fi (ok), 17:30, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А разве у ваших rpm-ок   нет своей подписи ??? Не верю!  rpm еще не пробили.
     
  • 3.126, Аноним (126), 14:49, 26/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если Вас поломают, Вы об этом можете никогда даже не узнать, будучи гением системного администрирования. Но тут многое зависит от того, кто и с какими целями это сделает.
     

  • 1.3, rm_ (ok), 23:34, 22/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > следует заменить security.debian.org на конкретное зеркало (например, cdn-fastly.deb.debian.org).

    Вроде бы security не обязательно заменять, он не использует CDN и редиректы. А вот если у вас был прописан http.debian.net, тот да.

     
  • 1.5, Аноняшка (?), 23:45, 22/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Казалось бы, при чем здесь gentoo...
     
     
  • 2.25, irinat (ok), 01:50, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если злоумышленник может сделать MITM, что мешает ему подменить тарбол с исходниками, который ты будешь выкачивать во время выполнения emerge?
     
     
  • 3.40, nE0sIghT (ok), 06:49, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > что мешает ему подменить тарбол с исходниками, который ты будешь выкачивать во время выполнения emerge

    Хеш тарбола в метаданных portage, очевидно.

     
     
  • 4.42, пох (?), 06:58, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    а portage ты через /dev/astral скопировал, а не открытым протоколом с левого зеркала смиррорил?

    Или они все же поумнели за десять лет?

     
     
  • 5.43, nE0sIghT (ok), 07:00, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ты не поверишь. Добро пожаловать в 2019 год, в котором portage синхронизируется с помощью Git.
     
     
  • 6.94, нах (?), 11:23, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    с зеркала? А чем это мне поможет?

     
     
  • 7.116, captcha 20168 (?), 16:33, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    цифровой подписью коммита и хешем этого самого коммита
     
  • 7.119, nE0sIghT (ok), 18:15, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это же Git с подписью каждого коммита.
    Можно установить автора последнего коммита и, если он - разработчик Gentoo, не беспокоиться.
     
  • 5.59, Гентушник (ok), 09:43, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    При обновлении portage он точно так же был проверен по хешу как и другие пакеты.
    А первая установка portage была осуществлена с диска (болванки) высланной мне по почте (не электронной).
     
     
  • 6.65, scor (ok), 10:07, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Вот на почте болванку и подменили! Нет у вас методов против Коли^W Почты России!:)
     
     
  • 7.71, Гентушник (ok), 10:24, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Всё возможно. Но в цепочке доверия нужно с чего-то начать.
    У кого-то это сайт https://gentoo.org, где они скачивают iso/stage и проверяют хэши. Тут доверие зиждется на доверии корневым сертификатам вшитым в браузер (на текущей ОС, а не устанавливаемой).
    У меня же это был диск.
     
     
  • 8.83, нах (?), 11:02, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    у правильной цепочки должно быть не одно возможное начало скачанные с того же с... текст свёрнут, показать
     
     
  • 9.99, rshadow (ok), 12:06, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Самое главное доверие, на котором все держится - это доверие тому что ты нах ник... текст свёрнут, показать
     
     
  • 10.112, нах (?), 15:55, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    лично ты может и не нужен хотя твои процессорные мощности могут пригодиться пом... текст свёрнут, показать
     
  • 9.101, Аноним (101), 12:37, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это начало какой то замудерённой сети, а не цепочки ИМХО ... текст свёрнут, показать
     
  • 9.107, Гентушник (ok), 13:44, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет Скачанные с какого-нибудь васянского зеркала, по http, через открытый WiFi ... текст свёрнут, показать
     
     
  • 10.113, нах (?), 16:05, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    по простому никак, но ключи меняются редко и обычно с анонсами, их айдишки должн... большой текст свёрнут, показать
     
  • 8.96, Andrey Mitrofanov (?), 11:25, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Обожаю форумную криптографию Она такая форумная Такая незамутнённая si... текст свёрнут, показать
     
     
  • 9.103, freehck (ok), 13:07, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Судя по всему вот они https gentoo osuosl org releases amd64 20160704 ... текст свёрнут, показать
     
     
  • 10.110, Andrey Mitrofanov (?), 14:15, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну, вот да-да я знал Вы там средь своих, гентушников, поучите, поуч... текст свёрнут, показать
     
  • 9.106, Гентушник (ok), 13:34, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Там есть файлы с подписями, но они полезны лишь в случае если у человека есть до... большой текст свёрнут, показать
     
  • 5.122, Я (??), 23:26, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    https://gentoo.org/support/news-items/2018-01-30-portage-rsync-verification.ht

    > Starting with sys-apps/portage-2.3.21, Portage will verify the Gentoo repository after rsync by default.

     
  • 3.41, пох (?), 06:57, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    а они что, по сей день не научились подписывать свои ебилды? Да ну, не может быть?!

    В 2008м-то я помню да, долго плакал, глядя на их "безопастность" с рсинком откуда попало и прочим хламом - при этом тщательно подсчитывающей контрольные суммы исходников. У freebsd, вероятно, скопипастили, там точно такая же глупость и по сей день - тщательнейшим образом тратят ресурсы на ненужно-хэши, предварительно скачав их по открытому svn (правда, там не слишком популярны зеркала).

    redhat и клоны к тому моменту уже лет десять как использовали pgp.

     
     
  • 4.55, nE0sIghT (ok), 08:58, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В 2008м-то я помню да, долго плакал

    Ну зачем ты слёзы то лил? Ну был же тогда уже emerge-websync с проверкой подписи всего дерева, не?
    Да, он был медленнее и по очевидной причине. И кушал больше трафика, но всё же?

    Вот я занекрофиндил инфу про него аж 2004 года: https://forums.gentoo.org/viewtopic-t-226263-start-0.html
    Мне правда лень искать его ебилды. А в 2014 году он стал модулем portage.

     
     
  • 5.90, нах (?), 11:08, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ну как бы костылик наверное уже был (его еще, правда, взять откуда-то надо было, в бустрапных имиджах он не сидел, и узнать о его существовании, при наличии штатных рекомендаций emerge --sync добавить в крон), но я ж говорю - на фоне героических подсчетов сумм каждого архива, которые даже для собственных оверлеев было не отключить (да мля, я это только что оттуда же и взял, хрен ли его считать!) выглядело анекдотом.

    (у free, если что, отключалось, не говоря уже про самодостаточные binary packages, не привязанные к дереву портов)

     
     
  • 6.108, Онанимус (?), 13:46, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Контрольная сумма для проверки на побитость, а не для верификации.
     
     
  • 7.114, нах (?), 16:06, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ну да, gzip же ж ее не проверяет, ага.

    Причем, заметьте - неотключаемая.

     
  • 6.120, nE0sIghT (ok), 18:32, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > в бустрапных имиджах он не сидел, и узнать о его существовании, при наличии штатных рекомендаций emerge --sync добавить в крон

    Сидел он, сидел.
    Вот даже в хэндбуке о нём написано было в далёком 2006 году: https://web.archive.org/web/20060410004826/http://www.gentoo.org:80/doc/en/han
    Правда не в контексте безопасности. Но я где-то в районе 2008-2010 годов на него перешел с emerge --sync. Как раз озадачился безопасностью.

     
  • 4.109, irinat (ok), 14:14, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > <...> В 2008м-то я помню да <...>
    > <...> там точно такая же
    > глупость и по сей день - тщательнейшим образом тратят ресурсы на
    > ненужно-хэши, предварительно скачав их по открытому svn (правда, там не слишком
    > популярны зеркала).

    А тебе повезло, что в 2008 ты не сталкивался с кеширующими проксями, от которых иногда приходили битые файлы. Или старые.


     

  • 1.7, Simion (?), 23:47, 22/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    # pacman -Syyuu It's the best
     
     
  • 2.10, Michael Shigorin (ok), 23:59, 22/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Арчеводы вообще-то дружно забили на в чём-то перекликающийся баг, которым им коллега нашёл и зафайлил: https://bugs.archlinux.org/task/45657
     
     
  • 3.19, Аноним (19), 00:39, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    К ним хоть зашли. А в альт кто-нибудь заходит? Или только выходит?
     
     
  • 4.21, Michael Shigorin (ok), 01:22, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > К ним хоть зашли.

    И хоть в белой шляпе, а не в серой.

    > А в альт кто-нибудь заходит? Или только выходит?

    Боюсь, Вам уже или к ослику Иа, или к профильному специалисту. :)

    PS: что самое смешное, арчик я тоже зеркалил на f.l.k.u.

     

  • 1.12, Аноним (12), 00:04, 23/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Получается обновление apt нужно качать через уязвимый apt...
     
     
  • 2.14, IdeaFix (ok), 00:07, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем? Его можно собрать... :)
     
     
  • 3.17, анонимус (??), 00:33, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Понадобятся шило, ножницы и пластиковая бутылка?
     
     
  • 4.33, Hz (??), 04:20, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    И фольга.
     
     
  • 5.44, пох (?), 07:02, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    и зажигалка, а ножницы оставьте неумехам - и без них норм.
     
  • 4.63, Аноним (63), 09:52, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    За что вы так называете gcc?
     
     
  • 5.118, Аноним (118), 18:01, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > За что вы так называете gcc?

    Потому что меня от него прёт

     
  • 2.26, irinat (ok), 01:57, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Либо настройками запретить переадресацию, либо воспользоваться security through obscurity, заменив Location: в бинарнике на какую-нибудь другую строку. И никому не говорить, на какую. Формально, уязвимость всё ещё есть, но вот угадать, на что ты там заменил, чтобы сделать атаку под твои системы — чрезвычайно проблематично.
     
  • 2.37, Shevchuk (ok), 06:32, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Можно при этом обновлении отключить перенаправления (источник уязвимости):

    $ sudo apt update -o Acquire::http::AllowRedirect=false
    $ sudo apt upgrade -o Acquire::http::AllowRedirect=false

     
  • 2.56, MrClon (ok), 09:02, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В новости ведь даже приведён волшебный ключик отключающий уязвимое поведение. Делаешь update && upgrade с -o Acquire::http::AllowRedirect=false, получаешь менее дырявый apt, живёшь спокойно до следующей уязвимости
     
  • 2.76, Andrey Mitrofanov (?), 10:33, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Получается обновление apt нужно качать через уязвимый apt...

    Кстати, да!  Я тоже там "наверху" никогда не читаю.
        http://www.opennet.me/openforum/vsluhforumID3/116369.html#75
    Я просто сразу иду и пишу всё то же самое "внизу".

     

  • 1.27, Аноним (-), 02:00, 23/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    > Для загрузки данных из репозитория APT запускает дочерний процесс с реализацией конкретного
    > транспорта и организует взаимодействие с этим процессом при помощи простого текстового
    > проткола с разделением команд пустой строкой.

    Опять синдром NIH и кастомные парсеры - в результате грабли. А ведь можно было использовать какой-нибудь JSON и не обосраться.

     
     
  • 2.28, Michael Shigorin (ok), 02:05, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > А ведь можно было использовать какой-нибудь JSON и не обосраться.

    И где Вы весь такой умный были в девяносто-когда-там-апт-делали...

     
     
  • 3.29, Аноним (-), 02:13, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > в девяносто-когда-там-апт-делали...

    Это понятно. Однако любителям изобретать свои "простые текстовые протоколы" стоит мотать на ус.

     
     
  • 4.34, Crazy Alex (ok), 04:45, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это да. И заодно - борцам с готовыми библиотеками.
     
  • 4.67, Ю.Т. (?), 10:11, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В "90-каком-то" году не было json, и только взлетал xml.
     
  • 3.84, freehck (ok), 11:03, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    >> А ведь можно было использовать какой-нибудь JSON и не обосраться.
    > И где Вы весь такой умный были в девяносто-когда-там-апт-делали...

    Подрастает уже которое поколение, для которого написать парсер или язык -- невыполнимая задача. Какие там протоколы, lex, yacc... =)

     
     
  • 4.95, CAE (ok), 11:24, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    lex - это мелко. Вот flex с состояниями без bison - вот это да.
     
     
  • 5.102, freehck (ok), 13:02, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > lex - это мелко. Вот flex с состояниями без bison - вот это да.

    lex -- это название собирательное. Их ведь много, и для каждого языка своя.

     
  • 2.30, Аноним (30), 02:15, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Apt писали, когда ни ты ещё не родился, ни JSON ещё не придумали. Поэтому, не спросив тебя, взяли стандартный HTTP (который основан на RFC 822, которому сто лет в обед, и что-то стандартнее придумать невозможно, но тебе этого не понять). Но с реализацией таки облажались (как могли облажаться и с JSON, но и этого тебе, похоже, не понять).
     
     
  • 3.31, Аноним (-), 02:22, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > взяли стандартный HTTP

    Попробуй потушиться и перечитать, на что отвечаешь. TLDR: к HTTP претензий нет.

     
  • 2.32, YetAnotherOnanym (ok), 02:35, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы так свято верите в непогрешимость сторонних парсеров?
     
     
  • 3.35, Crazy Alex (ok), 04:51, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Они больше на глазах и, как правило, более "архитектурно" написаны, как и то, что ими парсят. Все эти милые артефакты вроде разделения переводами строк и прочего плейнтекста давно пора хоронить, отползая, как минимум, к надёжным реализациям json, а лучше - к бинарям вроде protobufs с известными или явно указанными длинами, где понятий вроде escape просто нет.
     
     
  • 4.46, пох (?), 07:10, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    тысячигласс, да.

    Как правило они overengineered, bloated и вообще не поддаются анализу.

    > Все эти милые артефакты вроде разделения переводами строк и прочего плейнтекста давно пора
    > хоронить, отползая, как минимум, к надёжным реализациям json,

    кто сказал что они надежны?

    > а лучше - к бинарям

    ага, чтоб сразу срыв стека при подстановке левого кода (например, как у вас с _очень_ большими числами в качестве длины пакета?)

    Вместо того чтобы просто добавить тривиальную проверку что текст таки остается текстом, чего второпях в 96м не сделали. Потому что пакету или url на самом деле совершенно необязательно включать в себя "весь юникод".

     
  • 4.61, Andrey Mitrofanov (?), 09:44, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Они больше на глазах и, как правило, более "архитектурно" написаны,

    Что,, прям все?  Как http://langsec.org/ проверял?

    > надёжным реализациям json, а лучше - к бинарям вроде protobufs с

    Как http://langsec.org/ проверял-то7?

    > известными или явно указанными длинами, где понятий вроде escape просто нет.

    Аминь, веруем, бро.  [I]Нет.

     
  • 2.45, пох (?), 07:06, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    стесняюсь спросить - а в json парсерах не правят раз в месяц очередное "ой мы об третью кавычку споткнулись и внезапно вообще выполнили это как код"?

    Я правда не знаю - когда эта модная уродливая технология массово распространилась, мне уже было наплевать на этот опенсорсий, пусть хоть на голове стоят.

    А в былые годы любое употребление чего либо из набора libxml*/xslt (ваша предыдущая волшебная таблетка, если вы родиться опоздали) для меня означало что эту программу можно запускать только от nobody, желательно в chroot, желательно на чужой машине.

     
  • 2.54, sigprof (ok), 08:42, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Опять синдром NIH и кастомные парсеры - в результате грабли. А ведь можно было использовать какой-нибудь JSON и не обосраться.

    Вот только баг в данном случае не в парсере, а в генераторе. Если бы JSON формировали с помощью printf() (ну или, как в данном случае, std::cout << arbitrary_string), было бы то же самое.

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

     
     
  • 3.62, Andrey Mitrofanov (?), 09:45, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Опять синдром NIH и кастомные парсеры - в результате грабли. А ведь можно было использовать какой-нибудь JSON и не обосраться.

    // Хотя разлёт обобряю[I]!

    > Если бы JSON формировали с помощью printf() (ну или, как в

     

  • 1.36, Аноним (36), 06:02, 23/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > Вычислением хэшей для загруженных файлов занимается обработчик транспорта

    Зачем тогда было выносить "обработчик транспорта" в отдельный процесс? Зачем общаться с ним по какому-то доморощенному протоколу (в котором наверняка есть ещё тыща дыр)?

    По-моему, исследователь не очень искренен в своём анализе — основная проблема здесь не в выборе протокола (HTTP vs HTTPS), а в том что ключевой код проверки сигнатур отдан на откуп обработчику протокола. По такой же логике можно было интегрировать SSL-библиотеку, которая по дефолту разрешает NULL cipher, и спокойно спать, зная что своя задница прикрыта, а какие-то там баги — они не в APT, а в этом злосчастном дырявом TLS!

     
     
  • 2.47, пох (?), 07:14, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Зачем тогда было выносить "обработчик транспорта" в отдельный процесс?

    unixway, не, не слышали?

    давайте запилим уже systemd-aptd, ага. С бинарным протоколом с сразу remote root, если с той стороны приехало что-то странное.

    > ключевой код проверки сигнатур отдан на откуп обработчику протокола

    этот обработчик часть пакета, а не сторонний код, и вообще-то ему полагается быть надежным - он имеет дело как раз с untrusted input, в отличие от apt.
    Хотя решение и странное, поскольку в результате этот код задействуется в трех как минимум разных вместо одного.

     
     
  • 3.53, Аноним (36), 08:28, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Одно дело 8212 развивать независимые проекты, предоставляющие другим приложен... большой текст свёрнут, показать
     
     
  • 4.93, нах (?), 11:19, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в каком месте fileutils, к примеру - независимые проекты А если вы опоздали ... большой текст свёрнут, показать
     
  • 4.105, Michael Shigorin (ok), 13:29, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Одно дело — развивать независимые проекты, предоставляющие
    > другим приложениям стабильные интерфейсы.

    О, а покажите-ка список того, что Вы _уже_ наархитектурили (и взлетело).  А то вдруг очередное непризнанное юное дарование, теоретически рассуждающее о том, как космические корабли...

     

  • 1.39, Аноним (39), 06:44, 23/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как можно проверить в куче установленных апт ориентированных дистрибутивов, что все пакеты нормальные ? Может уже давно половину подменили ?
     
     
  • 2.87, Гентушник (ok), 11:06, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Развернуть рядом точно такую же систему с такими же пакетами и версиями (список установленных пакетов можно скопировать).
    Сравнить два каталога через любимую программу сравнивания файлов (например kdiff3 если надо с gui)
    Просмотреть придётся много (особенно конфигов), но по-крайней мере можно будет убедиться в целостности всяких бинарей автоматом.

    Все действия естественно выполнять НЕ из исследуемой системы.

     
     
  • 3.97, Andrey Mitrofanov (?), 11:31, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Развернуть рядом точно такую же систему с такими же пакетами и версиями

    И обязательно ч-з нескомпрометированный этими пра-а-ативными MITM-ами  Интернет!  Или хотя б через скомпрометированный _другими_, ога.

    ВМФ США распростёрает TOR-объятья.  Анонимы не дадут в сарказьм!

    > (список установленных пакетов можно скопировать).
    > Сравнить два каталога через любимую программу сравнивания файлов (например kdiff3 если
    > надо с gui)
    > Просмотреть придётся много (особенно конфигов), но по-крайней мере можно будет убедиться
    > в целостности всяких бинарей автоматом.
    > Все действия естественно выполнять НЕ из исследуемой системы.

     
  • 3.127, Аноним (127), 15:41, 24/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Как развернуть такую точно такую же систему с такими же пакетами и версиями?
     
     
  • 4.128, Гентушник (ok), 18:39, 24/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Готового рецепта не знаю Список пакетов с версиями можно вывести через dpkg-que... большой текст свёрнут, показать
     

  • 1.48, odd.mean (ok), 07:19, 23/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Для Debian есть прямой workaround, настолько прямой, что меня (Debian GNU/Linux везде кроме смартфона) это не коснулось вообще:
    # apt-get install apt-transport-tor
    Далее по инструкции: https://guardianproject.info/2016/07/31/howto-get-all-your-debian-packages-via
     
     
  • 2.50, ryoken (ok), 07:47, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А если подключены ещё пара реп, которые в тор никто не додумался закинуть?
    Вот странно, почему по умолчанию apt-transport-https & apt-transpoкt-tor не ставится в дебе...
     
  • 2.75, Andrey Mitrofanov (?), 10:31, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Для Debian есть прямой workaround, настолько прямой,

    ..., что он написан в новости наверху, он написан в DSA-, он....  ПРЯМООООЙ!!!  ой.

    Since the vulnerability is present in the package manager itself, it is recommended to disable redirects in order to prevent exploitation during this upgrade only, using:

    apt -o Acquire::http::AllowRedirect=false update
    apt -o Acquire::http::AllowRedirect=false upgrade  

    --https://www.debian.org/security/2019/dsa-4371


    >что меня (Debian GNU/Linux везде

     
     
  • 3.91, Andrey Mitrofanov (?), 11:11, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Для Debian есть прямой workaround, настолько прямой,
    > ..., что он написан в новости наверху, он написан в DSA-, он....
    >  ПРЯМООООЙ!!!  ой.
    > apt -o Acquire::http::AllowRedirect=false update
    > apt -o Acquire::http::AllowRedirect=false upgrade   [/I]

    Гм!  Обновил в своём Devuan ASCII 2.0.

    Так как все (пара-другая, потом бросил) попробованные зеркала Devuan-а, включая "Основной" deb.devuan.org, таки-да...

    зачем-то редиректили куда-то то .deb-ы, то Release-файлы, ...

    и должны были быть обновлены только пакеты apt (всё безопасно ещё со вчера:)), ...

    и _эти_ пакеты таки "merged" из донора-Debian-а, ...

    то сделал /etc/apt/sources.list-у...  Патч!...

    -deb http://deb.devuan.org/merged ascii-security main
    +deb http://mirror.yandex.ru/debian-security stretch/updates main

    , обновил [apt apt-utils libapt-inst2.0 libapt-pkg5.0]...

    и откатил sources.list обратно.


    >>что меня (Debian GNU/Linux везде

     
  • 2.100, rshadow (ok), 12:31, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если там какой нить баг окажется, то и следов кто тебе напихал не найти.
     
     
  • 3.115, нах (?), 16:08, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ну как будто ты найдешь следы кто поломал какой-нибудь левый репо давно забытый админами яндекса или еще какой хни?
     

  • 1.57, Аноним (57), 09:24, 23/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >apt-get install apt-transport-tor

    И АНБ вот уже сколько лет ломает всех, кто это юзает. Скажите спасибо Дебиану за бекдор и Убунту, у которой все репы по http.

     
  • 1.70, Аноним (70), 10:19, 23/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Соединяюсь с репами по HTTPS и мои волосы мягкие и шелковистые.
     
     
  • 2.85, Аноним (-), 11:03, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >  Соединяюсь с репами по HTTPS и мои волосы мягкие и шелковистые.

    Какой попсовый анон нонче пошел.

    Ссаными тапками по лицу автору новости. Соединяется по HTTP, и что? Подменили пакет - пофигу. Провели MITM-атаку - тоже пофигу. Все это должно быть не существенно, т.к. верификация пакета должна выявить любое вмешательство, хоть черта лысого!

    Уязвимости как раз в реализации механизмов верификации пакета, все остальное - не важно!

     

  • 1.72, Аноним (72), 10:26, 23/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Кто-то тут позавчера бил себя пяткой в грудь и кричал что в стабильном релизе нету уязвимостей, потому что он стабильный. Где вы все? Я хочу послушать ваши оправдания.
     
     
  • 2.77, Andrey Mitrofanov (?), 10:36, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто-то тут позавчера бил себя пяткой в грудь и кричал что в
    > стабильном релизе нету уязвимостей, потому что он стабильный.

    Потому что их _исправляют_.  Иди туда-вчера и прочитай, что там-тогда написано.  Если не получится -- обратно за букварь.

     
     
  • 3.78, Аноним (72), 10:42, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я сижу на дебьяне довольно продолжительное время, но пока что не видел чтобы исправляли. Багтрекер пестрит критическими уязвимостями в базовых компонентах, которые не правятся годами. Не так давно вылез баг в блендере, так его 2 месяца мариновали прежде чем исправить, хотя там всего-лишь нужно было blender data пересобрать. KDE собран через одно место, чтобы установить один пакет, нужно поставить весь KDE, неоднократно сообщалось в баг-трекер, все тикеты закрывали и удаляли без объяснения причин. В общем доверия к майнтейнерам не осталось никакого.
     
     
  • 4.79, Аноним (72), 10:51, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А ещё майнтейнер systemd временно отстранился от майнтенинга этого пакета, так что ожидаем очередной цирк с конями.
     
     
  • 5.86, Цирк без коней (?), 11:04, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Надо уточнять что именно в дебиан.
     
     
  • 6.92, Аноним (92), 11:18, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Надо еще уточнять что один из нескольких мантейнеров.
     
  • 4.81, Аноним (92), 10:58, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Я сижу на дебьяне довольно продолжительное время

    Да-да. Мы так и поверили.

     
  • 4.82, Andrey Mitrofanov (?), 10:59, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Я сижу на дебьяне довольно продолжительное время, но пока что не видел
    > чтобы исправляли. Багтрекер пестрит критическими уязвимостями в базовых компонентах,

    Пройдите на.
       https://www.debian.org/security/
       https://lists.debian.org/debian-security-announce/
    [I]" Вы там будете слушать. "(ц)

     
  • 4.88, Цирк без коней (?), 11:07, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Я сижу на дебьяне довольно продолжительное время, но пока что не видел чтобы исправляли.

    Любите опасность?)

     
  • 4.89, Цирк без коней (?), 11:07, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    "Я сижу на дебьяне довольно продолжительное время, но пока что не видел чтобы исправляли. "

    Любите опасность?)

     
  • 2.80, Аноним (92), 10:58, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Кто тебе куда бил? Иди регрессию после очередного обновления systemd исправляй, рачешкольник.
     
     
  • 3.98, дебилиан (?), 11:50, 23/01/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    а зачем ее исправлять? У полутора пользователей, вздумавших, вот поганцы, лучше Поцтера знать как дожен называться интерфейс, он пару раз попереименуется и потом его модный network-managerd не узнает? notabug, не выпендривайтесь, кушайте ваши ens16023134142
     

  • 1.111, Аноним (111), 15:50, 23/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Очередная дырка в Дебиане, всегда проигрываю.
     
  • 1.121, jalavan (ok), 21:42, 23/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Спасибо исследователю безопасности Max'y
     
  • 1.123, su (??), 11:20, 24/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    глаза откройте, у кого они еще есть. Уязвимость устранена в v.1.4.9. Для Debian 9.6. Stable уже не особо актуально
     
  • 1.124, Анонымоус (?), 21:24, 24/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Поясните далекому от всего этого http. Почему вообще свойства транспорта как-то повлияли на apt? Есть же подписанный Release, в нем есть хэш Packages, а в нем хэши deb'ов. И что мешает проверить хэш полученного файла? Для того это все и существует, чтобы обнаруживать, пришел ли файл целым и настоящим, или испорченным. Невзирая на то, как он пришел. Чего я не понимаю? Всего?
     
     
  • 2.125, Аноним (125), 15:33, 25/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Там проблема не в транспорте а в обработчиках и архитектуре апта. Из-за ошибки все проверялось не так как должно. Https уберег бы от этого.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру