🥇Om en sårbarhet i…

För ett år sedan, den 21 mars 2019, i bug bounty-programmet Mail.Ru på HackerOne kom en mycket bra bugrapport från maxarr. Vid införandet av en noll-byte (ASCII 0) i POST-parametern för en av API-förfrågningarna till webbmailen, som returnerade en HTTP-redirect, syntes bitar av icke-initierat minne i redirect-datan, där det oftast förekom fragment från GET-parametrar och rubriker från andra förfrågningar till samma server.

Detta är en kritisk sårbarhet, eftersom förfrågningarna också innehåller sessionscookies. Inom några timmar gjordes en tillfällig fix som filtrerade nollbytet (som senare visade sig vara otillräckligt, eftersom möjligheten till CRLF-injektion / ASCII 13, 10 kvarstod, vilket möjliggör manipulation av rubriker och HTTP-svar, vilket är mindre kritiskt, men fortfarande otrevligt). Samtidigt överlämnades problemet till säkerhetsanalytiker och utvecklare för att identifiera och åtgärda orsakerna till buggen.

Mail.ru är en mycket komplex applikation, i formandet av svaret kan ett stort antal olika frontend/backend-komponenter delta, både öppen källkod (ett stort tack till alla utvecklare av fri programvara), och egna utvecklingar. Det lyckades utesluta alla komponenter utom nginx och openresty och lokalisera problemet till anropet ngx.req.set_uri() i OpenResty-skriptet, som inte uppträdde som förväntat (att införa noll-byte eller radbrytningar via GET-parametrar med rewrite i ngx_http_rewrite_module, som enligt dokumentationen används och som borde fungera exakt som det skulle är inte möjligt). Eventuella konsekvenser åtgärdades, strikt filtrering infördes och det kontrollerades att filtreringen eliminerade alla möjliga vektorer. Men mekanismen som ledde till läckage av minnesinnehåll förblev en gåta. En månad senare stängdes buggrapporten som löst, och analysen av orsakerna till buggen sköts upp till en senare tid.

OpenResty är en mycket populär plugin som gör det möjligt att skriva Lua-skript inuti nginx, och den används i flera projekt av Mail.ru, så problemet ansågs inte löst. Och efter en tid återvände man till det för att förstå de verkliga orsakerna, möjliga konsekvenser och formulera rekommendationer för utvecklarna. I granskningen av källkoden deltog Denis Denisov och Nikolai ErmishkinDet visade sig att:

I nginx finns det en möjlighetsbegripning för katalogtraversering (och troligtvis SSRF) i vissa konfigurationer när man använder rewrite med användardata, men detta är en känd lösning, och den bör upptäckas av statiska analysatorer av konfigurationer i Nginx Amplify och Gixy från Yandex (ja, vi använder det också, tack). När man använder OpenResty är det lätt att missa denna möjlighet, men vår konfiguration påverkades inte.
exempel på konfiguration:
```
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 läckage av minnesinnehåll om rewrite-strängen innehåller en nollbyte. När nginx ger en omdirigering allokerar det en ny minnesbuffert som motsvarar den fulla längden av strängen, men kopierar strängen via en strängfunktion där nollbytet är en strängterminator, så strängen kopieras endast fram till nollbytet och resten av bufferten innehåller oinitierade data. En detaljerad analys kan hittas här.
exempel på konfiguration (^@ nollbyte)
```
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 mot injektion av kontrolltecken och ger möjlighet att använda i rewrite endast GET-parametrar. Därför går det inte att utnyttja injektion via användarkontrollerade parametrar i nginx. POST-parametrar är däremot inte skyddade. OpenResty tillåter att arbeta både med GET- och POST-parametrar, vilket innebär att det finns möjlighet till injektion av specialtecken när man använder POST-parametrar genom OpenResty.
exempel på konfiguration:
```
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=%00asdfasdfasdfasdfasdfasdfasdfasdf" -vv ... Plats: http://localhost:8337/{...kan innehålla hemlig...} ...

Fortsatt reaktion

Problemet har rapporterats till utvecklarna av nginx och OpenResty, utvecklarna ser inte problemet som en säkerhetsbrist i nginx, eftersom det inte finns något sätt att utnyttja felet genom injektion av specialtecken, fix av läckage av minnesinnehåll publicerades den 16 december. Fyra månader efter rapporteringen har det inte heller gjorts några ändringar i OpenResty, trots att man förstod att det behövdes en säker version av funktionen ngx.req.set_uri(). Den 18 mars 2020 publicerade vi information och den 21 mars släppte OpenResty version 1.15.8.3, som lägger till kontroll av URI.

Portswigger skrev en bra artikel och jag tog kommentarer från OpenResty och Nginx (men 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 efter nollbyte och, vid avsaknad av tydliga begränsningar för längden, kan kontrolleras av en angripare).

Så vad var felet och vad kan göras för att förhindra det?

Var felet i nginx? Ja, det var det, eftersom minnesläckage ändå är ett fel.

Var det något fel med OpenResty? Ja, åtminstone har frågan om säkerheten för den funktionalitet som OpenResty erbjuder inte undersökts eller dokumenterats.

Fanns det ett konfigurations-/användningsfel i OpenResty? Ja, för i avsaknad av en tydlig angivelse gjordes en otestad antagande om säkerheten i den använda funktionaliteten.

Vilket av dessa fel utgör en säkerhetsrisk med ett bountyy på $10000? För oss är det i stort sett oviktigt. I all programvara, särskilt i skärningspunkten mellan flera komponenter, särskilt de som tillhandahålls av olika projekt och utvecklare, kan ingen någonsin garantera att alla aspekter av deras funktion är kända och dokumenterade och att det inte finns några fel. Därför uppstår varje säkerhetsrisk där den påverkar säkerheten.

I vilket fall som helst är det en bra praxis att normalisera eller begränsa/filtera indata som går till något externt modul/API, om det inte finns tydliga angivelser och en entydig förståelse av att detta inte är nödvändigt.

Errata

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

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

Källa: habr.com