🥇Om en sårbarhet i…

För ett år sedan, den 21 mars 2019, i Mail.Ru:s bug bounty-program on HackerOne kom det en mycket bra bugrapport från maxarr. Vid införandet av null-byte (ASCII 0) i POST-parametern för en av API-frågorna från webbmailen, som returnerade en HTTP-omdirigering, sågs bitar av icke initierat minne där fragment från GET-parametrar och huvuden från andra förfrågningar till samma server oftast visades.

Detta är en kritisk sårbarhet, då förfrågningarna även innehåller sessionscookies. Inom några timmar gjordes en temporär fix som filtrerade bort null-byte (som det senare visade sig var otillräckligt, eftersom möjligheten till CRLF/ASCII 13, 10-injektion fortfarande kvarstod, vilket möjliggör manipulation av huvud och data i HTTP-svaret, något som är mindre kritiskt men fortfarande obehagligt). Samtidigt överlämnades problemet till säkerhetsanalytiker och utvecklare för att hitta och åtgärda orsakerna till buggen.

Mail.ru:s e-post är en mycket komplex applikation där många olika frontend/backend-komponenter kan vara involverade, både öppen källkod (stort tack till alla utvecklare av fri programvara) och egna utvecklingar. Det lyckades utesluta alla komponenter förutom nginx och openresty och lokalisera problemet till anropet ngx.req.set_uri() i OpenResty-skriptet, som inte fungerade som förväntat (att införa null-byte eller radbyte via GET-parametrar med omskrivning i ngx_http_rewrite_module, som enligt dokumentationen används och som borde fungera helt likadant, gick inte). Eventuella konsekvenser har åtgärdats, strikt filtrering har lagts till och det har kontrollerats att filtreringen eliminerar alla möjliga vektorer. Men mekanismen som ledde till läckage av minnesinnehåll förblev en gåta. Efter en månad stängdes buggrapporten som löst, medan analysen av orsaken till buggen sköts upp till bättre tider.

OpenResty är en mycket populär plugin som möjliggör skrivande av Lua-skript inuti nginx, och den används i flera projekt av Mail.ru, så problemet ansågs inte vara löst. Och efter en tid återkom man till det för att förstå de verkliga orsakerna, möjliga konsekvenser och skapa rekommendationer för utvecklarna. I granskningen av källkoden deltog Denis Denisov och Nikolaj Ermiškin. Det har visat sig att:

I nginx, vid användning av rewrite med användardata, finns det en möjlighet för directory traversal (och sannolikt SSRF) i vissa konfigurationer, men detta är en känd fråga och bör upptäckas av statiska konfigurationsanalysatorer i Nginx Amplify och Gixy från Yandex (ja, vi använder det också, tack). Vid användning av OpenResty kan denna möjlighet lätt missas, men vår konfiguration påverkades inte.
exempelkonfiguration:
```
location ~ /rewrite {
    rewrite ^.*$ $arg_x;
}

location / {
    root html;
    index index.html index.htm;
}
```
resultatet
curl localhost:8337/rewrite?x=/../../../../../../etc/passwd root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin ...
I nginx finns det ett fel som leder till minnesläckage om rewrite-strängen innehåller en null-byte. Vid omdirigering allokerar nginx en ny minnesbuffer som motsvarar hela längden på strängen, men kopierar strängen med en strängfunktion där null-byte är terminatorn för strängen, vilket gör att strängen endast kopieras fram till null-byte, resten av buffern innehåller oinitialiserade data. En detaljerad analys kan hittas här.
exempelkonfiguration (^@ null-byte)
```
location ~ /memleak {
    rewrite ^.*$ "^@asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdasdf";
}

location / {
    root html;
    index index.html index.htm;
}
```
resultatet
curl localhost:8337/secret -vv ... curl localhost:8337/memleak -vv ... Location: http://localhost:8337/secret ...
Nginx skyddar GET-parametrar från injektion av kontrolltecken och ger möjlighet att använda i rewrite endast GET-parametrar. Därför är det inte möjligt att utnyttja injektion genom kontrollerade användarparametrar i nginx. POST-parametrar är dock inte skyddade. OpenResty tillåter arbete med både GET och POST-parametrar, så vid användning av POST-parametrar genom OpenResty uppstår möjligheten för injektion av specialtecken.
exempelkonfiguration:
```
location ~ /memleak {
    rewrite_by_lua_block {
        ngx.req.read_body();
        local args, err = ngx.req.get_post_args();
        ngx.req.set_uri( args["url"], true );
    }
}

location / {
    root html;
    index index.html index.htm;
}
```
resultat:
curl localhost:8337 -d "url=hemlig" -vv ... curl localhost:8337 -d "url=asdfasdfasdfasdfasdfasdfasdfasdf" -vv ... Plats: http://localhost:8337/{...kan innehålla hemlig...} ...

Vidare åtgärder

Problemet har rapporterats till utvecklarna av nginx och OpenResty, utvecklarna betraktar inte problemet som en säkerhetsbrist i nginx, eftersom det inte finns någon möjlighet att utnyttja felet genom injektion av specialtecken; fix av avslöjande av minnesinnehåll publicerades den 16 december. Under de fyra månader som gått sedan rapporteringen har det inte heller skett några förändringar i OpenResty, trots förståelse för att en säker version av funktionen ngx.req.set_uri() var nödvändig. Den 18 mars 2020 publicerade vi information, den 21 mars släppte OpenResty version 1.15.8.3, som lägger till kontroller av URI.

Portswigger skrev en bra artikel och tog kommentarer från OpenResty och Nginx (även om kommentaren om att endast en liten del av minnet avslöjas är felaktig och missledande, detta bestäms av längden på strängen som följer nollbyte och, i avsaknad av uppenbara begränsningar av längden, kan kontrolleras av en angripare).

Vad var felet och vad gör vi för att förhindra det?

Var felet i nginx? Ja, det var det, eftersom en minnesläcka i alla avseenden är ett fel.

Var det fel i OpenResty? Ja, minst sagt var frågan om säkerheten i den funktionalitet som erbjuds av OpenResty inte undersökt och dokumenterad.

Var det en konfigurations-/användarfel i OpenResty? Ja, eftersom i avsaknad av ett uttryckligt angivet, gjordes en obekräftad antagelse om säkerheten i den använda funktionaliteten.

Vilket av dessa fel är en säkerhetsrisk med en bountykostnad på $10000? För oss spelar det i stort sett ingen roll. I all mjukvara, särskilt i skärningspunkten av flera komponenter, särskilt som tillhandahålls av olika projekt och utvecklare, kan ingen och aldrig garantera att alla aspekter av deras arbete är kända och dokumenterade och att det inte finns några fel. Därför uppstår varje säkerhetsrisk precis där den påverkar säkerheten.

I alla fall, det är en bra praxis att normalisera eller maximalt begränsa/filtera indata som går till någon extern modul/API, om det inte finns några tydliga riktlinjer och en entydig förståelse av att det inte behövs.

Errata

Enligt erfarenhet den tidigare artikeln, för att bevara språkets renhet:

bug bounty — en tävling för att upptäcka fel
bugrapport — felanmälan
redirect — omdirigering
öppen källkod — med öppen källkod
errata — arbete med fel

Källa: habr.com