Блог*
#prog #rust #article ROFL with a LOL: rewriting an NGINX module in Rust
#prog #article
В статье не особо рассказано про то, что именно переписали.
В статье A History of HTML Parsing at Cloudflare: Part 1 рассказывается, как в Cloudflare перешли от отдельных модулей для переписывания ответа серверов (например, замены http на https в ссылках) на отдельный единый фреймворк для потокового парсинга и переписывания HTML, который впоследствии и был опубликован под названием lazyhtml. Также описываются трудности, которые стояли перед этим парсером, и некоторые трюки, которые помогли повысить производительность. В частности, использование своего варианта арифметического кодирования позволило переводить теги в 5-битное число и таким образом сравнивать теги без чувствительности к регистру за констатное время.
В статье A History of HTML Parsing at Cloudflare: Part 2 рассказывается о новой, переписанной версии этого фреймворка, которая получила название LOL HTML (low output latency HTML). Одним из причин переписывания было желание предоставить доступ к выразительному API для динамического переписывания HTML внутри Cloudflare workers. Архитектура lazyhtml предполагала постоянную передачу данных через границу FFI, что было достаточно дорогим, чтобы потенциально свести на нет весь выигрыш в производительности от использования нативного языка.
Переписанный вариант использует синтаксис, схожий с селекторами CSS, для матчинга нужных фрагментов текста, вместо ручного матчинга по нужным свойствам токенов в пользовательских коллбеках, что не только более эргономично, но и позволило провести некоторые оптимизации. Одна из них — деление стейт-машины парсера на подробный парсер, который парсит все теги, и более простой т. н. tag scanner, который на каждый распознанный тег ищет соответствующий закрывающий, игнорируя содержимое документа между ними. За счёт того, что пользователь задаёт паттерны наперёд декларативно, этот подход позволяет безопасно пропускать обработку тех фрагментов текста, в которых пользователь не заинтересован.
Более того, lolhtml может эксплуатировать тот факт, что у заданных пользователем паттернов есть общие префиксы, что позволяет объединить часть работы над распознаванием нужных фрагментов и не проводить её заново по несколько раз.
Обе статьи более подробны, чем я расписал в своём обзоре, так что рекомендую к прочтению.
В статье не особо рассказано про то, что именно переписали.
В статье A History of HTML Parsing at Cloudflare: Part 1 рассказывается, как в Cloudflare перешли от отдельных модулей для переписывания ответа серверов (например, замены http на https в ссылках) на отдельный единый фреймворк для потокового парсинга и переписывания HTML, который впоследствии и был опубликован под названием lazyhtml. Также описываются трудности, которые стояли перед этим парсером, и некоторые трюки, которые помогли повысить производительность. В частности, использование своего варианта арифметического кодирования позволило переводить теги в 5-битное число и таким образом сравнивать теги без чувствительности к регистру за констатное время.
В статье A History of HTML Parsing at Cloudflare: Part 2 рассказывается о новой, переписанной версии этого фреймворка, которая получила название LOL HTML (low output latency HTML). Одним из причин переписывания было желание предоставить доступ к выразительному API для динамического переписывания HTML внутри Cloudflare workers. Архитектура lazyhtml предполагала постоянную передачу данных через границу FFI, что было достаточно дорогим, чтобы потенциально свести на нет весь выигрыш в производительности от использования нативного языка.
Переписанный вариант использует синтаксис, схожий с селекторами CSS, для матчинга нужных фрагментов текста, вместо ручного матчинга по нужным свойствам токенов в пользовательских коллбеках, что не только более эргономично, но и позволило провести некоторые оптимизации. Одна из них — деление стейт-машины парсера на подробный парсер, который парсит все теги, и более простой т. н. tag scanner, который на каждый распознанный тег ищет соответствующий закрывающий, игнорируя содержимое документа между ними. За счёт того, что пользователь задаёт паттерны наперёд декларативно, этот подход позволяет безопасно пропускать обработку тех фрагментов текста, в которых пользователь не заинтересован.
Более того, lolhtml может эксплуатировать тот факт, что у заданных пользователем паттернов есть общие префиксы, что позволяет объединить часть работы над распознаванием нужных фрагментов и не проводить её заново по несколько раз.
Обе статьи более подробны, чем я расписал в своём обзоре, так что рекомендую к прочтению.
The Cloudflare Blog
A History of HTML Parsing at Cloudflare: Part 1
This post reviews the history of HTML rewriting at Cloudflare, replacing a collection of ‘ad-hoc’ parsers with a HTML5 spec-compliant pluggable rewriter.
👍4
ОРУ, СЭР!
В твиттере запустили тренд — спрашивать близких, любили бы их, если бы они были червем
Папищеки, а вы бы любили меня, если бы я был червём?
🤔9🍌7
Кстати, в это воскресенье у вашего любимого (я надеюсь ) админа день рождения 👀
🎉22🤣2
Блог*
Кстати, в это воскресенье у вашего любимого (я надеюсь ) админа день рождения 👀
Как насчёт встретиться завтра в 18:00 в Vol. 1? На этот раз повод весомый
🤣10🖕3😢2🤡2
#itsec
Вот
TL;DR (отсюда):
The xz/liblzma project has released versions 5.6.0 and 5.6.1.
The combination of this and patches made by some distributions to the interactions between liblzma, libsystemd, and sshd have resulted in a situation where an attacker can compromise a system by sending a malicious payload to an sshd server.
We are lucky. This only affects AMD64 Linux systems. Currently, incomplete analysis of the vulnerability suggests that this only targets a specific RSA function used in sshd. The exploit is in the wild [выделение моё]. This is also a very new version of xz/liblzma, so it is not widely deployed yet. This is also unlikely to affect anything other than Glibc (because of glibc IFUNC support), so if you use musl or another libc implementation, you are likely safe.
If you are using a distribution that has not yet released xz 5.6.0 or 5.6.1, you are likely safe.
Примечательно, что нагрузка, которая используется для внедрения эксплоита, была добавлена в исходники, как набор тестовых бинарных файлов, а внедряется вредоносная нагрузка в процессе исполнения скрипта configure. Все изменения, необходимые для того, чтобы сделать эксплоит возможным, были внесены различными коммитами на протяжении двух лет.
(thanks @tech_b0lt_Genona)
Вот
TL;DR (отсюда):
The xz/liblzma project has released versions 5.6.0 and 5.6.1.
The combination of this and patches made by some distributions to the interactions between liblzma, libsystemd, and sshd have resulted in a situation where an attacker can compromise a system by sending a malicious payload to an sshd server.
We are lucky. This only affects AMD64 Linux systems. Currently, incomplete analysis of the vulnerability suggests that this only targets a specific RSA function used in sshd. The exploit is in the wild [выделение моё]. This is also a very new version of xz/liblzma, so it is not widely deployed yet. This is also unlikely to affect anything other than Glibc (because of glibc IFUNC support), so if you use musl or another libc implementation, you are likely safe.
If you are using a distribution that has not yet released xz 5.6.0 or 5.6.1, you are likely safe.
Примечательно, что нагрузка, которая используется для внедрения эксплоита, была добавлена в исходники, как набор тестовых бинарных файлов, а внедряется вредоносная нагрузка в процессе исполнения скрипта configure. Все изменения, необходимые для того, чтобы сделать эксплоит возможным, были внесены различными коммитами на протяжении двух лет.
(thanks @tech_b0lt_Genona)
Gist
xz-utils backdoor situation (CVE-2024-3094)
xz-utils backdoor situation (CVE-2024-3094). GitHub Gist: instantly share code, notes, and snippets.
🔥11❤1👍1🤯1😱1