Worthy tech news
6 subscribers
141 photos
4 videos
1 file
1.02K links
Download Telegram
Forwarded from Тысяча фичей
Делюсь тем, как ебашу проекты.

👹 Project Hub 👹 — шаблон репозитория-«кабины» для ведения проекта с Claude Code: глоссарий, инварианты, ADR-решения, живой статус, каталог сервисов, подключение реп симлинками, параллельные агенты в git worktree, safety-hook перед прод-командами.

Скопируй промпт и вставь в Claude Code — расспросит про проект и соберёт хаб под тебя:

Create a project hub from this template: https://github.com/PakhomovAlexander/project-hub



https://github.com/PakhomovAlexander/project-hub

Пост, где я рассказываю как это работает: https://t.me/toxic_enterprise/369
Please open Telegram to view this post
VIEW IN TELEGRAM
chDB SQL Shell
https://wasm.chdb.io/

ClickHouse WebAssembly
Phoronix

ReactOS Implements First Windows NT6 System Call In Step Toward Vista Compatibility

The ReactOS project that is striving to be the "open-source Windows" with Windows driver and software binary compatibility hit another milestone today. ReactOS to date has primarily targeted Windows NT 5.2 as the architecture from Windows XP and Windows Server 2003 but with an eye toward Windows NT 6.0 for Windows Vista and later compatibility with software. ReactOS has now landed their first NT6 system call...

2026-07-03 06:22:38 +06:00

https://www.phoronix.com/news/ReactOS-First-NT6-Syscall
Forwarded from TheCacheWorks
​​Линия жизни

Проблема DF (double free)/UAF (use-after-free) в действительности глубже, чем может показаться.

Причем эта кроличья нора мало того, что бездонная - она тщательно замаскирована и угодить в нее можно буквально где угодно и почти на каждом шагу.

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

Если объяснять совсем на пальцах, в языках с ручным управлением памятью, память - разумеется - не может знать, сколько на нее смотрит указателей из разных мест кода. Сырые указатели штука тупая и циничная. Это просто адрес ячейки или блока.

Считать указатели в обертках (shared_ptr) накладно и в горячих путях дорого. Счетчики, блокировки. Наворачивать слои безопасности при работе с памятью - чрезвычайно дорого.

Проблема усугубляется тем фактом, что в том же C++ на сырых указателях под капотом много чего строится - наследование, полиморфизм, vtable - и заменить всё это на умные указатели (которые тоже вовсе не панацея) или на ссылки не получится по определению, совместимость и гигатонны работающего кода. Что касается Си, то там указатели буквально фундамент всей и всяческой алгоритмики.

Суть проблемы, однако же, даже не в этом. А в том, что нижележащий слой - libC, системные и мажорные аллокаторы - проблему прячут и прячут глубоко в своем бэкэнде.

Теоретически аллокатор должен предоставлять один железный контракт - после free() память считается не твоей, всё, забудь о ней. Сразу же, незамедлительно, как только произошел возврат из free(). И правильно занулить указатель, потому что повторный free(NULL) - по POSIX - не бросит исключения или сегфолта и просто молча ничего не выполнит. Это не абсолютная защита, но хотя бы кое-что.

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

Так DF плавно превращается в UAF, что уже значительно хуже. Представили, да, извлечение приватных данных из памяти?

Так что АНБ напрасно мутит воду с безопасными языками программирования. Во-первых, никто не станет переписывать этит самые гигатонны работающего кода. Во-вторых, кто посмеет хоть пальцем тронуть системные аллокаторы?

Снова и снова - никакие костыльные защиты не спасают. Они либо чрезвычайно дороги в плане оверхеда, либо фрагментарны, либо бесполезны.

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

Статический анализ малоэффективен. Санитайзеры очень тяжеловесны (а чего вы ожидали?) и нацелены, в общем, на другое.

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

С тем, чтобы приложение, в случае DF/UAF, немедленно грохнулось в дамп, и чтобы в дампе на стеке было то самое место, где DF/UAF произошел.

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

По очевидной причине, которую все понимают - такие ошибки это буквально приглашение к RCE. Ведь понимают? Ведь правда?
J-jaeyoung/bad-epoll
https://github.com/J-jaeyoung/bad-epoll

Bad Epoll (CVE-2026-46242) is a race-condition use-after-free in the Linux kernel's epoll subsystem. This bug lets an unprivileged process become root, not only on Linux desktops and servers but also on Android devices.
Forwarded from Hacker News
CPUs Aren't Dead. Gemma2B Out Scored GPT-3.5 Turbo on Test That Made It Famous
Article, Comments