Уязвимость позволяет осуществить подстановку SQL-кода в GitHub

Уязвимость позволяет осуществить подстановку SQL-кода в GitHub

Уязвимость позволяет осуществить подстановку SQL-кода в GitHub

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

В описании уязвимости приводится заслуживающий внимания рассказ об организации работы кода GitHub Enterprise, который во многом пересекается с кодом публичного сервиса GitHub. Пакет поставляется в виде образа виртуальной машины, доступной для бесплатного ознакомительного использования в течение 45 дней. Исходные тексты скрыты и поставляются в упакованном виде, напоминающем зашифрованный набор данных. Прозрачная распаковка в момент выполнения осуществляется при помощи библиотеки ruby_concealer.so, анализ которой показал, что метод упаковки сводится к сжатию кода при помощи Zlib::Inflate::inflate и применению операции XOR с предопределённым ключом, пишет opennet.ru.

После распаковки было выяснено, что большая часть кода написана на языке Ruby с использованием фреймворков Ruby on Rails и Sinatra, но также применяются компоненты на Python, Bourne Shell, C++ и Java. По мнению исследователя безопасности, код, отвечающий за работу web-сервисов, основан на реальной кодовой базе github.com, gist.github.com, render.githubusercontent.com и api.github.com. Получив доступ к коду исследователь, до этого не имевший дело c языком Ruby, потратил всего четыре дня на поиск возможных уязвимостей и выявил проблему в обработчике PreReceiveHookTarget, позволяющую осуществить подстановку SQL-кода через передачу специально оформленных данных через параметр "sort", отправив запрос к общедоступному Web API.

$ curl -k -H 'Accept:application/vnd.github.eye-scream-preview' \
'https ://192.168.187.145/api/v3/organizations/1/pre-receive-hooks?access_token=????????&sort=id,(select+1+from+information_schema.tables+limit+1,1)'
$ curl -k -H 'Accept:application/vnd.github.eye-scream-preview' \
'https ://192.168.187.145/api/v3/organizations/1/pre-receive-hooks?access_token=????????&sort=id,if(user()="github @localhost",sleep(5),user())'

GitHub был уведомлен о проблеме в конце декабря и устранил уязвимость в выпуске GitHub Enterprise 2.8.5. Выявившему уязвимость исследователю выплачено вознаграждение в размере 5 тысяч долларов США.

Фоновая служба Windows 11 может тайно съедать гигабайты ОЗУ

Microsoft снова заставила пользователей Windows 11 присматриваться к системным службам. На этот раз поводом стало изменение поведения одного из сервисов в Windows 11 24H2, 25H2 и Windows Server 2025 — теперь он запускается по умолчанию и может постоянно работать в фоне, а не только «по требованию». Это сразу вызвало опасения: не приведёт ли такой подход к лишней нагрузке на систему?

На фоне обсуждений среди участников форума Neowin всплыл старый знакомый — служба Delivery Optimization.

Один из постоянных участников форума с иронией заметил, что «хуже уже не будет, если только это не Delivery Optimization, которая иногда просто съедает всю память и сидит так ради удовольствия».

И почти сразу после этого пользователь на площадке Reddit подтвердил, что шутка не так уж далека от реальности. Он провёл собственное наблюдение за работой Delivery Optimization (DoSvc) и обнаружил, что со временем служба начинает потреблять всё больше оперативной памяти — заметно больше, чем другие системные процессы. По его словам, такая картина наблюдается уже около месяца и очень напоминает утечку памяти.

Delivery Optimization — это служба, которая отвечает за доставку обновлений Windows и приложений из Microsoft Store. Она работает по принципу P2P: компьютер может не только загружать обновления с серверов Microsoft, но и получать их от других устройств в локальной сети или даже в интернете. В теории это должно экономить трафик и ускорять обновления, но на практике сервис иногда ведёт себя слишком прожорливо.

Проблема в том, что при длительной работе Delivery Optimization может постепенно накапливать использование ОЗУ и не спешит его освобождать. Да, функцию можно ограничить или полностью отключить в настройках Центра обновления Windows, но по умолчанию она включена — и далеко не все пользователи знают, что именно она грузит систему.

На этом фоне решение Microsoft отложить внедрение ещё одной автоматической функции обновлений до 2026 года выглядит уже не таким странным. Компания прямо сослалась на отзывы пользователей и администраторов. А рекомендация иметь минимум 16 ГБ оперативной памяти для «игровых ПК» теперь звучит не как маркетинг, а как суровая необходимость.

RSS: Новости на портале Anti-Malware.ru