Критическая уязвимость во всех версиях JunOS начиная с 7.6R1

    Приветствую,

    Juniper опубликовал PR839412, который описывает уязвимость, существующую во всех версиях JunOS начиная с 7.6R1. Cпециально сформированный TCP-пакет направленный на RE (Routing Engine) маршрутизатора может привести к краху ядра. Деталей о том каким именно должен быть TCP-пакет — не предоставляется. На данный момент известных публичных эксплоитов нет.

    Для эксплуатации уязвимости нет необходимости устанавливать TCP-сессию, достаточно одного пакета, но этот пакет должен быть разрешен фильтрами. То есть, если у вас слушает любой TCP-сервис (например: BGP, SSH) и злоумышленнику известны ip-адреса, которые разрешены в фильтрах — теоретически он может сформировать пакет, который приведет к отказу в обслуживании маршрутизатора.

    Закрыть уязвимость можно двумя способами:
    — Запретить доступ ко всем TCP-сервисам, включая BGP.
    — Обновиться до версии JunOS в которой уязвимость закрыта.

    На данный момент уязвимость исправлена в следующих версиях:
    9.1R4 9.3R4 9.5R3 9.6R2 9.6R3 9.6R4 10.1R1 10.1R4 10.1R5 10.2R1 10.2R2 10.2R3 10.2R4 10.3R1 10.3R2 10.4R1 10.4R2 10.4R3 10.4R4 10.4R5 10.4R6 10.4R7 10.4R8 10.4R9 10.4R10 10.4R11 10.4R12 10.4R13 11.1R1 11.1R2 11.1R3 11.1R4 11.1R5 11.1R6 11.2R1 11.2R2 11.2R3 11.2R4 11.2R5 11.2R6 11.2R7 11.3R1 11.3R2 11.3R3 11.3R4 11.3R5 11.3R6 11.3R7 11.4R1 11.4R2 11.4R3 11.4R3-S1 11.4R3-S3 11.4R4 11.4R4-S2 11.4R5 11.4R5-S1 11.4R5-S3 11.4R6 11.4R7 12.1R1 12.1R2 12.1R2-S2 12.1R3 12.1R3-S1 12.1R4 12.1R5 12.2R1 12.2R1-S3 12.2R2 12.2R3

    Обновляйтесь!

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 19

      –3
      Кто-то ещё сидит на таком старье?
      Помнится, года 3 назад новые железки шли с уже 10.2
        +3
        Уязвимы все версии, начиная с 7.6R1. По сути это баг, который был с нами годами.
          0
          из:
          > На данный момент уязвимость исправлена в следующих версиях
          можно предположить, что эти релизы не подвержены уязвимости.

          Будте любезны ссылку на оригинальную новость на сайте Juniper'а?
            0
            > можно предположить, что эти релизы не подвержены уязвимости.
            В конкретных перечисленных релизах эта уязвимость должна быть уже исправленна.

            Будьте любезны, прочитайте текст внимательно еще раз. Я указал в самом начале, что информация доступна в PR839412.
            Не думаю что это оформленно в виде «новости» на сайте Juniper'а.

              0
              >Juniper опубликовал PR839412

              Приведите, пожалуйста, ссылку на публикацию. Или приведите оригинал.
              Потому что из новости совершенно не понятно, есть ли данная уязвимость, например, в 11.4R5, установленном год назад.
                +3
                Пожалуйста: prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR839412
                Думаю, ссылка не особо полезна, т.к. те кто работают с JunOS знают как посмотреть PR, у остальных же нет логина.

                Я понял ваше замечание, возможно не совсем корректно сформулировал. Список исправленных релизов я скопировал из оригинального PR.
                Естественно, уязвимость исправленна в последних версиях этих релизов. К примеру, 11.4R5.7, который был обновлен 28 января 2013 последний раз.
                  0
                  Спасибо!
        0
        :) Три года назад была один в один уязвимость у Джунов. только там использовался ICMP пакет. Выходит ICMP подчинили, а TCP забыли. Ждем информации, что один UDP пакет тоже ложит железку. :)
          +1
          Кладёт. Простите, не удержался.
          0
          prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR839412

          Собственно, там все написано. Судя по всему, это уязвимость ядра FreeBSD (так что надо жать аналогичные репорты о других продуктах на базе этого ядра).

          Честно говоря, причин для паники не вижу.

          Если у вас RE не защищен от входящих TCP откуда ни попади, то вас можно задосить еще примерно сотней способов.

          В идеале FW-фильтры, защищающие RE, и не должны принимать TCP на RE от всех подряд. BGP должен быть разрешен только от сконфигурированных пиров (одна команда), к тому же eBGP — только с TTL 1. SSH — от доверенных, и т. д.

          О best-practices защиты RE см. например вот эти книжки:

          www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/securing-routing-engine/ (доступно официально бесплатно в виде PDF).
          www.juniper.net/us/en/training/jnbooks/mx-series.html
            0
            С этим багом достаточно одного пакета для эксплуатации. Т.е. фильтры легко обойдутся, если атакующий знает адреса ваших BGP пиров (что достаточно легко). Насчёт TTL — есть еще и multihop, и, снова таки, один единственный пакет можно собрать каким угодно.
              0
              Ну, если все так плохо: и multihop, и вы max ttl выставили от души, и атакующий знает адреса пиров, то да, можно кричать «караул». Только по хорошему делать это надо несколько раньше. Спорим, что в таком сулчае у вас на сессии нету аутентификации, и положить вашу внеш пиринг можно без всяких багов просто послав вам чего-нибудь по BGP? А еще лучше — просто слать вам TCP RST со всех подряд src-портов.
                0
                Строить теории о том, какой может быть конфигурация чтобы быть или не быть уязвимой — можно долго. Я уверен, что найдётся не мало конфигураций, которые будут уязвимы в той или иной степени. И, к счастью, такие, которые не уязвимы.
                Уязвимость есть и она критическая по своей сути. Является ли возможной ее эксплуатация — зависит от вас :)
                  0
                  Ну, я с вашего позволения, повторю свой первоначальный тезис:

                  Если так случилось, что конфигурация уязвима в отношении данного экспойта, то с большой вероятностью она уязвима к массе других возможных атак на тот же BGP, о которых известно давно и подробно. И наоборот: если вы раньше думали головой и все делали правильно, то от этой проблемы вы защищены — проапгрейдиться все же стоит, но скорее в плановом режиме, чем сломя голову.

                  А дальше каждый сам решает, разумеется.
                    0
                    Смотрите, речь тут не о BGP. Во-первых, уязвимость на уровне TCP стэка, т.е. потенциально ещё можно эксплуатировать до того как BGP процесс дропнет пакет из-за неправильного TTL. Т.е. не важно насколько хорошо у вас он сконфигурирован, зная адрес пира — уже можно спуфнуть пакет, который потенциально перезагрузит маршрутизатор.
                    Это же касается и всех других сервисов, включая SSH. Раньше, зная адрес доверенного хоста — ничего сделать было нельзя. Теперь же — можно. Security through obscurity — это плохо.
                    Но с SSH, конечно, сложнее. С BGP же адрес пира с большой вероятностью можно угадать глядя в trace route к вам.

                    Поэтому уязвимы все, у кого есть хотя бы BGP с внешним миром. Не считая всех других возможных TCP сервисов.
                      0
                      Я прекрасно понимаю, о чем вы.

                      Но только еще раз повторюсь, что пакет, прежде чем вообще быть скоммутированным свичем, который передает трафик с плат коммутации в RE, должен пролезть через систему файрвольных фильтров внутри комплекса коммутации. В случае с eBGP это должен быть пакет только от пира, и только с TTL 1. То есть это способ защититься в том числе от этой уязвимости, и это должно быть сделано, на любом маршрутизаторе, RE которого общается с недоверенными сетями.

                      И если этого не сделано, то бессмысленно вообще говорить о каких-либо уязвимостях, потому что, если кто-то хочет выставить свою задницу в интернет, вопрос о том, каким именно способом его могут трахнуть, приобретает вторичное значение.

                      SSH с web-менеджментом, если он у вас есть, на время до апгрейда можно и вовсе отключить из интернета. Другие TCP, адресованные в RE, надо просто выкидывать у помойку не глядя. И до того, как этот косяк обнаружили, так и после.

                      Так что никакой страшной неопределеннсти и вот этого вот «ах, неизвестно к чему это можно привести. Вдруг нам нужно какие-нибудь еще TCP-порты слушать, а мы не знаем, какие» — ничего этого нету. Все вполне известно и определенно. И защититься в данном конкретном случае вполне можно и нужно.

                      А то что уязвимость и баги это плохо — ну, можно и попалакать, конечно, но мне лень, если честно. Далеко не самая страшная это проблема, в т. ч. из встречающихся в JUNOS.
                        0
                        Так а в чем заключается защита, если не проблема собрать пакет с адресом пира и таким TTL, чтобы он стал 1, когда дойдёт до маршрутизатора?

                        Даже если учесть, что атаковать можно только с «доверенного» внешнего пира, то если у вас их, например, сотни — это увеличивает вектор возможной атаки. Если кто то контролирует сеть пира, то он может перезагрузить ваши пограничные маршрутизаторы.

                        Я не вижу где я «плачу» об неизвестных слушающих сервисах. Все как раз известно. Поэтому для меня как раз ясно, что обновление должно быть внеплановым.
                0
                Ну, то есть, поймите правильно мой спич. Задуматься об апгрейде надо, нет вопросов. Но вот прям паниковать и сломя голову менять софт, нарушив стандартные правила этого дела (как минимум чтение Release Notes плюс соотнесение номера релиза со здравым смыслом) — по-моему не стоит. Лучше проверить, чего у вас в части стандартных механизмов защиты сделано.
                  0
                  Естественно. Я лишь привёл информацию о существующей проблеме. Определение степени уязвимости конкретной сети я оставлю её владельцам. Если кто то накатывает новые версии сломя голову и не подумав -, как вы сказали, там уже другие проблемы.

            Only users with full accounts can post comments. Log in, please.