Názory k článku
Chyba HollowByte v OpenSSL umožňuje trvale zaplnit paměť serveru

Nevíte jestli se stejná chyba projeví i v LibreSSL, nebo tam se už kód hodně liší a je bezpečné? Nepodařilo se mi to zatím dohledat.

Takze chyba je spis v glibc, nez openssl - kdyz ta knihovna dela chytristiku ktera je zneuzita.
OpenSSL v tom muze byt nevinne, kdyz radne vola free().

Nepřipadá mi že by v tom OpenSSL bylo úplně nevinně, když se nechá přesvědčit k tomu aby zbytečně alokovalo až 131 KB RAM na základě přijetí o několik řádů menšího objemu nedůvěryhodných dat. Kombinace s následným memory managementem glibc to ještě zhoršuje, ale to je zase vina OpenSSL že v tomto případě tento memory management glibc využívá místo aby použili něco lepšího.

Zřejmě máte pravdu. Z pohledu webové služby a jak se bránit Slowloris je chybou alokovat tolik paměti dopředu i když se neví že těch dat opravdu tolik dorazí (viz. oprava v podobě přírustkové alokace bufferu #30792, #30793 a #30794). Z pohledu čistě vývojářského by to neměl být problém - jakou paměť od OS dostanu tu také vrátím. Nebo snad ne? No sám jsem byl překvapen, že v případě glibc se vracená paměť vždy nemusí vrátit OS - tedy po dobu co běží proces. Popis chování glibc, jak je možné toto chování ovlivnit a případně zvolit jiný alokátor rozepisuje dobře na svém Linkedin profilu jistý Anmol TYAGI: https://www.linkedin.com/posts/anmol-tyagi-4994a612b_why-your-free-doesnt-free-memory-the-activity-7314282452087119873--Q9b.

Glibc v rámci možností vrací paměť systému a tu, kterou si drží, používá pro další alokace. Problém je v tom, že útočník má pod kontrolou fragmentaci té paměti, takže ji udržuje alokovanou a nutí alokovat další.

Jinými slovy, při nastavování parametrů programu předpokládáme, že naši službu používají slušní jedinci. Bohužel ne každý malware je z Albánie.