Цього тижня в розділі «Безпека»: Git Deep Dive, Mailchimp і SPF

Цього тижня в розділі «Безпека»: Git Deep Dive, Mailchimp і SPF

Мітка часу: 20 січня 2023 р., 10:00 ранку
Вихідний вузол: 1910203

Спочатку, git пройшов аудит. Це було спонсоровано Фондом удосконалення технологій з відкритим кодом (OSTIF), некомерційною організацією, яка працює над підвищенням безпеки проектів з відкритим кодом. Сам аудит проводили дослідники з X41 і GitLab виявлено дві критичні вразливості, обидва спричинені тією самою поганою звичкою кодування — використанням an int для зберігання довжини буфера.

У сучасних системах a size_t завжди без знаку та такої ж довжини в бітах, що й бітова ширина архітектури. Це правильний тип даних для рядка та довжини буфера, оскільки він гарантовано не переповнюється під час обробки довжини до максимальної адресної пам’яті в системі. З іншого боку, ан int зазвичай має довжину чотири байти та має знак із максимальним значенням 2^31-1 або 2147483647 — близько 2 ГБ. Великий буфер, але не нечувана кількість даних. Киньте щось таке велике в git, і воно зламається несподіваним чином.

Наш перший приклад — CVE-2022-23521, запис поза межами, викликаний int переливається в негатив. А .gitattributes файл може бути зафіксований у сховищі за допомогою модифікованого клієнта git, а потім перевірка цього сховища призведе до num_attrs змінна для переповнення. Зіштовхніть переповнення до невеликого від’ємного числа, і git тоді значно занизить буфер атрибутів і запише всі ці дані після кінця виділеного буфера.

CVE-2022-41903 — це ще одне переповнення цілого числа зі знаком, цього разу, коли красивий формат друку зловживають, щоб зробити щось несподіване. Подивіться на цей блок коду:

 int sb_len = sb->len, offset = 0; if (c->flush_type == flush_left) offset = padding - len; else if (c->flush_type == flush_both) offset = (padding - len) / 2; /* * we calculate padding in columns, now * convert it back to chars */ padding = padding - len + local_sb.len; strbuf_addchars(sb, ' ', padding); memcpy(sb->buf + sb_len + offset, local_sb.buf, local_sb.len);

Формат експлойту виглядав би приблизно так %>(2147483647)%a%>(2147483646)%x41, де наведений вище код виконується для кожного екземпляра доповнення (The %>(#) блоків), знайдених у форматі. Перший раз через цей код додає (2^31)-1 пробіли до початку вихідного рядка. Це число є максимальним значенням чотирибайтового цілого числа зі знаком. Але наведений вище блок коду запускається в інший раз, і ще один текст додається до буфера, що збільшує його довжину над максимальним цілим значенням. Перший рядок цього блоку виконує неявне приведення size_t до int, налаштування sb_len до від’ємного значення.

Тоді в memcpy() дзвоніть, sb->buf є покажчиком на початок буфера, sb_len є нашим переповненим великим від’ємним числом, а offset буде значенням, яким керує користувач. Це означає місце призначення, куди відправляється memcpy() може ненавмисно бути встановлено на нижчу область пам'яті, ніж початок передбачуваного буфера. Контрольований зловмисником пише. Я додав деякі налагоджувальні оператори printf() до цього текстового блоку та запустив тестовий приклад:

$ ./bin-wrappers/git log -1 --pretty="format:%>(2147483647)%a%>(2147483635)%s" >/dev/null
Padding: 2147483647
sb_len: 0
offset: 2147483647
Memcpy: Padding: 2147483635
sb_len: -2147483647
offset: 2147483591
Memcpy: CI: upgrade to macos-12, and pin OSX version
=================================================================
==844038==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd8989f97c8 at pc 0x7fdb15e49d21 bp 0x7ffe8fa5c100 sp 0x7ffe8fa5b8b0
WRITE of size 44 at 0x7fd8989f97c8 thread T0
0x7fd8989f97c8 is located 56 bytes to the left of 4831838268-byte region [0x7fd8989f9800,0x7fd9b89f983c)

Перший квартет вихідних даних — це налаштування, заповнюючи рядок журналу заповненням, щоб мати максимальну довжину int. Другий квартет - переповнення буфера, де sb_len встановлюється на від’ємне значення, а потім додається до зсуву, щоб отримати розташування 56 байтів ліворуч від початку буфера. Вміст, який друкується в цьому місці, знаходиться в цьому випадку %s, який замінюється рядком теми коміту — довжиною 44 байти. Автори припускають, що це може бути зброєю проти «кузні git», AKA GitHub і GitLab, оскільки ці програмні пакети запускають команду git archive, яка може викликати керований користувачем красивий рядок.

Виправлення були внесені у вихідний код git ще 8 грудня, але нові випуски, що містять ці виправлення, доступні лише зараз. Є приблизно 2200 екземплярів raw int проблеми, і для їх усунення знадобиться деякий час, навіть за допомогою деяких цікавих прийомів, як-от cast_size_t_to_int(), вбудована функція, яка просто вбиває програму, якщо 2 ГБ+ size_t обробляється. Тож оновлюйся!

Mailchimp — Знову

Здається, люди в Mailchimp не можуть відпочити зловмисники знову отримали доступ до їхніх інструментів внутрішнього адміністрування, що призвело до викриття 133 облікових записів клієнтів, у тому числі WooCommerce. Це вже третій випадок, коли Mailchimp зазнає атаки соціальної інженерії або фішингу за останній рік, і кожного разу кінцевим користувачам надсилаються електронні листи з фішингом. Отже, якщо ви є в будь-якому списку розсилки Mailchimp, пам’ятайте про це порушення наступного разу, коли надійде відповідний електронний лист. (Примітка редактора: два інформаційні бюлетені Hackaday використовують Mailchimp, і ми не отримали сповіщення, тому ми вважаємо, що все добре.)

Програма-вимагач Royal Mail

В історії, яка може мати великі наслідки, Королівська пошта Великобританії зазнала атаки програм-вимагачів на їх системі обробки міжнародної пошти. Атака використовує програмне забезпечення-вимагач Lockbit, угруповання, яке підозрюється як російськомовне угруповання програм-вимагачів. Це може мати велике значення, оскільки атака на справжню державну установу набагато серйозніша, ніж атака на бізнес. Оскільки Lockbit працює як програма-вимагач як послуга, буде дуже важко визначити, хто саме здійснив атаку. Наразі рекомендація проста: не надсилайте міжнародної пошти. Ой.

Сканування записів SPF

[Себастьян Салла] має те, що можна вважати дивним хобі, у формі сканування записів SPF на наявність дивних неправильних конфігурацій. У його останній пригоді це сканування потрапило до 3 мільйонів найбільш відвідуваних доменів. І була виявлена ​​неправильна конфігурація.

Але почекайте, що таке SPF і чому це нас цікавить? Sender Policy Framework – це запис txt, який є частиною DNS-записів домену. І вказує, які IP-адреси насправді авторизовані для надсилання електронної пошти для цього домену. Отже, якщо вхідний електронний лист стверджується, що він надійшов із домену з дійсним записом SPF, а IP-адреса відправника не вказана в цьому записі, цілком очевидно, що він насправді не з заявленого домену.

І відхилення електронних листів вашого домену через проблему SPF є одним із найнадійніших способів зловити збій. Тож є спокуса зробити запис SPF трохи більш … *ліберальним*, ніж, можливо, має бути. І найекстремальніша ітерація цього – просто дати ляпаса +all на свій запис SPF і закінчити з цим. Звичайно, це повідомляє світові, що кожен спамер будь-де, який використовує ваш домен, насправді надсилає справжні електронні листи, але принаймні вихідні електронні листи боса знову працюють. З понад тисячею доменів, налаштованих на SPF +all, мабуть, це більш поширена помилка, ніж очікувалося.

Справді цікавим є те, хто є хто з цих неправильно налаштованих доменів, як-от численні урядові установи США, інші державні домени по всьому світу та численні університети. Найцікавішим було Міністерство оборони України, де запис ФДМ було вирізано з а -all до +all приблизно 4 місяці тому.

Біти та байти

Tailscale виявив потенційно серйозну проблему, через яку, знаючи ідентифікатор вузла іншого клієнта, зловмисник міг би додати вузол до своєї власної кінцевої мережі. Це призвело б до того, що зловмисник проникне всередину вашої VPN, безумовно, поганий сценарій. Але перш ніж ви отримаєте свої вила, уразливий код був розгорнутий менше чотирьох місяців, перш ніж його виправили. Про це приватно повідомили 11 числа цього місяця, а зафіксували 12 числа. І на додаток, атака залишає підпис журналу, який Tailscale зміг просканувати, і дійшов висновку, що він був ізольований для тестування доказу концепції. Ви можете перевірити свою власну інформаційну панель на предмет будь-яких вузлів, наданих спільно з їх власною хвостовою мережею для підтвердження. І хоча це неприємна вразливість, добре для Tailscale, щоб розкрити її. Багато постачальників сиділи б на цьому і ніколи не оприлюднювали його.

Команда Ядро Linux мало переповнення буфера у своєму коді Netfilter, де переповнення буфера може призвести як до витоку даних, так і до виконання коду. Шляху до віддаленого використання не існує, але електронний лист, на який посилається вище, містить повний PoC для локальної ескалації привілеїв. І якщо вам подобається експлуатація ядра, Google Project Zero має новий запис на цю тему, все про нульове розіменування.

І якщо ви використовуєте ManageEngine від Zoho, то сьогодні ваше волосся може спалахнути, якщо ви не оновилися до випуску, який виправляє CVE-2022-47966. Дослідники в Horizon3 переробив патч, і розповсюдив цей RCE. Це проблема в тому, як реалізовано систему єдиного входу SAML, частково через надзвичайно стару бібліотеку, яка є частиною продукту. Це досить простий експлойт, тож час ще раз перевірити ці встановлення!

Часова мітка:

Більше від Рубати день