/tech/ - technology

github и gitlab увольняют часть сотрудников


github увольняет 10%
https://techcrunch.com/2023/02/09/github-lays-off-10-and-goes-fully-remote/

gitlab увольняет 7%
https://about.gitlab.com/blog/2023/02/09/gitlab-news/


https://www.opennet.ru/opennews/art.shtml?num=58635

получили доступ к кодам реддита

What Happened?

On late (PST) February 5, 2023, we became aware of a sophisticated phishing campaign that targeted Reddit employees. As in most phishing campaigns, the attacker sent out plausible-sounding prompts pointing employees to a website that cloned the behavior of our intranet gateway, in an attempt to steal credentials and second-factor tokens.

After successfully obtaining a single employee’s credentials, the attacker gained access to some internal docs, code, as well as some internal dashboards and business systems. We show no indications of breach of our primary production systems (the parts of our stack that run Reddit and store the majority of our data).

Exposure included limited contact information for (currently hundreds of) company contacts and employees (current and former), as well as limited advertiser information. Based on several days of initial investigation by security, engineering, and data science (and friends!), we have no evidence to suggest that any of your non-public data has been accessed, or that Reddit’s information has been published or distributed online.

https://www.reddit.com/r/reddit/comments/10y427y/we_had_a_security_incident_heres_what_we_know/

godaddy обнаружил у себя утечку исходников, установленные системы слежения и всякое другое

прикольно у них

https://www.bleepingcomputer.com/news/security/godaddy-hackers-stole-source-code-installed-malware-in-multi-year-breach/

Издательский концерн Axel Springer проводит реструктуризацию, в ходе которой часть журналистов будет уволена и заменена чат-ботом ChatGPT. Сокращения коснутся двух немецких изданий: Die Welt и Bild. Об этом в письме сотрудникам заявил генеральный директор Axel Springer Матиас Дёпфнер.

Axel Springer – один из крупнейших европейских издательских и медиаконцернов, выпускающий свыше 150 наименований газет и журналов в более чем 32 странах, включая Германию, Францию, Испанию, Россию, Швейцарию, Чехию и т.д.

«Искусственный интеллект может сделать независимую журналистику лучше, чем когда-либо, или просто заменить её», — заявил Дёпфнер.

По его словам, ИИ-инструменты могут «совершить революцию» в области СМИ и скоро будут агрегировать информацию лучше, чем профессиональные журналисты. Дёпфнер считает, что в таких условиях выживут только те, кто способен предоставить аудитории уникальную информацию.

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

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

Сотрудники Die Welt и Bild не единственные, кто подвергся сокращению. После увольнения 12% своих сотрудников онлайн-издатель BuzzFeed, известный своими статьями о поп-культуре, викторинами и статьями-заметками, объявил, что начнет использовать ChatGPT для создания контента и индивидуальных квизов.

GitHub принудительно и без предварительного предупреждения перевёл репозитории проекта IPMI Tool в архивный режим, допускающий доступ только в режиме чтения. Также в режим только для чтения переведены все репозитории Александра Амелькина, сопровождающего ipmitool. Пакет ipmitool входит в состав RHEL, SUSE, Debian и других дистрибутивов Linux и является наиболее распространённым открытым инструментарием командной строки для управления, мониторинга и настройки серверов с BMC-контроллерами, поддерживающими стандарт IPMI (Intelligent Platform Management Interface).

Ограничение введено без пояснения причин, но по неофициальной информации причиной введённых ограничений стало то, что Александр трудоустроен в компании Yadro, которая в конце февраля была включена в блокирующий санкционный список США. Все GitHub-репозитории с открытыми проектами данной компании, а также репозитории сотрудников переведены в режим только для чтения. 

https://www.opennet.ru/opennews/art.shtml?num=58789

Цукерберг уволит 10000 человек и закроет 5000 открытых вакансий


“Overall, we expect to reduce our team size by around 10,000 people and to close around 5,000 additional open roles that we haven’t yet hired,” Zuckerberg wrote in the memo

https://variety.com/2023/digital/news/meta-layoffs-10000-more-employees-mark-zuckerberg-1235553578/

Вечером пятницы 23 сентября, в самое «горячее» время для Додо Пиццы, развалилась платформа Dodo IS. Приём заказов превратился в тыкву, клиенты и пиццерии 4 часа испытывали проблемы. Это было наше самое крупное падение с 2018-го года как в техническом плане, так и по недополученной выручке.

Особенная боль — то, что мы упали в прайм-тайм. Наш бизнес устроен циклично и зависит от сезона: осенью заказов больше, чем летом, а по вечерам пятницы больше в несколько раз, чем утром вторника, обычно пик заказов приходится на вечер пятницы (с 16 до 20 по Москве). Это время — самое напряжённое для системы и самое ценное для бизнеса.

У Dodo IS произошёл каскадный сбой и мы долго не могли реанимировать систему. Описываем наш путь во время этого инцидента:

    Накинем ресурсов и все полетит?

    Рассылка от маркетинга пушей в самый пик — может, дело в этом?

    Наверняка это DDoS.

    Или плохой релиз, вышедший недавно?

    Короче, это что-то с базой.

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

Хронология событий и гипотезы
Первые алерты: ничего критичного, просто растёт нагрузка

Это была обычная пятница. Заказы принимались, алертов, которые говорили бы о сбоях системы, не было. В 16-52 прилетел алерт от MySQL о том, что много активных тредов.

График поступающих заказов — это важный индикатор реальной работы системы. Если заказы совсем перестают поступать, т.е. падают в 0 по какому-то источнику, то для пользователя это выглядит по-разному: может не открываться приложение, заказ может добавляться в корзину, но не приниматься. Т.е. не проходит ключевой сценарий — заказать пиццу не получается.


дальше по ссылке: https://habr.com/ru/company/dododev/blog/703052/

>>42

из комментов

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

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

Джун, ему простительно, реализовал прекрасно: на каждый (ты вдруг VIP'ом стал внезапно) got/lost focus элемента формы проверка через select * from vip, дальше поиск по массиву уже на клиенте...

В форме, центральной, было несколько десятков закладок, пара сотен статических и, в зависимости от, еще минимум сотня динамических элементов. А в момент открытия формы, как мы потом узнали, каждый (!) элемент генерил эти 2 события. И в понедельник утром > 5 тыс. ничего не подозревающих пользователей пришли на работу. И не могли открыть форму, приложение "висело", они его срубали и открывали заново. Восточные регионы успели, а следующие часовые пояса уже нет, что внесло свои коррективы в понимание проблемы. Мы докидывали сервера приложений, которые принимались переваривать все новые сессии пользователей, а старые никуда не девались, пока не дорабатывали до конца или мы не перегружали сервак. Между БД и серверами приложений гнался немеренный траффик. К БД было подключено несколько десятков и других приложений, и там тоже началась деградация.

Тем, кто не очень в теме БД, простой select из базы в таком виде грубо: declare stmt/open cursor/fetch 200+ rows/close cursor, каждое действие это несколько пакетов, каждый фетч страница в 4Кб, умноженное на число строк в таблице - 200+ и умноженное на 2*300 раз за контрол на форме на каждого пользователя=5000 и каждую зависшую сессию - умножить еще на 2. И все это в единицу времени. "Ватага зайцев мочит льва."

Мы ddos-или собственную инфру. И самое главное, не понимали причину, поднимали новые сервера => создавали все новую нагрузку, положили сеть. Снять дампы или включить детальный мониторинг было нереально. А причину, без инструмента и исходных данных, искали, как вы понимаете, теоретически, в последних-предпоследних-предпредпоследних изменениях. Судорожные откаты к результату не приводили, управлять пользователям мы в тот момент не умели. А про крыж в настройках никто не подумал, потому что дата файла с этими настройками из репозитория (феншуй епрст!) оказалась, как можно догадаться, 2-х месячной давности.

Как DBA отвечу:

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

Графики нагрузки на продуктивные БД имели историю, анализ, с указанием причин изменений ключевых показателей, объяснения динамики и "красные линии", с историчностью в несколько лет и разбирались на еженедельной основе вместе с разрабами. И с точки зрения написанного кода, и бизнес-показателей, внедрения новых фич и тп. Не говоря уже про даш-борды и алерты для группы онлайн-мониторинга 24х7.

"Можно придумать защиту от дурака, но только неизобретательного" ИТ-шная мудрость

Якуб Кичиньский (Jakub Kicinski), мэйнтейнер сетевой подсистемы ядра Linux, отказался принимать патчи от Сергея Сёмина, мотивируя свои действия тем, что он чувствует себя некомфортно, принимая изменения от сотрудников Baikal Electronics или для оборудования данной компании (компания находится под международными санкциями). В патчах для сетевого драйвера STMMAC была реализована поддержка процессора Baikal, а также предложены общие исправления. Сергею рекомендовано воздержаться от участия в разработке сетевой подсистемы ядра Linux до получения уведомления.

Поддержка российского процессора Baikal-T1 и основанной на нём системы на кристалле BE-T1000 включена в ядро Linux начиная с ветки 5.8. Процессор Baikal-Т1 содержит два суперскалярных ядра P5600 MIPS 32 r5, работающих на частоте 1.2 ГГц. Чип содержит кэш L2 (1 Мб), контроллер памяти DDR3-1600 ECC, 1 порт 10Gb Ethernet, 2 порта 1Gb Ethernet, контроллер PCIe Gen.3 х4, 2 порта SATA 3.0, USB 2.0, GPIO, UART, SPI, I2C. Процессор предоставляет аппаратную поддержку виртуализации, инструкции SIMD и интегрированный аппаратный ускоритель криптографических операций, поддерживающий ГОСТ 28147-89. Чип разработан с использованием лицензированного у компании Imagination Technologies блока процессорного ядра MIPS32 P5600 Warrior. 

https://lore.kernel.org/all/[email protected]/

 After a strategic review, Amazon intends to lay off 9,000 more employees — on top of the 18,000 job cuts it previously announced, CEO Andy Jassy said Monday.

The latest round of cuts will mostly affect employees in Amazon Web Services (AWS), People, Experience and Technology (PXT), advertising and Twitch divisions, according to Jassy. The company’s senior management team expects to make final decisions on which jobs will be eliminated by “mid to late April,” the CEO said.

“This was a difficult decision, but one that we think is best for the company long term,” Jassy wrote.

The announcement of layoffs at Twitch follows CEO Emmett Shear’s resignation last week from the post after 16 years at the livestreaming platform.

Jassy said economic “uncertainty” drove the decision to make the latest round of layoffs after several years of Amazon businesses adding “a significant amount of headcount.” As of Dec. 31, 2022, the ecommerce giant had about 1.541 million full-time and part-time employees, up nearly 19% compared with 1.298 million a year prior.

“For several years leading up to this one, most of our businesses added a significant amount of headcount,” Jassy wrote in the memo, which Amazon shared publicly. “This made sense given what was happening in our businesses and the economy as a whole. However, given the uncertain economy in which we reside, and the uncertainty that exists in the near future, we have chosen to be more streamlined in our costs and headcount.”

Even with the additional cuts, Amazon will engage in “limited hiring” in “strategic areas where we’ve prioritized allocating more resources,” Jassy said, without elaborating.

For the fourth quarter of 2022, Amazon sales were up 9% year over year while net income came in at $278 million (compared with $14.3 billion a year earlier) on higher costs and charges, including $640 million in severance-related expenses. For the first quarter of 2023, Amazon expects sales to grow between 4% and 8% compared with the year-earlier period, in-line with Wall Street forecasts. CFO Brian Olsavsky last month said Amazon anticipates slower growth rates “for the next few quarters.”


https://variety.com/2023/digital/news/amazon-layoffs-9000-employees-twitch-aws-1235559365/

Оуэн Тейлор (Owen Taylor), создатель GNOME Shell и библиотеки Pango, входящий в рабочую группу по развитию Fedora для рабочих станций, выставил на обсуждение план шифрования по умолчанию системных разделов и домашних каталогов пользователей в Fedora Workstation. Из плюсов перехода к шифрованию по умолчанию называется защита данных в случае кражи ноутбука, защита от атак на оставленные без присмотра устройства, поддержание конфиденциальности и целостности из коробки без необходимости совершения лишних манипуляций.

В соответствии с подготовленным черновым планом для шифрования планируют использовать Btrfs fscrypt. Для системных разделов ключи шифрования планируют хранить в TPM-модуле и использовать в привязке к цифровым подписям, применяемым для проверки целостности загрузчика, ядра и initrd (т.е. на этапе загрузки системы пользователю не нужно будет вводить пароль для расшифровки системных разделов). При шифровании домашних каталогов ключи планируют генерировать на основе логина и пароля пользователя (подключение зашифрованного домашнего каталога будет производиться во время входа пользователя в систему).

Сроки реализации инициативы зависят от перехода дистрибутива на унифицированный образ ядра UKI (Unified Kernel Image), объединяющий в одном файле обработчик для загрузки ядра из UEFI (UEFI boot stub), образ ядра Linux и загружаемое в память системное окружение initrd. Без поддержки UKI невозможно гарантировать неизменность содержимого окружения initrd, в котором осуществляется определение ключей для расшифровки ФС (например, атакующий может подменить initrd и симулировать запрос пароля, чтобы этого избежать требуется верифицированная загрузка всей цепочки до монтирования ФС).

В текущем виде в инсталляторе Fedora имеется опция для шифрования разделов на блочном уровне при помощи dm-crypt, используя отдельную парольную фразу, не привязанную к учётной записи пользователя. В данном решении отмечаются такие проблемы, как непригодность для раздельного шифрования в многопользовательских системах, отсутствие поддержки интернационализации и средств для людей с ограниченными возможностями, возможность совершения атак через подмену загрузчика (установленный атакующим загрузчик может притвориться оригинальным загрузчиком и запросить пароль расшифровки), необходимость поддержки framebuffer в initrd для вывода запроса пароля.

https://www.opennet.ru/opennews/art.shtml?num=58916
https://lists.fedoraproject.org/archives/list/[email protected]/thread/LYUABL7F2DENO7YIYVD6TRYLWBMF2CFI/

Директор компании Red Hat объявил во внутренней корпоративной рассылке о грядущем сокращении сотен рабочих мест. В настоящее время в головном офисе Red Hat трудоустроено 2200 сотрудников и ещё 19000 работает в отделениях по всему миру. Точное число сокращаемых рабочих мест не уточняется, известно только то, что увольнения будут проведены в несколько этапов и не затронут сотрудников, вовлечённых в создание продуктов и прямые продажи клиентам.

Cокращению персонала способствуют негативные прогнозы относительно предстоящей прибыли. Например, в последнем квартале доход Rad Hat вырос на 8%, что воспринимается как замедление роста, так как с 2019 года компания демонстрировала рост в среднем на уровне 15%.

Дополнительно можно отметить, что в начале года корпорация IBM, которая владеет Red Hat, анонсировала увольнение 3900 сотрудников, но затем появились сведения об увеличении числа увольнений до 5000. С учётом, что за несколько месяцев до этого в IBM было нанято 7000 новых работников, некоторые аналитики объясняют увольнения избавлением от избыточного персонала, нанятого из-за нехватки рабочей силы в момент роста экономической активности после пандемии. 

https://www.opennet.ru/opennews/art.shtml?num=59027
https://news.ycombinator.com/item?id=35687687

Cloud storage giant Dropbox today joined the fray of tech companies announcing layoffs. The company today announced that it would be laying off 16% of its staff, equivalent to about 500 employees, due to slowing growth, and — in the words of CEO Drew Houston — because “the AI era of computing has finally arrived.”

These appear to be the first layoffs the company has made since January 2021, when it laid off 315 employees in the throes of the COVID-19 pandemic.

The latest cull was announced to staff in a memo from CEO and co-founder Drew Houston, as well as in an SEC filing.

The SEC filing noted that the company will incur charges of approximately $37 million to $42 million in connection with layoffs, which will be recorded in Q2. Q1 results, which will be reported next Thursday, May 4, will be in-line or even above expectations, it added.

Ironically, even with the strong results, and the fact that Dropbox is profitable, Houston said the company is choosing to take a preemptive step to cut jobs and invest in new areas to keep up with the pace of change, given that growth is slowing.

“While our business is profitable, our growth has been slowing. Part of this is due to the natural maturation of our existing businesses, but more recently, headwinds from the economic downturn have put pressure on our customers and, in turn, on our business. As a result, some investments that used to deliver positive returns are no longer sustainable,” he wrote.

The interesting thing is that he also cites AI as a major factor.

“Second, and more consequentially, the AI era of computing has finally arrived,” he continued. “We’ve believed for many years that AI will give us new superpowers and completely transform knowledge work. And we’ve been building towards this future for a long time, as this year’s product pipeline will demonstrate.”

For those who have been warning that AI will inevitably lead to the loss of more jobs, this will come as an alarming development. The more cynical might argue that it’s an easy and timely excuse for cutting costs right now, to keep the market and investors optimistic that Dropbox is changing with the times and itself won’t get disrupted in the next wave of innovation.

Houston said that impacted staff will be getting notified today and will be finished with work by tomorrow. The company had 3,125 employees prior to the move today.

More than 184,000 people have been laid off in the tech sector in 2023 across nearly 620 tech companies, according to the Layoffs.fyi tracker.

More to come.

https://techcrunch.com/2023/04/27/dropbox-lays-off-500-employees-16-of-staff-ceo-says-due-to-slowing-growth-and-the-era-of-ai/

Starting today, you can create and use passkeys on your personal Google Account. When you do, Google will not ask for your password or 2-Step Verification (2SV) when you sign in.

Passkeys are a more convenient and safer alternative to passwords. They work on all major platforms and browsers, and allow users to sign in by unlocking their computer or mobile device with their fingerprint, face recognition or a local PIN.

Using passwords puts a lot of responsibility on users. Choosing strong passwords and remembering them across various accounts can be hard. In addition, even the most savvy users are often misled into giving them up during phishing attempts. 2SV (2FA/MFA) helps, but again puts strain on the user with additional, unwanted friction and still doesn’t fully protect against phishing attacks and targeted attacks like "SIM swaps" for SMS verification. Passkeys help address all these issues.

https://security.googleblog.com/2023/05/so-long-passwords-thanks-for-all-phish.html

Леннарт Поттеринг рассказал о подготовке к добавлению в системный менеджер systemd режима мягкой перезагрузки ("systemctl soft-reboot"), который приводит к перезапуску только компонентов пространства пользователя, не трогая ядро Linux. Предполагается, что по сравнению с обычной перезагрузкой мягкая перезагрузка сократит время простоя во время обновления окружений, использующих готовые системные образы.

Новый режим позволит завершить работу всех процессов в пространстве пользователя, после чего заменить образ корневой ФС на новую версию и запустить процесс инициализации системы, не перезагружая ядро. Кроме того, сохранение состояния работающего ядра при замене пользовательского окружения даст возможность реализовать обновление некоторых сервисов в live-режиме, организовав передачу файловых дескрипторов и слушающих сетевых сокетов для этих сервисов из старого окружения в новое. Таким образом, можно будет существенно сократить время замены одной версии системы на другую и обеспечить бесшовную передачу ресурсов наиболее важным сервисам, которые продолжат работать без остановки.

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

https://www.opennet.ru/opennews/art.shtml?num=59099
https://mastodon.social/@pid_eins/110272799283345055

Раскрыты сведения о неисправленной (0-day) уязвимости (CVE-2023-2156) в ядре Linux, позволяющей остановить работу системы через отправку специально оформленных пакетов IPv6 (packet-of-death). Проблема проявляется только при включении поддержки протокола RPL (Routing Protocol for Low-Power and Lossy Networks), который в дистрибутивах по умолчанию отключён и применяется, главным образом, на встраиваемых устройствах, работающих в беспроводных сетях с большой потерей пакетов.

Уязвимость вызвана некорректной обработкой внешних данных в коде разбора протокола RPL, которая приводит к срабатыванию assert-сбоя и переходу ядра в состояние panic. При размещении в структуре k_buff (Socket Buffer) данных, полученных в результате разбора заголовка пакета IPv6 RPL, если поле CmprI выставлено в значение 15, поле Segleft в 1, а CmprE в 0, 48-байтный вектор с адресами распаковывается до 528 байт и возникает ситуация, когда выделенной для буфера памяти оказывается недостаточно. В этом случае в функции skb_push, применяемой для помещения данных в структуру, срабатывает проверка на несоразмерность размера данных и буфера, генерирующая состояние panic, чтобы предотвратить запись за границу буфера. 

Примечательно, что разработчики ядра были уведомлены об уязвимости ещё в январе 2022 года и за прошедшие 15 месяцев три раза попытались устранить проблему, выпустив патчи в сентябре 2022 , октябре 2022 и апреле 2023 года, но каждый раз исправлений оказывалось недостаточно и уязвимость удавалось воспроизвести. В конечном счёте проект ZDI, координировавший работу по устранению уязвимости, принял решение раскрыть детальную информацию об уязвимости, не дожидаясь появления работающего исправления в ядре.

Таким образом уязвимость до сих пор остаётся неисправленной. В том числе не эффективен патч, вошедший в ядро 6.4-rc2. Пользователям рекомендуется проверить, что протокол RPL в их системах не используется, что можно сделать при помощи команды


sysctl -a | grep -i rpl_seg_enabled

https://www.opennet.ru/opennews/art.shtml?num=59146
https://www.interruptlabs.co.uk/articles/linux-ipv6-route-of-death

В представленном 22 мая выпуске платформы для организации совместной разработки GitLab 16.0 выявлена критическая уязвимость (CVE-2023-2825), позволяющая неаутентифицированному пользователю получить содержимое любого файла на сервере, насколько это позволяют права доступа процесса, обрабатывающего запросы. Уязвимости присвоен наивысший уровень опасности (10 из 10). Проблема устранена в обновлении GitLab 16.0.1 и затрагивает только ветку 16.0. Информация об уязвимости передана в GitLab в рамках действующей на HackerOne программы выплаты вознаграждений за обнаружение уязвимостей.

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

https://www.opennet.ru/opennews/art.shtml?num=59190
https://about.gitlab.com/releases/2023/05/23/critical-security-release-gitlab-16-0-1-released/

Исследователи из компании Eclypsium выявили аномальное поведение на системах с материнскими платами тайваньской компании Gigabyte Technology. Используемая в платах прошивка UEFI без информирования пользователя во время загрузки системы осуществляла подстановку и запуск исполняемого файла для платформы Windows. В свою очередь, запущенный исполняемый файл загружал из сети и запускал сторонние исполняемые файлы. Дальнейший разбор ситуации показал, что идентичное поведение проявляется на сотнях разных моделей плат Gigabyte и связано с работой поставляемого компанией приложения App Сenter.

Запускаемый файл был встроен в прошивку UEFI и в процессе инициализации во время загрузки сохранялся на диск. На стадии запуска драйверов (DXE, Driver Execution Environment) при помощи модуля прошивки WpbtDxe.efi данный файл загружался в память и прописывался в таблицу WPBT ACPI, содержимое которой в дальнейшем загружается и запускается менеджером сеансов Windows (smss.exe, Windows Session Manager Subsystem). Перед загрузкой модуль проверял включение в BIOS/UEFI функции "APP Center Download & Install" (отключена по умолчанию). Во время запуска на стороне Windows код подставлял в систему исполняемый файл "%SystemRoot%\system32\GigabyteUpdateService.exe", который прописывался как системный сервис.

После запуска сервис GigabyteUpdateService.exe выполнял загрузку обновления с серверов Gigabyte, но производил это без должной верификации загруженных данных по цифровой подписи и без использования шифрования канала связи. Для загрузки использовались адреса "http://mb.download.gigabyte.com/FileList/Swhttp/LiveUpdate4", "https://mb.download.gigabyte.com/FileList/Swhttp/LiveUpdate4" и "https://software-nas/Swhttp/LiveUpdate4". Допускалась загрузка по HTTP без шифрования, но даже при обращении по HTTPS проверка сертификата не производилась, что позволяло подменить файл при помощи MITM-атак и организовать выполнение своего кода на системе пользователя.

Ситуацию усложняет то, что полное устранение проблемы требует обновления прошивки, так как логика запуска стороннего кода интегрирована в прошивку. В качестве временной меры защиты от MITM-атаки на пользователей плат Gigabyte рекомендуется заблокировать вышеупомянутые URL на межсетевом экране. Компания Gigabyte уведомлена о недопустимости наличия в прошивках подобных небезопасно автообновляемых и принудительно встраиваемых в систему сервисов, так как компрометация инфраструктуры компании или участника цепи поставщиков (supply chain) может привести к совершению атак на пользователей плат и организации запуска вредоносного ПО, неподконтрольного на уровне операционной системы. Например, в августе и октябре 2021 года было зафиксировано два взлома инфраструктуры Gigabyte, которые привели к утечке закрытой документации и конфиденциальных данных. 

https://www.opennet.ru/opennews/art.shtml?num=59224
https://eclypsium.com/blog/supply-chain-risk-from-gigabyte-app-center-backdoor/

ClipboardImage.png
[Hide] (26.6KB, 500x87)

ClipboardImage.png
[Hide] (34.2KB, 400x145)

ClipboardImage.png
[Hide] (123.7KB, 700x274)

ClipboardImage.png
[Hide] (95KB, 500x347)

Некоторые серверы с nginx остаются уязвимы для техники Nginx Alias Traversal, которая была предложена на конференции Blackhat ещё в 2018 году и позволяет получить доступ к файлам и каталогам, размещённым вне корневого каталога, заданного в директиве "alias". Проблема проявляется только в конфигурациях с директивой "alias", размещённой внутри блока "location", параметр которой не завершается на символ "/", в то время как "alias" завершается на "/".

Суть проблемы в том, что файлы для блоков с директивой alias отдаются через прикрепление запрошенного пути, после его сопоставления с маской из директивы location и вырезания заданной в этой маске части пути. Для показанного выше примера уязвимой конфигурации атакующий может запросить файл "/img../test.txt" и этот запрос подпадёт под указанную в location маску "/img", после чего остающийся хвост "../test.txt" будет прикреплён к пути из директивы alias "/var/images/" и в итоге будет запрошен файл "/var/images/../test.txt". Таким образом, атакующим может получить доступ к любым файлам в каталоге "/var", а не только к файлам в "/var/images/", например, для загрузки лога nginx можно отправить запрос "/img../log/nginx/access.log".

В конфигурациях, в которых значение директивы alias не завершается символом "/" (например, "alias /var/images;"), атакующий не может перейти в родительский каталог, но имеет возможность запросить другой каталог в /var, начало имени которого совпадает с указанным в конфигурации. Например, запросив "/img.old/test.txt" можно получить доступ к каталогу "var/images.old/test.txt".

Анализ репозиториев на GitHub показал, что приводящие к проблеме ошибки в настройке nginx до сих пор встречаются в реальных проектах. Например, наличие проблемы было выявлено в серверной части менеджера паролей Bitwarden и могло использоваться для доступа ко всем файлам в каталоге /etc/bitwarden (запросы /attachments отдавались из /etc/bitwarden/attachments/), включая хранимую там БД с паролями "vault.db", сертификат и логи, для получения которых достаточно было отправить запросы "/attachments../vault.db", "/attachments../identity.pfx", "/attachments../logs/api.log" и т.п.

Метод также сработал с Google HPC Toolkit, в котором запросы /static перенаправлялись в каталог "../hpc-toolkit/community/front-end/website/static/". Для получения БД с закрытым ключом и учётными данными атакующий мог отправить запросы "/static../.secret_key" и "/static../db.sqlite3".

https://www.opennet.ru/opennews/art.shtml?num=59383
https://news.ycombinator.com/item?id=36580417

Опубликован выпуск пакетного фильтра nftables 1.0.8, унифицирующего интерфейсы фильтрации пакетов для IPv4, IPv6, ARP и сетевых мостов (нацелен на замену iptables, ip6table, arptables и ebtables). В пакет nftables входят компоненты пакетного фильтра, работающие в пространстве пользователя, в то время как на уровне ядра работу обеспечивает подсистема nf_tables, входящая в состав ядра Linux начиная с выпуска 3.13. На уровне ядра предоставляется лишь общий интерфейс, не зависящий от конкретного протокола и предоставляющий базовые функции извлечения данных из пакетов, выполнения операций с данными и управления потоком.

Непосредственно правила фильтрации и специфичные для протоколов обработчики компилируются в байткод в пространстве пользователя, после чего данный байткод загружается в ядро при помощи интерфейса Netlink и выполняется в ядре в специальной виртуальной машине, напоминающей BPF (Berkeley Packet Filters). Подобный подход позволяет значительно сократить размер кода фильтрации, работающего на уровне ядра и вынести все функции разбора правил и логики работы с протоколами в пространство пользователя.

Основные изменения:

    Добавлена возможность установки меток "meta" и "ct" из других полей в правилах. Например, для создания метки "meta" на основе манипуляций с IP-адресом из заголовка DSCP можно использовать конструкции вида:

        ... meta mark set ip dscp
        ... meta mark set ip dscp and 0x0f
        ... meta mark set ip dscp < 8
        ... meta mark set (ip dscp and 0xf) < 8

    В оптимизаторе правил, вызываемом при указании опции "-o" ("--optimize"), улучшена упаковка выражений, связанных с трансляцией адресов (NAT). Например, правила

       ip saddr 10.141.11.0/24 masquerade
       ip saddr 10.141.13.0/24 masquerade

       tcp dport 83 redirect to :8083
       tcp dport 84 redirect to :8084

    будут объединены в

       ip saddr { 10.141.11.0/24, 10.141.13.0/24 } masquerade

       redirect to :tcp dport map { 83 : 8083, 84 : 8084 }

    В анонимных map-списках реализована поддержка сохраняющих состояние (stateful) выражений, таких как счётчики:

       ... meta mark { 0xa counter, 0xb counter }
       ... ip saddr vmap { 127.0.0.1 counter : drop, * counter : accept }

    Появилась возможность упаковки наборов правил со сопоставленями 'ct state', без потери возможности подсчёта пакетов, например:

        ... ct state vmap { established counter : accept, \
                            related counter : accept, \
                            invalid counter : drop }

    На системах с ядром Linux 6.5 добавлена поддержка сброса сохраняющих состояние выражений (обнуления счётчиков) в списках element, set и map:

        reset element t m '{ 1.2.3.4 }'
        reset map ip t m
        reset set ip t m

    Упрощён синтаксис команды "reset", позволяющей обнулять сохраняющую состояние информацию в правилах, такую как счётчики и состояние квот:

        reset rules                  # сброс всех счётчиков
        reset rules ip               # сброс всех счётчиков для семейства 'ip'
        reset rules ip t             # сброс всех счётчиков для таблицы 'filter' в семействе 'ip'
        reset rules ip t c           # сброс всех счётчиков в цепочке 'input'

    При сбросе именованных объектов появилась возможность не указывать ключевое слово "table":

        reset counters
        reset counters ip
        reset counters ip filter

    Решена проблема с выводом некорректных сообщений об ошибках из-за отсутствия указания транспортного протокола при использовании map-выражений вида

        ... redirect to :tcp dport map { 83 : 8083, 84 : 8084 }

    (осуществляет перенаправление трафика на localhost, выбирая порт перенаправления в зависимости от целевого порта, например, пакеты к порту 83 будут перенаправлены на TCP-порт 8083 хоста localhost).
    При попытке загрузки правил, размер которых превышает ограничение, применяемое в непривилегированном пространстве имён (например, при попытке загрузки списков GeoIP в контейнере), обеспечен вывод рекомендации по увеличению значения параметра "/proc/sys/net/core/wmem_max".
    Разрешено обновление устройств в существующих цепочках netdev.

         # cat ruleset.nft
         table netdev x {
                chain y {
                        type filter hook ingress devices = { eth0 } priority 0; 
    policy accept;
                }
         }
         # nft -f ruleset.nft
         # nft add chain netdev x y '{ devices = { eth1 };  }'
         # nft list ruleset
         table netdev x {
                chain y {
                        type filter hook ingress devices = { eth0, eth1 } priority 
    0; policy accept;
                }
         }
         # nft delete chain netdev x y '{ devices = { eth0 }; }'
         # nft list ruleset
         table netdev x {
                chain y {
                        type filter hook ingress devices = { eth1 } priority 0; 
    policy accept;
                }
         }

    В выводе "nft list sets" по умолчанию включено отображение элементов списка. Для отключения показа элементов предложена опция "-t" ("--terse").
    Улучшены диагностические сообщений при ошибках, вызванных неверным выбором типа данных и некорректным использованием jump/goto в map.

         # cat test.nft
         table ip x {
                map y {
                        typeof ip saddr : verdict
                        elements = { 1.2.3.4 : filter_server1 }
                }
         }
         # nft -f test.nft
         test.nft:4:26-39: Error: Could not parse netfilter verdict; did you mean 
    `jump filter_server1'?
                         elements = { 1.2.3.4 : filter_server1 }
                                                ^^^^^^^^^^^^^^

    В наборах для присоединений (concatenation, определённые связки адресов и портов, упрощающие сопоставление) реализована возможность указания констант.

        ... update @s1 { ip saddr . 10.180.0.4 . 80 }

    Добавлена поддержка отображения комментариев при выводе таблиц и цепочек в формате JSON:

        # nft -j list ruleset
        {"nftables": [{"metainfo": {"version": "1.0.7", "release_name": "Old Doc 
    Yak", "json_schema_version": 1}}, {"table": {"family": "inet", "name": "test3", 
    "handle": 4, "comment": "this is a comment"}}]}

    Добавлена возможность использования JSON при сопоставлении инкапсулированных и туннелируемых данных. Например, для сопоставления с полем dscp, инкапсулированным в заголовок vxlan, можно использовать следующую конструкцию:

        # udp dport 4789 vxlan ip dscp 0x02
        [
            {
                "match": {
                    "left": {
                        "payload": {
                            "field": "dport",
                            "protocol": "udp"
                        }
                    },
                    "op": "==",
                    "right": 4789
                }
            },
            {
                "match": {
                   "left": {
                        "payload": {
                            "field": "dscp",
                            "protocol": "ip",
                            "tunnel": "vxlan"
                        }
                    },
                    "op": "==",
                    "right": 2
                }
            }
        ]

    Добавлена поддержка JSON в выражении 'last used', показывающем когда последний раз использовался элемент правила или списка.
    В команде 'nft list hooks' обеспечен показ зарегистрированных обработчиков bpf.
    Запрещено одновременное использование параметров "-i" ("--interactive") и "-f" ("--filename").
    В Python-привязках применение distutils заменено на setuptools. 

https://www.opennet.ru/opennews/art.shtml?num=59444

Лия Роу (Leah Rowe), основной разработчик и основатель дистрибутива Libreboot, представила первый выпуск новой загрузочной прошивки GNU Boot, представляющей собой форк Libreboot, адаптированный для соответствия требованиям Фонда СПО к полностью свободным дистрибутивам. GNU Boot планируют развивать в составе проекта GNU в качестве свободного системного окружения, которое можно использовать вместо проприетарных прошивок, обеспечивающих загрузку (полностью свободный дистрибутив CoreBoot). Сопровождение GNU Boot, как и Libreboot, будет обеспечивать Лия Роу.

Причиной создания форка является расхождение в подходе к допустимости использования в прошивках бинарных компонентов у проекта Libreboot и Фонда СПО. Осенью прошлого года проект Libreboot перешёл на более прагматичные правила использования бинарных компонентов, позволившие заметно расширить спектр поддерживаемого аппаратного обеспечения. Новой целью проекта Libreboot стала поддержка всего оборудования, поддерживаемого в CoreBoot, за исключением бинарных компонентов, влияющих на безопасность и надёжность (например, в Libreboot используеься me_cleaner для отключения Intel ME). При этом Libreboot потерял статус полностью свободного дистрибутива с позиции Фонда Свободного ПО.

10 июля была сформирована экспериментальная сборка Censored Libreboot c20230710, предлагающая редакцию Libreboot 20230625, в которой оставлены только компоненты, соответствующие критериям Фонда СПО, не допускающим поставку бинарных прошивок (firmware) и любых бинарных компонентов драйверов. В итоге в Censored Libreboot была удалена поддержка 2 материнских плат для ПК и 12 ноутбуков, т.е. почти половина из ранее поддерживаемых систем.

Проект GNU Boot стал продолжением опробованной в Censored Libreboot идеи по созданию полностью свободного ответвления Libreboot. Первый выпуск GNU Boot 20230717 вобрал в себе соответствующие критериям Фонда СПО изменения, накопившиеся с момента формирования прошлогоднего выпуска Libreboot 20220710, который является последним выпуском Libreboot, подготовленным до принятия проектом новых правил. По сравнению с Libreboot 20220710 в GNU Boot 20230717 реализована поддержка ноутбука Dell Latitude E6400 и двух Chromebook на базе архитектуры ARM - ASUS Chromebook Flip C101 и Samsung Chromebook Plus. В опубликованном выпуске также расширена поддержка плат ASUS KFSN4-DRE, KCMA-D8 и KGPE-D16, значительно переработана система сборки и проведена чистка документации.

Полный список поддерживаемого в GNU Boot 20230717 оборудования:

   * Серверы:
        ASUS KGPE-D16
        ASUS KFSN4-DRE 
   * Десктоп-системы:
        ASUS KCMA-D8
        Gigabyte GA-G41M-ES2L
        Acer G43T-AM3
        Intel D510MO и D410PT
        Apple iMac 5,2 
   * Ноутбуки:
        Dell Latitude E6400
        ThinkPad X60 / X60S / X60 Tablet
        ThinkPad T60 (с GPU Intel)
        Lenovo ThinkPad X200 / X200S / X200 Tablet
        Lenovo ThinkPad X301
        Lenovo ThinkPad R400
        Lenovo ThinkPad T400 / T400S
        Lenovo ThinkPad T500
        Lenovo ThinkPad W500
        Lenovo ThinkPad R500
        Apple MacBook1,1 и MacBook2,1
        ASUS Chromebook Flip C101
        Samsung Chromebook Plus (v1) 

https://libreboot.org/news/gnuboot.html
https://www.opennet.ru/opennews/art.shtml?num=59456

На конференции Black Hat USA 2023 объявлены победители ежегодной премии Pwnie Awards 2023, выделяющей наиболее значительные уязвимости и абсурдные провалы в области компьютерной безопасности. Pwnie Awards считается аналогом Оскара и Золотой малины в области компьютерной безопасности.

Основные победители:

    Лучшая уязвимость, приводящая к повышению привилегий. Победа присуждена уязвимости USB Excalibur (CVE-2022-31705) в реализации USB-контроллера, применяемого в продуктах виртуализации VMware ESXi, Workstation и Fusion. Уязвимость позволяет получить доступ к хост-окружению из гостевой системы и выполнить код с правами процесса VMX. Среди номинантов отмечается серия уязвимости в ядре Linux, связанная с использованием небезопасного макроса container_of().
    Лучшая уязвимость, приводящая к удалённому выполнению кода. Победа присуждена уязвимости (CVE-2023-20032) в свободном антивирусном пакете ClamAV, позволяющей выполнить код при сканировании файлов со специально оформленными дисковыми образами в формате HFS+ (например, при сканировании на почтовом сервере файлов, извлекаемых из писем). В числе номинантов упоминались уязвимости в системе мониторинга Checkmk и балансировщике нагрузки Windows (CVE-2023-28240).
    Лучшая криптографическая атака. Присуждается за выявление наиболее значимых брешей в реальных системах, протоколах и алгоритмах шифрования. Победу одержал метод атак по сторонним каналам, позволяющий удалённо восстановить значения ключей шифрования на базе алгоритмов ECDSA и SIKE через анализ видео с камеры, снимающей светодиодный индикатор ридера смарт-карт или устройства, подключённого к одному USB-хабу со смартфоном, производящим операции с ключом. В числе номинантов также были проблемы с шифрованием, компрометирующие сквозное шифрование во многих Matrix-клиентах.
    Наиболее инновационное исследование. Победа присуждена исследованию, показавшему возможность использования разъёма Apple Lightning для доступа к отладочному JTAG-интерфейсу iPhone и получения полного контроля за устройством. Среди номинантов также были атака Downfall на CPU Intel и анализ применения метода атаки Rowhammer на память DRAM для создания уникальных идентификаторов.
    Самое недооцененное исследование. Победителем стало исследование сотрудника компании Trendmicro, выявившее новый класс уязвимостей в Windows CSRSS, позволяющих повысить свои привилегии через отравление кэша контекстов активации. Среди номинантов упомянуты уязвимости, затрагивающие почти все IoT-устройства Mobile-as-a-Gateway (MaaG), а также уязвимости в отладчике Renderdoc, вызванные целочисленным переполнением и ошибкой при работе с символическими ссылками.
    Самый большой провал (Most Epic FAIL). Премию получила Администрация транспортной безопасности США, которая забыла ограничить доступ к публично доступному хранилищу Elasticsearch, на котором, среди прочего, находился список лиц, которых запрещено пускать в самолёты (No Fly List).
    Лучшая ошибка в клиентском ПО. Победителем стала уязвимость CVE-2022-22036 в механизме Performance Counters, позволяющая повысить свои привилегии на платформе Windows.
    Самая ламерская реакция производителя (Lamest Vendor Response). Номинация за самую неадекватную реакцию на сообщение об уязвимости в собственном продукте. Победа присуждена компании Threema, которая капризно отреагировала на анализ безопасности протокола "безопасного" мессенджера данной компании и не посчитала серьёзными выявленные критические проблемы.
    Самое большое достижение. Победа присуждена Клементу Лесину (Clement Lecigne) из Google Threat Analysis Group за работу по выявлению 33 0-day уязвимостей, используемых для атак на Chrome, iOS и Android. 

https://www.opennet.ru/opennews/art.shtml?num=59577

Опубликован корректирующий выпуск системного менеджера systemd 256.1, в котором устранена проблема, приводившая к удалению содержимого раздела /home при выполнении команды "systemd-tmpfiles --purge", добавленной в systemd 256 для удаления всех файлов и каталогов, созданных через настройки в tmpfiles.d.

В примечании к выпуску systemd 256 и в man-руководстве systemd-tmpfiles было указано, что опция "--purge" удаляет все файлы и каталоги, созданные через настройки tmpfiles.d, но название "tmpfiles" в названии утилиты вводило в заблуждение и создавало впечатление, что удаление касается только временных файлов. При этом настройки tmpfiles.d не ограничиваются временными файлами и также используются для автоматического создания несуществующих каталогов с данными. В частности, удаление содержимого домашних каталогов объясняется тем, что при помощи файла "/usr/lib/tmpfiles.d/home.conf" создавался раздел "/home" и, соответственно, команда "systemd-tmpfiles --purge" приводила к его удалению.

Первоначально сообщение об ошибке было отвергнуто Лукой Боккасси (Luca Boccassi), разработчиком systemd из Microsoft, следующим образом: "Таким образом, функция, которая буквально задокументирована как «все файлы и каталоги, созданные записью tmpfiles.d/, будут удалены», о чём вы ничего не знали, звучала как «хорошая идея»? Вы хотя бы пошли и посмотрели, какие записи tmpfiles.d у вас были заранее? Может быть, не стоит просто запускать случайные команды, о которых вы ничего не знаете, игнорируя при этом то, что вам говорит документация? Просто мысль, ага". В ответ ему указали на то, что в документации утилита systemd-tmpfiles до сих пор описывается как "инструмент для создания, удаления и очистки непостоянных и временных файлов и каталогов", несмотря на то, что это давно не соответствует действительности.

В конечном итоге, после долгих обсуждений в последние несколько дней, поведение systemd-tmpfiles всё таки было признанно ошибочным и изменено. Вначале для исключения ошибочного удаления домашних каталогов разработчики systemd намеревались удалить опцию "--purge", но затем приняли изменение, ограничивающее область действия команды "systemd-tmpfiles --purge" - данная команда теперь может быть выполнена только при явном указании в командной строке конкретного файла конфигурации из tmpfiles.d/ и приведёт к удалению лишь связанных с ним файлов и каталогов. Кроме того, в man-руководство systemd-tmpfiles добавлено более подробное описание опции и предупреждение о возможных последствиях.


---

https://www.opennet.ru/opennews/art.shtml?num=61403

Представлен выпуск P2P-платформы Radicle 1.0, нацеленной на создание децентрализованного сервиса совместной разработки и хранения кода, похожего на GitHub и GitLab, но не привязанного к конкретным серверам, не подверженного цензуре и работающего с использованием ресурсов участников P2P-сети. Релиз 1.0 ознаменовал стабилизацию протокола и готовность платформы к повсеместному использованию. Начиная с данного выпуска протокол будет изменяться с сохранением обратной совместимости, а инструментарий будут включать возможности для бесшовного обновления существующих систем до новой версии. Наработки проекта написаны на языке Rust и распространяются под лицензиями Apache 2.0 и MIT. Сборки подготовлены для Linux и macOS. Дополнительно развиваются десктоп-клиент, web-интерфейс и консольный интерфейс.

Radicle позволяет не зависеть при разработке и распространении кода от централизованных платформ и корпораций, привязка к которым вносит дополнительные риски (единая точка отказа, компания может закрыться или изменить условия работы). Для управления кодом в Radicle используется привычный Git, расширенный средствами определения репозиториев в P2P-сети. Все данные в первую очередь сохраняются локально (концепция local-first) и всегда доступны на компьютере разработчика, независимо от состояния сетевого подключения.

Участники предоставляют доступ к своему коду и связанным с кодом артефактам, таким как патчи и обсуждения исправления ошибок (issues), которые сохраняются локально и реплицируются на узлы других заинтересованных разработчиков, подключённые к общей децентрализованной P2P-сети. В итоге формируется глобальный децентрализованный Git-репозиторий, данные которого реплицированы и продублированы на разных системах участников.

Для определения соседних узлов в P2P-сети применяется протокол Gossip, а для репликации данных между узлами протокол Heartwood, основанный на Git. Так как протокол основан на Git, платформу легко интегрировать с существующими инструментами для разработки на Git. Для идентификации узлов и верификации репозиториев используется криптография на основе открытых ключей, без применения учётных записей.

Каждый репозиторий в P2P-сети имеет свой уникальный идентификатор и самосертифицирован (self-certifying), т.е. все действия в репозитории, такие как добавление коммитов и оставление комментариев к issue, заверяются владельцем цифровой подписью, позволяющей убедиться в корректности данных на других узлах без использования централизованных удостоверяющих центров. Для получения доступа к репозиторию достаточно, чтобы в online находился хотя бы один узел, на котором имеется его реплицированная копия.

Узлы в P2P-сети могут подписываться на определённые репозитории и получать обновления. Возможно создание приватных репозиториев, доступных только определённым узлам. Для управления и владения репозиторием используется концепция "делегатов" (delegates). Делегатом может быть как отдельный пользователь так и бот или группа, привязанные к специальному идентификатору. Делегаты могут принимать в репозиторий патчи, закрывать issue и задавать права доступа к репозиторию. К каждому репозиторию может быть привязано несколько делегатов.

На системах пользователей Radicle-репозитории хранятся в виде обычных git-репозиториев, в которых присутствуют дополнительные пространства имён для хранения данных пиров и форков, с которыми осуществляется текущая работа. Обсуждения, предлагаемые патчи и компоненты для организации рецензирования тоже сохраняются в git-репозитории в виде совместных объектов (COB - Collaborative Objects) и реплицируются между пирами.

Radicle 1.0 включает в себя:

    * Реализацию расширяемого протокола для организации работы P2P-сети и синхронизации данных.
    * Элементы социального взаимодействия, такие как issue, патчи и рецензии на код.
    * Протокол аутентификации и авторизации на основе открытых ключей, работающий без централизованных удостоверяющих серверов.
    * CLI-интерфейс, привычный пользователям, знакомым с Git.
    * Web-интерфейс для навигации по репозиториям и узлам.
    * Средства для обеспечения конфиденциальности, включающие поддержку приватных репозиториев и возможность работы через анонимную сеть Tor.
    * Поддержку повторяемых сборок для проверки, что распространяемые исполняемые файлы Radicle собраны из заявленных исходных текстов. 

Ещё не готовые возможности, пока находящиеся в разработке:

    * Встроенные инструменты для непрерывной интеграции (CI) и непрерывной доставки (CD).
    * Консольный интерфейс Radicle TUI (Terminal User Interface).
    * Расширенные возможности рецензирования изменений.
    * Система получения уведомлений об изменениях в репозитории.
    * Поддержка профилей пользователей и возможность привязки нескольких устройств.
    * Поддержка тегов.
    * Утилиты для модерирования и управления узлами.
    * Десктоп-приложение. 

---

https://www.opennet.ru/opennews/art.shtml?num=61842
https://radicle.xyz/2024/09/10/radicle-1.0.html

Разработчики дистрибутива Arch Linux объявили о переходе к прямому сотрудничеству с компанией Valve, развивающей операционную систему SteamOS, основанную на Arch Linux. Компания Valve поможет в сопровождении сборочной инфраструктуры и поддержании анклава для заверения компонентов дистрибутива цифровыми подписями. Valve предоставит дополнительные ресурсы, которые позволят развивать отмеченные области, не ограничиваясь свободным временем добровольцев.

Ожидается, что сотрудничество с Valve ускорит решение некоторых актуальных проблем дистрибутива, ускорит разработку и позволит быстрее реализовать задуманные планы. Работа над реализуемыми при участии Valve проектами будет вестись в рамках штатных рабочих процессов, принятых в сообществе Arch Linux, и модели принятия решений на основе достижения консенсуса. Для всех инициируемых при участии Valve значительных изменений будут создаваться RFC, проводиться публичное обсуждение в списке рассылки и осуществляться планирование работ через публикацию заявок (issue) в GitLab, что позволит добиться прозрачности и даст возможность сообществу контролировать ход выполняемой работы. 

---

https://www.opennet.ru/opennews/art.shtml?num=61950
https://lists.archlinux.org/archives/list/[email protected]/thread/RIZSKIBDSLY4S5J2E2STNP5DH4XZGJMR/

Вот, как это работало: при отправке письма на портал Zendesk техподдержки компании (например, [email protected]) Zendesk создаёт новый тикет техподдержки. Чтобы отслеживать цепочку писем, Zendesk автоматически генерирует адрес reply-to, который выглядит так: support+id{id}@company.com, где {id} — это уникальный номер тикета. Благодаря этому адресу все будущие ответы будут отправляться напрямую на тот же тикет.

Также у Zendesk есть функция совместной работы над тикетами. Если добавить кого-нибудь в CC в одном из ответов на письмо, то Zendesk автоматически добавляет его к тикету, позволяя ему видеть полную историю тикета на портале техподдержки.

Эксплойт было реализовать легко: если нападающий знает адрес почты техподдержки и ID тикета (который достаточно просто подобрать, потому что ID тикетов увеличиваются инкрементально), он может применить спуфинг почты, чтобы выдать себя за исходного отправителя. Если отправить поддельное письмо на support+id{id}@company.com с почтового адреса пользователя и добавив в CC своё собственное письмо, то Zendesk подумает, что письмо подлинное. Затем он добавит почтовый адрес нападающего к тикету, давая ему полный доступ ко всей истории тикета.

Это значит, что нападающий, по сути, мог присоединиться к любой беседе техподдержки и читать конфиденциальную информацию; и всё это благодаря тому, что Zendesk не обеспечил должной защиты от спуфинга электронной почты.
. . .
В то время я обнаружил пост TICKETTRICK, написанный в 2017 году. В нём исследователь безопасности Инти Де Сёклер подробно описал, как он воспользовался Zendesk для внедрения в приватные рабочие пространства Slack сотен компаний. Так как многие компании использовали Slack SSO на том же домене, что и Zendesk, исследователь догадался, что можно выполнить почтовые верификации через почтовый адрес [email protected] и получить доступ к приватным каналам Slack. В те годы Zendesk ещё не была такой большой и существовали другие баги, позволявшие любому, кто знает ваш адрес почты, просматривать тикеты.
. . .
1. Создаём аккаунт Apple с почтой [email protected] и запрашиваем код верификации. Apple отправляет код верификации с [email protected] на [email protected] и Zendesk автоматически создаёт тикет.

2. В то же самое время создаём тикет на портале техподдержки company.com с моего собственного адреса почты, что позволяет мне отслеживать диапазон значений ID.

3. Используем баг со спуфингом почты, чтобы попытаться добавить себя во все тикеты в рамках определённого выше диапазона.

4. Выполняем логин в портал техподдержки company.com (обычно на support.company.com) со своего аккаунта ([email protected]) и просматриваем тикеты, включённые в CC.

5. Вводим код верификации в Apple

6. Используем функцию Slack «Login with Apple» и выполняем вход с аккаунтом Apple, связанным с почтой company.com
Я воспроизвёл эти шесть этапов на сотнях уязвимых инстансов Zendesk и Slack.


> Так как в моём баге использовался спуфинг почты, его посчитали не входящим в рамки («out of scope») программы компании на HackerOne, а мой отчёт был отклонён. Невероятно.

> Несмотря на угрозу безопасности, компания не предприняла никаких действий по отчёту, потому что он выходил за рамки её программы.

> Несмотря на устранение проблемы, Zendesk в конечном итоге решила не выплачивать баунти за мой отчёт. Как они это мотивировали? Я нарушил инструкции HackerOne по раскрытию и поделился уязвимостью с компаниями, которые она затронула. 


оригинал https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b9d2cf2e52
https://habr.com/ru/companies/ruvds/articles/851106/

Стажер устроил саботаж на рабочем месте и принес проблем на 10 млн. долларов.

•  Программист Кейю Тянь (https://github.com/keyu-tian) устроился стажёром в компанию ByteDance (https://ru.wikipedia.org/wiki/ByteDance) (владеет TikTok) и изнутри два месяца саботировал выполнение проекта по разработке нейросетей, добавляя ошибки в код. Как сообщает BBC, Кейю успел нанести значительный ущерб — внедрял вирусы и изменял ключевые элементы инфраструктуры. Вся команда из 30 разработчиков отчаянно пыталась выяснить, откуда появляются ошибки, пока не стало ясно, что проблема внутри самой компании.

•  Один из самых коварных методов, который использовал стажер, — загрузка специальных Pickle-файлов (https://pythonworld.ru/moduli/modul-pickle.html) со скрытым вредоносным кодом. Этот код активировался случайным образом, что усложняло его обнаружение. Система начала ломаться, проекты зависали, а команда была в растерянности: казалось, что баги возникали из ниоткуда.

•  Кроме того, стажер изменил версию библиотеки PyTorch, (https://ru.wikipedia.org/wiki/PyTorch) на которой строились все проекты команды. Он вносил крохотные изменения каждый день, которые по итогу рушили все разработки. Программы перестали работать стабильно, а эксперименты давали неверные результаты. Разработчики не сразу догадались проверить исходный код, ведь ошибки выглядели настолько рандомными, что их сложно было связать с изменениями в библиотеке.

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

•  Хитрость «шпиона» была в том, что он посещал все командные совещания и следил за тем, как коллеги планируют решать проблемы. В результате, он мог заранее продумывать новые способы саботажа. Команда долгое время не подозревала, что один из своих и был причиной всех неприятностей.

•  Тем не менее, лог-файлы помогли вывести злоумышленника на чистую воду. Как только его действия были выявлены, компания уволила стажера и проинформировала его учебное заведение и отраслевые организации о случившемся. Теперь ByteDance оценивает убытки, которые составляют 10 миллионов долларов. Проект по внедрению ИИ сильно затормозился, а сроки сгорели. 

•  После того, как Тянь исключили из ByteDance, он не подвергся наказанию или порицанию со стороны своих наставников в высшем учебном заведении. Такие вот дела...

оригинал https://www.theguardian.com/technology/2024/oct/21/tiktok-owner-bytedance-sacks-intern-for-allegedly-sabotaging-ai-project

Своим первым постом на площадке я хочу привлечь внимание к катастрофе, сложившейся на данный момент в RU-зоне проекта NTPPool.org. Я думаю, что проект в представлении не нуждается, тем не менее, для тех, кто никогда о нём не слышал - во многом благодаря ему все ваши компьютеры, смартфоны, серверы и прочие гаджеты имеют точное время.

Из описания проекта:

    pool.ntp.org — это огромный кластер серверов точного времени, предоставляющий надежный и простой в использовании NTP‑сервис для миллионов клиентов. В настоящее время услугами пула пользуются десятки миллионов систем по всему миру. Он используется по умолчанию в большинстве дистрибутивов Linux и во многих сетевых устройствах (см. информацию для производителей).

Я являюсь участником проекта довольно давно - лет 5 точно, может быть больше. У меня дома толстый канал 500 Мбит/с, я поднял на домашнем Mikrotik RB4011 NTP-сервер, научил роутер ходить на несколько российских NTP-серверов высшего уровня точности Stratum 1 и добавился в пул на правах Stratum 2. Вкратце о том, что это значит - Stratum это уровень точности времени, чем больше цифра, тем меньше точность (условно). Серверы S1 получают данные о времени напрямую от источников точного времени (атомные часы, GPS, что-нибудь подобное). S2 запрашивает время у S1 и отдаёт его клиентам (серверов S1 на всех не хватает). S3 запрашивает время у S2 и отдаёт своим клиентам, и так далее. По факту для обычной жизни вполне достаточно S3.

На роутере годами висела поднятая служба NTP, которая приносила пользу миру и не мешала жить. Всё изменилось в середине октября, когда в домовой чат стали писать соседи, что шлагбаум, завязанный на мой интернет, стоит открытый (это его стандартное поведение при пропадании связи со шлюзом). Проверив всё у себя и не найдя проблем, я списал на случайность, пока не залез на роутер и не обнаружил 500 Мбит/с и около 500 000 pps входящего трафика, который словно растворялся в роутере (на WAN-интерфейсе дикий IN, но нет никаких сопутствующих OUT). Попинал лобовое стекло, протёр колесо, вышел и вошёл Обновив на роутере прошивку, перезагрузив его и увидев, что проблема не ушла, я полез искать причину и обнаружил, что проблема в службе NTP. Это именно она жрёт на 100% все 4 ядра CPU и всю полосу на приём. Заблокировал фаерволом запросы - и всё сразу же отвисло и заработало. Вскоре мне пришло сообщение от мониторинга NTPPool, что сервер пропал из доступа и исключён из пула (пул непрерывно мониторит серверы на предмет корректности отдаваемого времени и доступности вообще, и присваивает ему рейтинг - от -100 до 20. В пул добавляются серверы с рейтингом больше 10).

В личном кабинете участника проекта есть настроечка Netspeed, она показывает условное количество трафика по отношению к общему объёму твоей зоны, который ты готов принять на себя. У меня Netspeed стоял фактические 500 Mbps, но когда серверов осталось 5 - даже настройка 512 kbps кладёт полностью канал толщиной 500 Mbps.

Я несколько раз пытался открывать краник, в том числе на 512 kbit — мониторинг признавал сервер, добавлял его в пул и домашняя сеть ложилась под нагрузкой. NTP с точки зрения нагрузки мерзкий протокол — много‑много маленьких‑маленьких UDP‑шных пакетиков, попытка шейпить которые фаерволом ни к чему хорошему не приводит и нагрузку не снижает. Единственное, что можно сделать — откинуть.

В процессе изучения проблемы я обнаружил, что что-то случилось в начале-середине октября и из зоны RU за 2 недели вылетело 120 серверов из 140 имеющихся.

Остальные под непропорционально высокой нагрузкой тоже стали вылетать - кто-то, как я, заметил и временно потушил сам, поскольку это сказалось на качестве остальных сервисов, кого-то убил мониторинг за потерю пакетов. Данная ситуация развивается как снежный ком, вылетевшие 10 серверов поднимают нагрузку на оставшиеся, которые тоже начинают вылетать. На данный момент ситуация катастрофическая, поскольку в зоне RU осталось 4 (четыре) сервера, один из которых мой.

Данным постом я хочу привлечь внимание к проблеме и обратиться к сообществу с призывом арендовать по цене двух чашек кофе в месяц VPS на каком-нибудь хостинге и добавить его в пул до стабилизации ситуации.

Решение, которое выбрал я:
- аренда VPS на одном из хостингов с Debian 12. Одно ядро не вывозит нагрузку и очень быстро приводит к блокировке - лучше брать не самый дешёвый тариф.

- sudo apt install chrony и создать в /etc/chrony/conf.d/ файл

root@ntp2:~# cat /etc/chrony/conf.d/settings.conf
pool ntp.msk-ix.ru iburst 
pool ntp4.vniiftri.ru iburst 
pool ntp5.vniiftri.ru iburst  
allow all 
ratelimit interval 3 burst 8 leak 4

- перезапустить Chrony: systemctl restart chrony
- добавить сервер в свой кабинет и пройти валидацию (чтобы Unverified превратилось в галочку).
- выбрать скорость соединения (начать с 512kbps и потихоньку поднимать, если нет проблем) и подождать, пока скоринг поднимется до 10.

Если у вас многоядерная виртуалка, то можно собрать NTP-прокси https://github.com/mlichvar/rsntp, (доставив пакеты make и cargo), т.к. chrony однопоточен и в один поток не успевает отвечать. Конфиг для chrony будет немного иным:

root@cv4281075:~# cat /etc/chrony/conf.d/settings.conf 
pool ntp.msk-ix.ru iburst
pool ntp4.vniiftri.ru iburst
pool ntp5.vniiftri.ru iburst

cmdport 0
allow
port 11123
bindaddress 127.0.0.1

rsntp (после установки в /usr/bin) запускается командой /usr/bin/rsntp -4 N, где N - число ядер процессора.

А можно просто запустить несколько процессов chrony с первым конфигом, но разными pid-файлами (так тоже можно, и, кажется, этот способ лучше, чем rsntp)

# chronyd -d -x pidfile /var/run/chrony/server1.pid
# chronyd -d -x pidfile /var/run/chrony/server2.pid
# chronyd -d -x pidfile /var/run/chrony/server3.pid
# chronyd -d -x pidfile /var/run/chrony/server4.pid

До стабилизации ситуации с количеством серверов я настоятельно не рекомендую добавлять в пул ответственные серверы (работа, дом, етц) и предлагаю использовать именно выделенные VPS. Когда ситуация стабилизируется, можно будет поднять службу на роутере, как это было сделано у меня ранее.

Помогите сохранить точное время в Рунете. Если не мы, то кот?

UPD: на пост откликнулись представители timeweb.cloud и выделили под NTP 30 (!!!) виртуальных машин!

https://habr.com/ru/articles/860828/
https://archive.is/k2ZXv

15 октября мы раскатили прошивку на 10% устройств. Поэтапная раскатка обновления — это стандартная практика. Она предназначена в том числе для того, чтобы выявлять проблемы новых версий на ранней стадии. И прежде чем увеличивать процент раскатки, мы отсматриваем метрики всех ключевых пользовательских сценариев. Но число генерируемых нами NTP‑запросов исторически никогда не входило в метрики, требующие валидации, потому что NTP‑клиент годами существовал практически без изменений и не приводил к проблемам.

К 24 октября новая прошивка докатилась до 100% колонок. Опять же, критичные для пользователей сценарии покрыты автоматическим мониторингом. Если что‑то важное ломается, мы получаем уведомление. Но, как вы уже догадались, для NTP‑клиента таких уведомлений настроено не было.
. . .
Жалоб было мало, действующий регламент поддержки не был рассчитан на подобные ситуации, поэтому обращения рассматривали не в самом высоком приоритете. К 20 ноября мы нашли ошибку, внесли исправление в код и начали готовить новый релиз.

В выходные 23–24 ноября ситуация с NTP‑серверами обостряется: доступными остаются лишь четыре сервера. К этому моменту мы уже начали раскатывать релиз с исправлением на 10% устройств.
. . .
В воскресенье мы выпустили хотфикс в виде новой рантайм‑конфигурации для NTP‑клиента, который увеличивал период перезапроса с 5 до 600 секунд, уменьшая нагрузку на серверы в 120 раз. Хотфикс не исправлял проблему полностью, но был единственным быстрым способом снять чрезмерную нагрузку с NTP-серверов.
. . .
мы запланировали выделить ресурсы в общий пул NTP‑серверов. Это займёт некоторое время, потому что наши дата‑центры удалены от основных точек обмена трафиком, а для NTP‑серверов RTT (Round Trip Time) это — ключевой фактор качества. Мы установим и запустим мощности на основных точках обмена трафиком.

Для наших устройств мы заведём именную зону в соответствии с гайдлайнами проекта NTPPool.org для бо́льшей прозрачности. Генерируемый ими трафик будет локализован на наших NTP‑серверах, если мы продолжим полагаться на публичную инфраструктуру проекта.

Ещё мы добавим метрики, связанные с NTP, на этап валидации A/Б‑экспериментов, а также реалтайм‑уведомления о неполадках в этом компоненте. В том числе расширим сценарии мониторинга исходящего и входящего служебного трафика устройства в целом. Также поработаем над каналами коммуникаций и поддержкой, чтобы подобные проблемы быстрее до нас эскалировались.


https://habr.com/ru/companies/yandex/articles/861538/
https://archive.fo/1U5MJ