Трекеры мои трекеры.

Хакерская группа объявила о взломе компании Gravy Analytics, занимающейся продажей данных о местоположении смартфонов правительственным структурам США. Злоумышленники утверждают, что получили доступ к значительному объёму информации, включая списки клиентов, сведения об отраслях их деятельности и точные геоданные пользователей. Хакеры угрожают опубликовать эти данные, если компания не ответит в течение 24 часов.

Данный инцидент стал серьёзным сигналом для всей индустрии, связанной с торговлей геолокационными данными. На протяжении многих лет компании собирали информацию о местоположении через мобильные приложения и рекламные сети, а затем продавали её частным организациям и государственным учреждениям. Среди клиентов числятся Министерство обороны США, Министерство внутренней безопасности, Налоговое управление и ФБР. Однако такие данные становятся привлекательной целью для киберпреступников.

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

Злоумышленники заявляют, что получили доступ к инфраструктуре Gravy Analytics ещё в 2018 году. Предоставленные скриншоты демонстрируют полный контроль над серверами, доменами компании и хранилищами Amazon S3. Также сообщается, что взломанные серверы работают на операционной системе Ubuntu, что подчёркивает масштаб утечки информации.

Тут можно посмотреть, данные каких приложений были слиты.

Я у себя уже писал пару раз про движуху РБПО (Разработка Безопасного Программного Обеспечения) и "Центр исследований безопасности системного программного обеспечения"

https://xn--r1a.website/tech_b0lt_Genona/4755
https://xn--r1a.website/tech_b0lt_Genona/4784

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

Я не знаю, замечали ли вы или нет, но покрытие от полных тестов в postgres можно нормально строить только при сборке gcc и нельзя в clang.

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

Я обратился за помощью к коллегам из ИСП РАН, которые занимаются компиляторами. Некоторое время мы совместно созерцали эту проблему, потом перешли к действиям (они в первую очередь) и вот эти действия завершились успехом: патч добавляющий binary ID в имя файлов покрытия, и таким образом в должной мере разнообразящий имена файлов, был написан, и вот буквально вчера принят в основную ветку.

https://github.com/llvm/llvm-project/pull/123963

Ура, товарищи! Еще раз позвольте выразить благодарности Артему Синкевичу, написавшему патч, и его коллегам которые все это организовали!

Этот патч имеет больше значение не только для компании Postgres Professional, но и для всего мирового posgres-сообщества. Строить покрытия нужно всем, а использование clang в процессе разработки по многим причинам может быть более предпочтительным.

Я уже сообщил в списке рассылке hackers об этой новости
https://www.postgresql.org/message-id/flat/3398811.KgjxqYA5nG%40thinkpad-pgpro
надеюсь что эта новость будет оценена там по-достоинству

Источник: https://xn--r1a.website/sdl_dynamic/8409

Изначальная картинка взята из этой статьи

NowSecure Uncovers Multiple Security and Privacy Flaws in DeepSeek iOS Mobile App
https://www.nowsecure.com/blog/2025/02/06/nowsecure-uncovers-multiple-security-and-privacy-flaws-in-deepseek-ios-mobile-app/

13 февраля выступаю на ТБ Форуме в треке "Подходы и инструменты управления процессом РБПО (Разработки Безопасного Программного Обеспечения)".

Буду вести мастер-класс, где покажу и расскажу, как можно проводить анализ СЗИ (средств защиты информации) в контейнерном исполнении с помощью Luntry

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

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

https://www.tbforum.ru/2025/program/rbpo-mk

Собственно, я там буду весь день, кто хочет пересечься пишите в комменты или в личку - @rusdacent

Miguel Ojeda (https://ojeda.dev/) принёс в рассылку

Hi all,

Given the discussions in the last days, I decided to publish this page
with what our understanding is:

    https://rust-for-linux.com/rust-kernel-policy

I hope it helps to clarify things. I intend to keep it updated as needed.

https://lore.kernel.org/rust-for-linux/CANiq72m-R0tOakf=j7BZ78jDHdy=9-fvZbAT8j91Je2Bxy0sFg@mail.gmail.com/

Who maintains Rust code in the kernel?
The usual kernel policy applies. That is, whoever is the listed maintainer.

The "RUST" subsystem maintains certain core facilities as well as some APIs that do not have other maintainers. However, it does not maintain all the Rust code in the kernel — it would not scale.
. . .
Who is responsible if a C change breaks a build with Rust enabled?
The usual kernel policy applies. So, by default, changes should not be introduced if they are known to break the build, including Rust.

However, exceptionally, for Rust, a subsystem may allow to temporarily break Rust code. The intention is to facilitate friendly adoption of Rust in a subsystem without introducing a burden to existing maintainers who may be working on urgent fixes for the C side. The breakage should nevertheless be fixed as soon as possible, ideally before the breakage reaches Linus.
. . .
Are duplicated C/Rust drivers allowed?
The usual kernel policy applies. So, by default, no.

Rust kernel policy
https://rust-for-linux.com/rust-kernel-policy

Спасибо подписчику за наводку

.

Леннарт Поттеринг (Lennart Poettering) предложил включить в системный менеджер systemd изменение, позволяющие загружать систему с использованием образа корневой ФС, получаемого c внешнего хоста по протоколу HTTP. Изменение сводится к расширению systemd возможностью не только скачивать дисковый образ по HTTP на начальной стадии загрузки, но и распаковывать загруженный образ, связывать с блочным устройством в loopback-режиме, монтировать блочное устройство как /sysroot и загружать с него систему.
. . . 
Предполагается, что загрузка с образов, получаемых с внешнего хоста, упростит организацию тестирования современных неизменяемых ("immutable") операционных систем на реальном оборудовании. Разработчик может на своём компьютере сформировать образ с системным окружением утилитой mkosi и сделать его доступным через HTTP командой "mkosi -f serve". На компьютере, на котором требуется протестировать работу системы, достаточно включить в EFI загрузку по HTTP и добавить URL загружаемого образа командой:

   kernel-bootcfg --add-uri=http://192.168.47.11:8081/image.efi --title=testloop --boot-order=0

После чего можно просто перезагрузить компьютер и он загрузит типовой образ ядра UKI, который затем загрузит подготовленный разработчиком дисковый образ с корневой ФС. До отключения в EFI загрузки по HTTP каждая последующая перезагрузка компьютера будет приводить к загрузке свежего системного образа. При подобном тестировании никак не затрагиваются локальные диски.

Для systemd развивается возможность загрузки системных образов по HTTP
https://www.opennet.ru/opennews/art.shtml?num=62711

Оригинальный тред
https://mastodon.social/@pid_eins/113979730693247159

Четверг, а значит время проектов от подписчиков! 🌝

Тем, кто пропустил, что такое четверговые проекты от подписчиков, можно прочитать тут - https://xn--r1a.website/tech_b0lt_Genona/4983

Слово автору @Ihippik
---
Есть совершенно простое решение для публикации изменений данных в ваших таблицах PostgreSQL в брокер сообщений. Change Data Capture (CDC).
Например удалили какую-то строку, изменили или быть может добавили - вы сразу же получаете сообщение об этом со всеми подробностями в ваш брокер сообщений.
Благодаря этому вы сможете строить сложные event-driven системы или просто как-то реагировать на изменения ваших данных.
Механизм построен на логической репликации и использовании WAL.

https://github.com/ihippik/wal-listener
---

Если всё пойдëт хорошо, то будут тут в ~12-40 по МСК вещать про то как смотреть с пристрастием на СЗИ в контейнерном исполнении с помощью Luntry

https://groteck.mts-link.ru/j/91042977/525311227/stream-new/1854043222

Правительство РФ утвердило параметры эксперимента по внедрению системы добровольного подтверждения компетенций для разработчиков ПО. Это возможность для работодателей и образовательных учреждений точнее определять уровень ИТ-компетенций и подбирать подходящих сотрудников, а для специалистов — проверить свои знания и получить сертификат, подтверждающий их уровень. С 31 мая 2025 года любой желающий, независимо от уровня образования, сможет пройти тесты и выполнить практические задания. В этом году на платформе планируется разместить материалы по 21 направлению (Python, Java, Git и другие).

Примечательно, что Ассоциация предприятий компьютерных и информационных технологий (АПКИТ; входят VK, 1C, Softline) работает над другим способом подтверждения компетенций в IT — путем сертификации, по аналогии с вендорскими системами ушедших из РФ компаний. Председатель совета АПКИТ по развитию сертификации IT‑специалистов Наталья Починок сообщила СМИ, что ассоциация, помимо создания своей системы, участвует в разработке аналогичной сторонней системы на правах экспертов. В инициативе АПКИТ «заложена гармонизация требований к сертификатам участников, включая идентификацию по СНИЛС, что даст возможность в будущем интегрироваться с госсервисами».
В «Хабре» пояснили СМИ, что видят интерес аудитории сайта к оценке навыков на базе сайта: «Считаем, что на российском рынке должен быть набор разных возможностей оценки от разных игроков».
У каждой компании существуют собственные требования к квалификации специалистов, уточнила СМИ директор по персоналу Postgres Professional Ксения Замуховская. По её словам, «если у IT‑компаний будут запрашивать такие данные, то маловероятно, что найдутся желающие их распространять — есть риск раскрытия чувствительной информации».
Основатель IT‑компании Tiqum Юрий Гизатуллин считает, что систему подтверждения навыков нужно строить не на базе текущего решения одной компании, а в формате отдельной платформы.

Утверждены параметры эксперимента по внедрению системы добровольного подтверждения компетенций для разработчиков ПО в РФ
https://habr.com/en/news/882096/

Оригинал
http://government.ru/news/54223/

В экосистеме языка программирования Go обнаружен вредоносный пакет, остававшийся незамеченным три года...злоумышленники подменили популярный пакет базы данных BoltDB, используемый тысячами организаций, включая Shopify и Heroku
. . .
BoltDB, расположенный на GitHub по адресу github.com/boltdb/bolt , был создан девять лет назад и перестал обновляться спустя год после релиза. Атакующие использовали технику тайпосквоттинга, создав поддельный пакет github.com/boltdb-go/bolt. Разница в названии минимальна, но при установке подделки в проекте появляется бэкдор, позволяющий выполнять удалённый код.
. . .
Несмотря на то, что вредоносная версия оставалась доступной на Go Module Proxy в течение трёх лет, следов её массового использования не найдено. По данным Бойченко, поддельный пакет импортировался лишь дважды, причём оба раза — одним криптовалютным проектом, у которого всего семь подписчиков. Статистика скачиваний в Go не ведётся, но отсутствие звёзд и форков на GitHub за три года говорит о том, что модуль не получил широкого распространения.

Тем не менее, инцидент выявил уязвимость в системе управления пакетами Go. При первой загрузке новый пакет кешируется сервисом Go Module Mirror и остаётся доступным бессрочно. Злоумышленники воспользовались этим, сначала разместив безобидную версию, а затем изменив Git-теги, чтобы при проверке пакет выглядел легитимным. В то же время в кеше продолжала распространяться вредоносная версия.
. . .
неизменяемость модулей одновременно улучшает безопасность экосистемы и создаёт возможности для атак. Он призвал разработчиков тщательно проверять целостность пакетов перед установкой, анализировать зависимости и использовать инструменты для глубокого аудита кода.

Три года в тени: тайпсквоттинг стал угрозой для всей экосистемы Go
https://www.securitylab.ru/news/556167.php

Оригинал
Go Supply Chain Attack: Malicious Package Exploits Go Module Proxy Caching for Persistence
https://socket.dev/blog/malicious-package-exploits-go-module-proxy-caching-for-persistence

Хороший пост от Cloudflare в котором показаны примеры различных ситуаций при, по сути, одинаковом уведомлении ядра Linux о зависшей задаче.

INFO: task XXX:1495882 blocked for more than YYY seconds.
     Tainted: G          O       6.6.39-cloudflare-2024.7.3 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:XXX         state:D stack:0     pid:1495882 ppid:1      flags:0x00004002
. . .

Example #1 or XFS
. . .
Summary: In this case, nothing critical happened to the system, but the hung tasks warnings gave us an alert that our file system had slowed down.

Example #2 or Coredump
. . .
Summary: This example showed that even if everything suggests that the application is the problem, the real root cause can be something else — in this case, coredump.

Example #3 or rtnl_mutex
. . .
Summary: The hung task messages were the only ones which we had in the kernel log. Each stack trace of these messages was unique, but by carefully analyzing them, we could spot similarities and continue debugging with other instruments.

Epilogue

Your system might have different hung task warnings, and we have many others not mentioned here. Each case is unique, and there is no standard approach to debug them. But hopefully this blog post helps you better understand why it’s good to have these warnings enabled, how they work, and what the meaning is behind them. We tried to provide some navigation guidance for the debugging process as well:

- analyzing the stack trace might be a good starting point for debugging it, even if all the messages look unrelated, like we saw in example #3

- keep in mind that the alert might be misleading, pointing to the victim and not the offender, as we saw in example #2 and example #3

- if the kernel doesn’t schedule your application on the CPU, puts it in the D state, and emits the warning – the real problem might exist in the application code

Searching for the cause of hung tasks in the Linux kernel
https://blog.cloudflare.com/searching-for-the-cause-of-hung-tasks-in-the-linux-kernel/