суббота, 7 мая 2016 г.
Создание системы непрерывного развертывания: опыт Instagram
В нашем блоге на Хабре мы не только рассказываем о развитии своего продукта — биллинга для операторов связи «Гидра», но и публикуем материалы о работе с инфраструктурой и использовании технологий из опыта других компаний.
В Instagram развертывание backend-кода (основная программно-аппаратная часть, с которой работают клиенты) происходит от 30 до 50 раз в день, каждый раз, когда инженеры подтверждают изменение оригинала. И, по большей части, без участия человека — сложно в это поверить, особенно учитывая масштабы соцсети, но факт остается фактом.
Инженеры Instagram в своем техническом блоге рассказали о том, как создавали эту систему и налаживали ее безотказную работу. Мы представляем вашему вниманию главные мысли этой заметки.
Зачем все это нужно
У непрерывного развертывания есть несколько преимуществ:
- Непрерывное развертывание позволяет быстрее работать инженерам. Они не ограничены несколькими развертываниями за день в фиксированное время — вносить изменения по мере необходимости что экономит время.
- Непрерывное развертывание легче выявлять ошибки, которые вкрались в тот или иной коммит. Инженерам не приходится разом анализировать сотни изменений, чтобы найти причину новой ошибки, достаточно проанализировать два-три последних коммита. Метрики или данные, которые указывают на проблему, можно использовать для точного определения момента возникновения ошибки, а значит, сразу понятно, какие коммиты нужно проверить.
- Коммиты, содержащие ошибки можно быстро обнаружить и исправить, а значит код не превращается в кишащую «багами» массу, развернуть которую физически невозможно. Система всегда находится в таком состоянии, когда найти и поправить ошибку можно очень быстро.
Реализация
Успех итоговой реализации проекта во многом можно связать с итеративным подходом построения архитектуры. Система не создавалась отдельно с последующим переключением на нее, вместо этого инженеры Instagram развивали существующий процесс создания софта и работы с инфраструктурой до тех пор, пока не было реализовано непрерывное развертывание.
Что было раньше
До непрерывного развертывания, инженеры вносили изменения по мере их возникновения — если была реализована какая-то функция, которую хочется поскорее внедрить, то запускался процесс развертывания. При этом сначала развертывание происходило на тестовых серверах — на них «накатывались» обновления, затем изучались логи, и если все было хорошо, затем обновление разворачивалось уже на всю инфраструктур.
Всё это было реализовано в виде скрипта Fabric (библиотека и набор инструментов командной строки для развертывания и администрирования приложений на python), кроме того использовалась простейшая база данных и графический интерфейс “Sauron”, который хранил логи развертывания.
Тест с использованием «канареек»
Первым шагом было добавление теста с использованием «канареек» (групп конечных пользователей, которые могут не знать про участие в тесте), что изначально предполагало создание скриптов для автоматизации инжереных задач. Вместо запуска раздельного развертывания на одной машине, скрипт развертывается на машинах «канереек», записывает пользователськие логи, а затем запрашивает разрешение на дальнейшее развертывание. На следующем этапе осуществляется обработка собранных данных: скрипт анализирует HTTP-коды всех запросов и категоризирует их согласно заданному барьеру (например, менее 0,5% или как минимум 90%).
У инженеров Instagram был набор готовых тестов, однако, он запускался только сотрудниками ИТ-департамента на их рабочих машинах. А значит, рецензентам (тем, кто выполняет code review) при определение успешности или неуспешности теста приходилось верить коллегам на слово. Кроме того были неизвестны результаты теста при развертывании коммита на боевой системе.
Поэтому было решено установить систему интеграции Jenkins для запуска тестов новых изменений и создания отчетов для графического интерфейса Sauron. Этот инструмент был нужен для отслеживания последних успешно прошедших тесты коммитов — при необходимости, именно их система должна была предлагать вместо самого последнего коммита.
Для рефакторинга инженеры Facebook используют инструмент Phabricator и хорошо интегрирующуюся с ним систему Sandcastle. Их коллеги из Instagram также. воспользовались Sandcastle для запуска теста и получения отчетов.
Автоматизация
Перед началом проекта по автоматизации развертывания инженерам Instagram пришлось проделать кое-какую подготовительную работу. В частности, для каждого нового развертывания был добавлен статус (запущено, готово, ошибка) и реализованы оповещения, которые появлялись в случае, если предыдущее развертывание не имело статуса «готово». В графический интерфейс была добавлена кнопка для прерывания развертывания. Кроме того, было реализовано отслеживание всех изменени. В итоге, если раньше Sauron знал лишь о последнем удачно прошедшем тесте, то теперь все изменения боевой системы записывались, и был известен статус каждого из них.
Затем была проделана работа по автоматизации оставшихся решений, которые должен был принимать человек. Первым из них был выбор коммита, который должен быть развернут. Изначальный алгоритм всегда выбирал коммиты, которые удачно прошли тест, и выбирал как можно меньшее их количество — это число никогда не превышало трех. Если все коммиты прошли тест успешно, то каждый раз выбиралось новое изменение, кроме того могло быть не более двух последовательных изменений, не прошедших тестирование. Вторым было решение об успехе или провале прохождения развертывания. Если оно не прошло более чем на одном проценте хостов, то такое развертывание считалось не выполненным.
В такой конфигурации в процессе развертывания человеку приходилось несколько раз отвечать «да» в системном диалоге (прием коммита, запуск канареечного теста, старт полного развертывания) — это действие можно было автоматизировать. Послеэтого Jenkins научился запускать скрипт полного развертывания — конечно, на первом этапе эта его возможность использовалась только под присмотром инженеров.
Проблемы
При реализации непрерывного развертывания в Instagram до его текущего состояния не все шло гладко. Было несколько неполадок, над которыми инженерам пришлось поработать.
Ошибки тестирования
Прежде всего, часто бывало так, что в коммитах содержались ошибки, приводившие к сбоям тестов — а значит они не работали и для всех последующих коммитов. А это, в свою очередь, означало, что в таком случае ничего не могло быть развернуто. Чтобы исправить ошибку, нужно было сначала заметить неполадки, откатить проблемный коммит, подождать прохождения тестов для последнего успешного коммита, а затем вручную развернуть входящие в коммит изменения, прежде чем процесс сможет продолжиться в автоматическом режиме.
Все это сводило на нет главное преимущество непрерывного развертывания — развертывание малого количества коммитов за раз. Проблема заключалось в ненадежности и малой скорости отработки тестов. Чтобы сократить время их выполнения с 12-15 минут до 5 инженерам Instagram пришлось заняться оптимизацией производительности и исправлением ошибок в тестовой инфраструктуре, которые приводили к ее ненадежности.
Накопление очереди изменений
Несмотря на внедренные улучшения, все еще регулярно образовывалась очередь изменений, ждущих развертывания после ошибки. Основной причиной являлись ошибки, выявленные в ходе канареечных тестов (как положительные, так и ложноположительные), но возникали и другие неисправности. После исправления проблемы, система автоматизации выбирала по одному коммиту для развертывания — чтобы развернуть их все, нужно было время, за которое в очередь могли попасть и новые изменения.
Обычно в такой ситуации дежурный инженер мог вмешаться и развернуть всю очередь сразу — но это, опять же, нивелировло одно из главных достоинств непрерывного развертывания.
Для исправления этого недостатка был реализован алгоритм обработки очереди в логике выбора изменений, что позволило автоматически развертывать множество изменений при наличии очереди. Алгоритм основан на установке временного интервала, через который будет развертываться каждое изменение (30 минут). Для каждого изменения в очереди рассчитывается оставшийся интервал времени, число развертываний, которые можно провести в этот интервал, и число изменений, которые должны быть развернуты за раз. Выбирается максимальное отношение изменений к развертыванию, но оно ограничивается тремя. Это позволило инженерам Instagram проводить столько развертываний, сколько возможно при обеспечении развертывания каждого коммита за приемлемое время.
Одной из специфических причин возникновения очереди было замедление развертывания из-за возросшего размера инфраструктуры сервиса. К примеру, однажды инженеры обнаружили, что ядро было полностью загружено SSH-агентом, осуществлявшим SSH-аутентификацию соединений, и скриптом Fabric. Для решения этой проблемы агент был заменен на распределенную SSH-систему от Facebook.
Памятка по развертыванию от инженеров Instagram
Что нужно знать, чтобы осуществить подобный проект? Инженеры Instagram выделили несколько основных принципов, которые следует использовать для создания столь же эффективно работающих систем автоматического развертывания.
- Тесты. Набор тестов должен быть быстрым. Охват тестов также должен быть обширным, однако здесь не обязательно пытаться объять необъятное. Тесты должны часто запускаться: при оценке кода, перед применением изменений (в идеале блокируя реализацию при ошибке), после реализации изменений.
- Тесты с использованием «канареек». Необходим автоматизированный тест с использованием «канареек» для предотвращения развертывания действительно плохих коммитов на всей инфраструктуре. Опять же, перфекционизм здесь не обязателен, даже простого набора статистических метрик и пороговых значений будет достаточно.
- Автоматизация обычного сценария. Не надо автоматизировать все, достаточно лишь стандартных и простых ситуаций. Если происходит что-то необычное, следует остановить автоматическое исполнение, чтобы в ситуацию могли вмешаться люди.
- Людям должно быть удобно. Одним из самых больших препятствий, возникающих в ходе подобных проектов по автоматизации, является тот факт, что люди перестают понимать, что происходит в текущий момент времени, и лишаются возможности контроля. Для решения этой проблемы, система должна обеспечивать хорошее понимание того, что сделано, что делается, и (в идеале) будет сделано на следующем шаге. Так же необходим хорошо работающий механизм экстренной остановки автоматического развертывания.
- Стоит ждать плохих развертываний. Не стоит надеяться на то, что все развертывания будут проходить без проблем. Ошибок не избежать, но это нормально. Главное уметь быстро находить проблемы и «откатывать» изменения до работающей версии.
По мнению инженеров Instagram, реализовать подобный проект под силам ИТ-департаментам многих компаний. Система постоянного развертывания не обязательно должна быть сложной. Стоит начать с чего-то простого, сфокусировавшись на изложенных принципах, улучшая систему шаг за шагом.
Что инженеры Instagram планируют делать дальше
Сейчас система автоматического развертывания в Instagram работает без особенных нареканий, но еще остаются некоторые моменты, которые нужно будет улучшить.
- Поддержание скорости работы. Instagram быстро развивается, и частота внесения изменений также увеличивается. Инженерам необходимо поддерживать высокую скорость развертывания для сохранения малого количества реализуемых за раз изменений.
- Добавить больше «канареек». С ростом объёма вносимых изменений, растет и число ошибок на хостах канареек, а с очередью ожидающих изменений взаимодействуют все больше разработчиков. Инженерам требуется на раннем этапе «отлавливать» больше плохих коммитов и блокировать их развертывание — для этого осуществляется постоянная модификация процесса канареечного тестирования, в частности, его результаты проверяются с помощью «боевого» трафика.
- Повышение качества обнаружения ошибок. Кроме того, инженерная команда Instagram планирует снизить влияние плохих коммитов, которые не были обнаружены с помощью канареечного тестирования. Вместо тестирования на одной машине и разворачивания на всем парке машин, планируется добавить промежуточные этапы (кластеры и регионы), на каждом из которых все метриеи будут проверяться перед дальнейшим развертыванием.
Другие технические статьи от «Латеры»:
- Автоматизируем учет адресов и привязок в IPoE-сетях
- Работа с MySQL: как масштабировать хранилище данных в 20 раз за три недели
- DoS своими силами: К чему приводит бесконтрольный рост таблиц в базе данных
- Архитектура open source-приложений: Как работает nginx
- Как повысить отказоустойчивость биллинга: Опыт «Гидры»
«Роботы» атакуют финансовые рынки: Как софт заменит биржевых аналитиков на Уолл-стрит
В конце 2013 года академики из Оксфорда опубликовали исследование, в котором утверждалось, что 47% всех рабочих позиций в США находятся «в зоне высокого риска» автоматизации в течение ближайших 20 лет. Такие выводы спровоцировали целый шквал публикаций в прессе на тему того, как бездушные роботы отнимают рабочие места у людей.
Однако исследователи говорили не только о том, что работу могут потерять неквалифицированные работники, выполняющие несложные действия, к примеру, на фабриках или производстве. Теперь софт, использующий новые подходы вроде машинного обучения, может делать работу, которая всегда считалась прерогативой высокообразованных и высокооплачиваемых людей, которые не занимаются физическим трудом.
Согласно данным исследования, степень угрозы автоматизации для конкретных отраслей сильно различается — заменить живого доктора, общающегося с пациентом, еще очень долго будет нельзя (и не факт, что это вообще возможно). А вот клерков в юридических конторах, которые анализируют бумаги — вполне можно будет заменить.
Но больше всего, по мнению исследователей, стоит беспокоиться работникам сферы финансов. Ее высочайшая степень автоматизации и проникновения технологий уже сейчас ставит под угрозу до 54% рабочих позиций.
Софт, который знает все
В феврале этого года издание New York Times рассказывало историю разработчика аналитической системы Kensho Даниэль Надлер. Его система собирает и анализирует информацию, которая может повлиять на изменение положения дел на фондовом рынке — а затем генерирует рекомендации о совершении транзакций.
Раньше, когда крупный клиент инвестиционной компании звонил своему брокеру и спрашивал, к примеру, как на цену купленных им акций энергетических компаний может повлиять очередное обострение ситуации в нефтедобывающих районах, скажем Сирии, он мог получить ответ, основанный на личных впечатлениях брокера или тот мог позвать на помощь аналитика. Такие советы могли быть точными, но всегда существовал риск человеческой ошибки — сотрудник мог не учесть какой-то важны фактор.
Чтобы снизить вероятность ошибки в каждом конкретном случае нужно было проводить глубокое исследование похожих событий и того, как они влияли на рынок. Однако минус такого подхода заключался в том, что к тому моменту, как аналитики могли сформулировать инвестиционный совет, возможность для его применения уже могла давно быть упущена.
Теперь же компании вроде Goldman Sachs начинают использовать аналитические системы вроде Kensho. С их помощью можно вбить интересующий поисковый запрос (например — «Сирия»), и сразу увидеть выдачу событий, связанных с этой темой. Похоже на Google, который показывает контент в сети на основе поискового запроса.
Kensho все активнее используется в Goldman Sachs и создатель программы Надлер убежден, что аналитикам этой и многих других финансовых компаний стоит беспокоиться за свою будущее. Он прогнозирует, что в течение десяти лет от трети до половины сотрудников финансовых компаний на Уолл-стрит потеряют работу из-за Kensho и других подобных систем.
Сфера финансов уже проходила подобные трансформации — сначала работу потеряли клерки и брокеры, которые занимались продажей и покупкой акций по телефону. По данным источника NY Times в том же Goldman Sachs таких людей осталось всего четыре, а было около 600. Кроме того, многие трейдеры, которые сами совершали операции на рынке, ушли с него, уступив торговым роботам.
Теперь пришла очередь финансовых аналитиков — новый софт в состоянии изучить и проанализировать в разы больший объём данных за гораздо меньшее время. И надежность этого анализа также выше, считает Надлер. Он также убежден, что увольнений не избежать и сотрудникам финансовых компаний, которые работают с инвесторами — если те смогут общаться с умной аналитической системой, которая почти не ошибается, мало кто захочет тратить свое время на людей.
Несколько месяцев назад Энтони Дженкинс, который ранее был уволен с должности гендиректора крупнейшего британского банка Barclays выступал на конференции. Его выступление было посвящено «уберизации» финансовой индустрии, то есть влиянию на нее новых технологий.
«По моему прогнозу, число подразделений и работающих в финансовых компаний сотрудников в ближайшие годы может сократиться на 50%, — говорил он со сцены. И даже при более оптимистичном сценарии, как минимум 20% работников потеряют свои места из-за развития технологий».
Стремление к экономии
Одним из стимулов к внедрению инновационных аналитических инструментов может послужить желание сэкономить. В течение нескольких десятилетий распоряжение чужими финансами, на котором специализируются многие инвестиционные компании, было более чем прибыльным бизнесом. По данным консалтинговой компании BCG, рентабельность отрасли доверительного управления активами достигла 39% в 2014 году (для сравнения, рентабельность сферы продаж потребительских товаров в то же время не превышала 8%, а фармацевтики — 20%). Совокупная прибыль отрасли в 2014 году, по различным оценкам, составила $102 млрд. Кроме того, индустрия управления чужими финансами растет быстрыми темпами: сейчас компании «присматривают» за $ 78 трлн по всему миру, а к 2020-ому эта цифра может дорасти и до $ 100 трлн.
Все это привело, в частности, к тому, что финансовые компани и управляющие активами запрашивали все более высокие комиссионные со своих клиентов. Пока рынки растут, клиенты могут не замечать влияния комиссионных сборов на итоговую прибыль, и доходам управляющих активами ничто не угрожает. Но в минувшем году большинство рынков существенно снижало темпы роста или падало.
Консалтинговая компания McKinsey сообщила, что в 2015 году снизились темпы роста и уровень прибыли многих американских фирм, предоставляющих услуги управления активами. Morningstar сообщает, что в 2015 году активные менеджеры столкнулись с «оттоком» более чем $ 100 млрд управляемого капитала. Еще $400 млрд были переведены под «пассивное» управление, которое предполагает отслеживание фондовых индексов и вложение средств в них. Впрочем, это не помогло тем, кто вложился в ценные бумаги суверенных фондов стран, экспортирующих природные ресурсы. Компенсировать потерянный доход после обвала общемировых цен на сырье практически невозможно. Тяжело пришлось и фирмам, специализирующимся на рынке акций: Aberdeen Asset Management, один из крупнейших инвестиционных фондов Европы, потерял 14% управляемых средств, Ashmore Group — 19%.
Внедрение новых технологий позволяет воспроизвести стратегии управления финансами при гораздо меньших затратах. В настоящий момент программы способны заменить к примеру, тех управляющих, которые пытаются «обыграть» рынок, покупая дешевые акции с высокой предполагаемой доходностью. Компьютерная программа куда быстрее анализирует рынок акций, которые выглядят дешевыми по отношению к прибыли выпустивешй их компании компании, стоимости ее активов или выплачиваемых ею дивидендов. Кроме того, система может использовать в торговле не только акции, но и к примеру, так называемые структурированные продукты. У инвесторов больше не будет необходимости беспокоиться о том, что управляющий или аналитики инвесткомпании могут просмотреть что-то или действовать не согласно утвержденной стратегии.
В случае выбора между рынками активов, робо-консультант, опираясь на компьютерные вычислительные модели, также сможет помочь инвесторам управлять своим капиталом, и за очень низкую плату.
Перспективы
Инвестиции в технологические разработки в сфере финансов («финтех») утроились в период с 2013 по 2014 год, составив $12,2 млрд. Новые стартапы работают над оптимизацией каждого звена всей финансовой системы. С помощью специального софта банки принимают решение о том, выдавать ли потенциальному заемщику кредит, страховые компании предлагают тарифы на основе данных о стиле вождения, собранных специальными средствами, а так называемые робо-советники помогают инвесторам формировать портфолио ценных бумаг — каждый такон инновационный рывок оставляет без работы какое-то количество квалифицированных сотрудников.
И тот факт, что пользователем технологий, вроде Kensho, стал Goldman Sachs, говорит о многом, считает создатель Kensho. Если такая консервативная и в чем-то неповоротливая компания, как Goldman, готова довериться софту и отказатсья от многих сотрудников, то работники не столь крупных финансовых компаний могут потерять свои места еще быстрее.
Другие материалы по теме от ITinvest:
- Можно ли создать алгоритм для торговли на бирже с помощью анализа тональности сообщений в интернете
- Как определить наилучшее время для сделки на фондовом рынке: Алгоритмы следования тренду
- ИБ-стартап Palantir поможет инвестбанку Credit Suisse создать систему для выявления недобросовестных трейдеров
- Эксперимент: Использование Google Trends для прогнозирования обвалов фондового рынка
- Эксперимент: создание алгоритма для прогнозирования поведения фондовых индексов
Комментарии (0)
Security Week 18: VirusTotal за справедливость, уязвимость в Android, утечка токенов Slack
Почему это важно? Изначально VirusTotal был проектом для исследователей: определить, детектируют ли защитные решения определенный файл — означало сэкономить время и потратить его на более интересные вещи. По мере роста сервиса появились и новые возможности: информация о том, когда был загружен файла иногда также могла многое подсказать о его предназначении и происхождении (особенно, если файл загружался пострадавшим пользователем, а то и самим автором вредоносной программы). Сейчас через VirusTotal проходят миллионы файлов: за последние семь дней 1,2 млн, из которых 400 тысяч задетектированы одним или несколькими антивирусными движками.
Короче, если есть доступ к этой информации, то только на ее основе можно создать свое, достаточно неплохо работающее типа защитное решение. Или, как минимум, получить несправедливое преимущество, получая от индустрии данные, но не отдавая ничего обратно. Not anymore. В посте VT приводится интересный набор правил использования сервиса, где его создателями критикуется пара устоявшихся мифов. Подробнее о них — под катом.
Все выпуски дайджеста доступны по тегу.
Начнем с самого жирного намека: «VirusTotal не может быть использован в качестве замены антивирусному решению». Дальше подробнее: данные VirusTotal (как участвующие в проекте вендоры детектируют файлы) не должны использоваться в качестве единственного критерия оценки для создания сигнатур. Еще важнее: VirusTotal не должен использоваться для сравнения эффективности защитных решений. Данный сервис сфокусирован именно на работе антивирусных движков. Его создатели прямо говорят, что правильные защитные решения антивирусным движком не ограничиваются — то есть если VirusTotal показывает, что антивирус такой-то не детектирует конкретный файл, это вовсе не значит, что решение не сможет заблокировать угрозу.
Наконец, для получения данных из VirusTotal претенденты должны не только предоставить свой антивирусный движок, но и активно участвовать в независимых тестированиях по стандартам AMTSO. Данную практику поддерживает практически вся индустрия защитных решений, за исключением компаний, которые по каким-то причинам не хотят публиковать результаты сравнения эффективности своих решений. Ну понятно по каким. В общем, это такая важная производственная новость. VirusTotal оказался одной из точек обмена данными между конкурирующими друг с другом компаниями. Такой обмен очень ценен, и нововведения в сервисе исправляют небольшой перекос в его работе, по сути исключая возможность пользоваться информацией, не отдавая ничего взамен.
В Slack обнаружили амазоноподобную прореху в безопасности
Новость. Исследование.
Slack — популярная платформа для группового общения, которую используют многие компании, включая самые крупные. Помимо разнообразной функциональности для коллективных чатов, сервис позволяет подключать «ботов» — как готовых, так и написанных клиентом самостоятельно. Боты значительно расширяют возможности Slack, добавляя в него и самые тривиальные опции вроде импорта RSS и сложную функциональность — выключить сервер, оповестить сотрудников о сбое в сервисе, сообщить погоду за окном.
«Уязвимость», обнаруженная исследователями компании Detectify Labs, оказалась тривиальнейшей. Код некоторых ботов выкладывается на GitHub, и в этом коде можно найти токен для доступа к рабочей среде группы пользователей или компании. Как оказалось, токен дает доступ практически ко всей информации внутри группы: чатам, файлам и так далее. В общем, неоднократно описанные грабли, например, с выкладыванием ключей к машинам в Amazon EC2, по-прежнему пользуются популярностью.
В Slack вполне резонно отреагировали на находку в стиле «это не баг, это фича», и это действительно так. Не всем ботам нужно давать полный доступ, но некоторым — необходимо, и ничего тут не поделаешь. Компания в результате провела свой собственный аудит кода на GitHub и разослала сообщения всем проштрафившимся. Вывод тут понятен: хардкодить ключи — это очень, очень плохо. Интересен во всей истории и такой момент: какими бы суровыми не были меры безопасности внутри периметра компании, такие сервисы как Slack, оказываются вне его, и огромный поток крайне чувствительных данных выходит из-под контроля. И ведь даже запрещать не поможет: внутрикорпоративные защищенные сервисы очень часто вчистую проигрывают публичным по удобству.
Очередная уязвимость в Android позволяет по-тихому протащить эксплойт в легитимном приложении
Новость. Исследование.
Компания FireEye рапортует о новой серьезной уязвимости, обнаруженной в различных версиях Android, от 2.3 до 5.0, хотя наибольшей опасности подвергаются смартфоны и планшеты с Android 4.3 и более ранними версиями — то есть как раз те, которые скорее всего никто обновлять не будет. Уязвимость, если коротко, позволяет обойти ограничения системы на доступ к данным и через одно место (конкретнее, через сетевой демон) украсть, скажем, информацию об SMS.
Судя по всему, уязвимость была занесена в кодовую базу Android Open Source Project компанией Qualcomm (она же предоставила патч), поэтому и подвержены в первую очередь устройства на базе железа от этого производителя. Но не обязательно: код сетевого демона netd (ранее network_manager) открыт и может использоваться кем угодно. В общем, дыра оказалась так выгодно расположена, что воспользоваться ей может любое приложение, запрашивающее доступ к сети, то есть каждое первое. В результате вредоносное приложение (или легитимное, но с дополнительной «фичей») может получить те же права доступа к данным, что и системный пользователь «radio». Именно поэтому начиная с Android 4.4 шансов добыть полезную информацию таким способом немного: безопасность была усилена, а права сетевых процессов (включая netd) урезаны.
Случаев эксплуатации уязвимости пока не замечено: к счастью, большинство дыр в Android пока только намекают на то, что надо что-то делать с фрагментацией платформы. Но ничего позитивного в этом направлении не происходит: по сути регулярные security-апдейты получают только «собственные» устройства Nexus. К статье об уязвимости в ArsTechnica есть один показательный комментарий по этому поводу: пока на платформе Android не случится массовое заражение а-ля эпидемия Slammer на Windows, ничего и не поменяется. Хочется надеяться, что до этого не дойдет.
Зато вирусописатели, как всегда, в авангарде прогресса: очередной крадущий данные троян распространяется под видом системного апдейта для Android.
Что еще произошло:
Две очень серьезные уязвимости в OpenSSL.
Закрыта большая дыра в Office 365.
Древности:
Семейство «Anti-Pascal»
Семейство из пяти очень опасных нерезидентных вирусов. Заражают или портят не более двух файлов во всех каталогах на текущем диске и диске C:. При поиске незараженных файлов используется рекурсивный обход дерева каталогов. Заражают .COM-, .BAK- и .PAS- файлы. В случае .COM-файла вирус записывается в его конец (версии вируса длин 400, 440 и 480) или начало (оставшиеся версии вируса). При заражении .BAK- и .PAS-файлов записывается в начало файла, при этом старое начало не сохраняется, т. е. файл оказывается безвозвратно потерян. Некоторые версии вируса переименовывают .BAK- и .PAS-файлы в .EXE.
Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 24.
Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Комментарии (0)
Дайджест новостей из мира разработки на Unity
Новости
Unity Technologies собираются привлечь инвестиции в размере $1,5 млрд.
Google Cardboard VR получат поддержку Unity.
Valve и Unity Technologies объединяют усилия в VR.
Покупатели Oculus Rift получат Unity Pro бесплатно на 4 месяца.
Вышел плагин Twitter Fabric для Unity.
Unity вводят программу сертифицирования для разработчиков.
Unity Technologies объявили о множестве изменений в ведении бизнеса.
Unity: 578 игр в секунду и 1.1 миллиона разработчиков.
Unity Asset Store объявляют о новой партнерской программе.
Unity 3D назвали самым популярным движком на игровом рынке.
Unity и Source 2 бесплатны (почти).
Релиз Unity 5.3.4 и публичной бета-версии 5.4.
Игры на Unity
Постмортем игры Prune.
Совершенно новый игровой опыт в Palimpseste.
Необычный контроллер в Crank Tank.
Игра-конструктор от Fabulous Beasts.
История разработки игры Armello от League of Geeks.
Игра, в которую можно играть при помощи старого проводного телефона и ЭЛТ-телевизора.
Необычная игра Progress to 100 для девайсов на iOS.
GNOG – игра об изучении гигантских монстров и их внутреннего мира (в буквальном смысле).
Please Stand By поселилась в телевизоре 1951 года выпуска.
Контроллер игры Ziff – игрушка с подвижными элементами.
Игра Operator от Killigan Industrie.
Игра Octobo – интерактивный сборник рассказов с плюшевой игрушкой осьминогом, реагирующей на действия игрока.
Disruption – две игры с уникальным симбиотическим взаимодействием, которое возможно благодаря необычному контроллеру.
Игра Rotator – мечта диджея.
Забавная игра Terence Tolman от Pretty Fox Games.
В Dobotone от Videogamo можно играть на двухкнопочных контроллерах с четырьмя друзьями.
Консольная версия Gone Home.
Стратегия «Османские войны» на Unity Engine.
Релиз Unity-клиента Master of Orion под Mac OS X.
Создание космического симулятора на Unity.
Обучение
Более детально о камере в Unity3D.
Как создать 3D алгоритмы при помощи Unity3D.
Шифрование текста в Unity.
Как написать скрипт 2D Tile Map в Unity3D.
Комбинирование камеры проекции и ортографической камеры для создания эффекта параллакса в 2D игре.
Создавайте собственные инструменты в редакторе Unity.
Unity и инструменты редактора.
Производительность Critical Editor Tools и сериализованных объектов.
Интерполяция сетевых объектов, часть 1 из 6 – разбиваем на компоненты.
Старт в разработку на Unity 5 от Microsoft.
Нюансы разработки плагина под Unity.
Unity и «Помогаторы» для редактора.
Hrushevka Builder для Unity.
Процедурно генерируемые карты мира на Unity C#: часть 2, часть 3, часть 4.
Это интересно
Почему Unity – лучший выбор для разработки приложений виртуальной реальности.
Клайв Дауни, директор по маркетингу в Unity: «Опустите слово виртуальная, это будет другая реальность».
Короткий ролик от Unity демонстрирует возможности движка.
Инструменты Unity, которые использовались для создания шутера от первого лица Immortal Redneck.
Движение от Next-Gen UI к Unity UI.
Портирование игры на Unity на Samsung Gear VR.
Как небольшая команда разработчиков использовала алгоритмическую генерацию контента для создания шутера с открытым миром от первого лица.
Презентация Unity на GDC 2016.
Использование плагинов Unity для разработки игры Mimpi Dreams.
Испытания и технические триумфы в разработке игры Return of the Obra Dinn.
Разработчики игры Limbo выложили код своей технологии сглаживания на Unity 5 в открытый доступ.
White Nights Helsinki 2016: доклад Unity о работе с данными.
Как зарабатывать на мобильных играх с Unity Engine и Unity Ads.
Интервью с дизайнером и саунд-дизайнером из Speelbaars об игре Lumini.
Сэм Барлоу о разработке игры Her Story.
Интервью с креативным директором Zachtronics об игре Infinifactory.
Комментарии (0)