За една уязвимост в…

Преди година, на 21 март 2019 г., в програмата за откриване на бъгове на Mail.Ru в HackerOne постъпи много добро багрепорт от maxarr. При внедряване на нулев байт (ASCII 0) в POST параметър на един от API заявките на уеб пощата, която връщаше HTTP пренасочване, в данните на пренасочването се появяваха парчета неинициализирана памет, в които най-често се разкриваха фрагменти от GET параметри и заглавки на други заявки към същия сървър.

Това е критична уязвимост, тъй като заявките съдържат и сесийни бисквитки. След няколко часа бе направено временно решение, което филтрираше нулевия байт (както впоследствие се оказа, това беше недостатъчно, тъй като оставаше възможност за инжекция на CRLF / ASCII 13, 10, което позволява манипулиране на заглавките и данните на HTTP отговора; това е по-малко критично, но все пак неприятно). В същото време проблемът беше предаден на аналитици по сигурността и разработчиците за проучване и отстраняване на причините за възникването на бъга.

Пощата Mail.ru е много сложен инструмент, при формирането на отговор може да участват голямо количество различни фронтенд/бекенд компоненти, както с отворен код (благодарим на всички разработчици на свободен софтуер), така и собствени разработки. Успяхме да изключим всички компоненти освен nginx и openresty и да локализираме проблема до извикването ngx.req.set_uri() в OpenResty скрипта, който не се държеше така, както се очакваше (не е възможно да вкарате нулев байт или нов ред чрез GET параметри с презапис в ngx_http_rewrite_module, който според документацията се използва и би трябвало да работи идентично). Бяха отстранени възможните последици, добавено беше максимално строго филтриране и беше проверено, че филтрирането премахва всички възможни вектори. Но механизмът, който водеше до изтичане на съдържание на паметта, остана загадка. След месец бъгрепортът беше затворен като разрешен, а анализът на причините за възникването на бъга беше отложен за по-добри времена.

OpenResty е доста популярен плъгин, позволяващ писането на Lua скриптове вътре в nginx, и той се използва в няколко проекта на Mail.ru, затова проблемът не се считаше за решен. И след известно време отново се върнаха на него, за да разберат истинските причини, възможните последствия и да съставят препоръки за разработчиците. В разкопките на изходния код участваха Денис Денисов и Николай ЕрмишкинУстановено е, че:

• В nginx, при използване на rewrite с потребителски данни, има възможност за directory traversal (и вероятно SSRF) в някои конфигурации, но това е известен факт и трябва да бъде открито от статичните анализатори на конфигурации в Nginx Amplify и Gixy от Яндекс (да, ние също го използваме, благодаря). При използване на OpenResty, тази възможност лесно може да се пропусне, но нашата конфигурация не е засегната.

  примерна конфигурация:

  location ~ /rewrite {
      rewrite ^.*$ $arg_x;
  }
  
  location / {
      root html;
      index index.html index.htm;
  }

  резултат

  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
...

• В nginx има грешка, която води до изтичане на паметта, ако редът rewrite съдържа нулев байт. При обработка на редирект, nginx отделя нов буфер памет, съответстващ на пълната дължина на реда, но копира реда чрез стрингова функция, в която нулевият байт е терминатор на реда, поради което редът се копира само до нулевия байт, а остатъкът от буфера съдържа неинициализирани данни. Подробен анализ може да бъде намерен тук.

  примерна конфигурация (^@ нулев байт)

  
  location ~ /memleak {
      rewrite ^.*$ "^@asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdasdf";
  }
  
  location / {
      root html;
      index index.html index.htm;
  }

  резултат
  curl localhost:8337/secret -vv
...
curl localhost:8337/memleak -vv
...
Location: http://localhost:8337/secret
...


• Nginx защитава GET параметрите от инжекция на служебни символи и дава възможност за използване в rewrite само на GET параметри. Следователно, експлоатирането на инжекция чрез контролирани от потребителя параметри в nginx не е възможно. POST параметрите обаче не са защитени. OpenResty позволява работа и с GET, и с POST параметри, затова при използване на POST параметри през OpenResty се появява възможност за инжекция на специални символи.

  примерна конфигурация:

  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;
  }
  

  резултат:

  curl localhost:8337 -d "url=secret" -vv
...
curl localhost:8337 -d "url=asdfasdfasdfasdfasdfasdfasdfasdf" -vv
...
Location: http://localhost:8337/{...може да съдържа secret...}
...


Следваща реакция

Проблемът беше докладван на разработчиците на nginx и OpenResty, разработчиците не разглеждат проблема като грешка в сигурността в nginx, тъй като в самия nginx няма възможност за експлоатация на грешката чрез инжекция на специални символи, поправка изтичане на съдържанието на паметта беше публикувана на 16 декември. За 4 месеца от момента на репорта, в OpenResty също не бяха направени никакви промени, въпреки че имаше разбирателство, че е необходима безопасна версия на функцията ngx.req.set_uri(). На 18 март 2020 публикувахме информация, на 21 март OpenResty издаде версия 1.15.8.3, която добавя проверка на URI.

Portswigger написа добра статия и коментари от OpenResty и Nginx (вярно, коментарът, че се разкрива само малка част от паметта, е неверен и подвеждащ; това се определя от дължината на реда, следващ нулевия байт, и при отсъствие на явни ограничения за дължина, може да се контролира от атакуващия).

Каква беше грешката и какво да направим, за да я предотвратим?

Имаше ли грешка в nginx? Да, имаше, защото изтичането на съдържание от паметта е във всеки случай грешка.

Имаше ли грешка в OpenResty? Да, понеже въпросът за безопасността на предлаганата функционалност на OpenResty не беше изследван и документиран.

Допусната ли е грешка в конфигурацията / използването на OpenResty? Да, защото при липса на ясно указание, беше направено непроверено предположение за безопасността на използваната функционалност.

Коя от тези грешки е уязвимост с бага на $10000? За нас това до известна степен не е важно. Във всяко ПО, особено на границата на няколко компоненти, предоставени от различни проекти и разработчици, никой и никога не може да гарантира, че всички особености на тяхната работа са известни и документирани и че няма грешки. Следователно всяка уязвимост за безопасността възниква точно там, където засяга сигурността.

Във всеки случай, добра практика е да се нормализират или максимално ограничат/филтрират входните данни, които отиват към външен модул/API, ако няма ясни указания и еднозначно разбиране, че това не е необходимо.

Errata

По опит предишната статия, за да се запази чистотата на езика:

баг баунти — конкурс за откриване на грешки
багрепорт — известие за грешка
редирект — пренасочване
открити източници — с отворен код
errata — работа по грешките

Източник: habr.com