Относно една уязвимост в...

Преди една година, 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, когато се използва пренаписване с потребителски данни, има възможност за обхождане на директория (и вероятно SSRF) в някои конфигурации, но това е известен факт и трябва да бъде открит от статичните конфигурационни анализатори в Nginx Amplify и Гикси от Yandex (да, ние също го използваме, благодаря). Когато използвате 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 има грешка, която причинява изтичане на памет, ако редът за презапис съдържа нулев байт. Когато се издаде пренасочване, 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 параметрите от инжектиране на служебни знаци и прави възможно използването само на 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=%00asdfasdfasdfasdfasdfasdfasdfasdf" -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.

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

И така, каква беше грешката и какво може да се направи, за да се предотврати?

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

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

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

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

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

печатни грешки

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

награда за грешки — състезание по лов на буболечки
доклад за грешка - известие за грешка
пренасочване - пренасочване
отворен код - отворен код
ератум - работа върху грешките

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