Проект GitHub уведомил (https://github.com/blog/1068-public-key-security-vulnerabili...) пользователей инциденте, в результате которого произошло неавторизированное внедрение кода в репозитории нескольких проектов, в том числе Ruby On Rails. В настоящее время приведшая к возможности взлома уязвимость уже устранена и начато расследование возможных последствий атаки. В настоящее время все факты свидетельствуют о том, что атака была лишь демонстрацией новой уязвимости, проведённой в открытую одним из исследователей безопасности.

Проблема была выявлена и продемонстрирована Егором Хомаковым (http://homakov.blogspot.com/) из Санкт-Петербурга. Уязвимость вызвана особенностью обработки массового присваивания данных форм в популярном web-фреймворке Ruby on Rails (http://rubyonrails.org/) и может наблюдаться в различных приложениях, не ограничиваясь GitHub. Использовав брешь в Rails стало возможным внесение изменений и отправка данных в репозиторий любого проекта GitHub, без ...

URL: http://www.h-online.com/open/news/item/GitHub-security-incid...
Новость: http://www.opennet.me/opennews/art.shtml?num=33268

• В GitHub устранена уязвимость, допускающая внедрение кода в ...,Loooooker, 19:13 , 05-Мрт-12
  • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Andrey Mitrofanov, 19:21 , 05-Мрт-12
• В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 20:05 , 05-Мрт-12
  • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 20:19 , 05-Мрт-12
    • В GitHub устранена уязвимость, допускающая внедрение кода в ...,kuraga, 20:52 , 05-Мрт-12
      • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 07:20 , 06-Мрт-12
        • В GitHub устранена уязвимость, допускающая внедрение кода в ...,kuraga, 18:31 , 06-Мрт-12
          • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 09:21 , 07-Мрт-12
            • В GitHub устранена уязвимость, допускающая внедрение кода в ...,kuraga, 21:20 , 07-Мрт-12
• В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 20:06 , 05-Мрт-12
  • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 22:05 , 05-Мрт-12
• В GitHub устранена уязвимость, допускающая внедрение кода в ...,evgeny_t, 21:18 , 05-Мрт-12
  • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 22:04 , 05-Мрт-12
    • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Псто, 23:59 , 05-Мрт-12
      • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 07:08 , 06-Мрт-12
        • В GitHub устранена уязвимость, допускающая внедрение кода в ...,zy, 12:42 , 06-Мрт-12
          • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 16:20 , 06-Мрт-12
            • В GitHub устранена уязвимость, допускающая внедрение кода в ...,kuraga, 18:35 , 06-Мрт-12
              • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 23:21 , 09-Мрт-12
      • В GitHub устранена уязвимость, допускающая внедрение кода в ...,SLK, 12:55 , 06-Мрт-12
        • В GitHub устранена уязвимость, допускающая внедрение кода в ...,gegMOPO4, 15:01 , 06-Мрт-12
          • В GitHub устранена уязвимость, допускающая внедрение...,arisu, 19:41 , 06-Мрт-12
            • В GitHub устранена уязвимость, допускающая внедрение...,gegMOPO4, 20:54 , 06-Мрт-12
              • В GitHub устранена уязвимость, допускающая внедрение...,arisu, 21:13 , 06-Мрт-12
                • В GitHub устранена уязвимость, допускающая внедрение...,gegMOPO4, 21:18 , 06-Мрт-12
                  • В GitHub устранена уязвимость, допускающая внедрение...,arisu, 21:26 , 06-Мрт-12
                  • В GitHub устранена уязвимость, допускающая внедрение...,Аноним, 00:03 , 10-Мрт-12
        • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 16:21 , 06-Мрт-12
          • В GitHub устранена уязвимость, допускающая внедрение кода в ...,SLK, 18:25 , 06-Мрт-12
          • В GitHub устранена уязвимость, допускающая внедрение кода в ...,kuraga, 18:39 , 06-Мрт-12
            • В GitHub устранена уязвимость, допускающая внедрение...,arisu, 19:42 , 06-Мрт-12
              • В GitHub устранена уязвимость, допускающая внедрение...,kuraga, 22:19 , 06-Мрт-12
                • В GitHub устранена уязвимость, допускающая внедрение...,arisu, 22:45 , 06-Мрт-12
                  • В GitHub устранена уязвимость, допускающая внедрение...,Аноним, 23:14 , 09-Мрт-12
• В GitHub устранена уязвимость, допускающая внедрение кода в ...,ЫыВ, 21:30 , 05-Мрт-12
• В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 21:49 , 05-Мрт-12
  • В GitHub устранена уязвимость, допускающая внедрение кода в ...,анон, 00:41 , 06-Мрт-12
    • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Crazy Alex, 01:07 , 06-Мрт-12
    • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 07:09 , 06-Мрт-12
      • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Alen, 09:40 , 06-Мрт-12
    • В GitHub устранена уязвимость, допускающая внедрение кода в ...,фклфт, 09:03 , 06-Мрт-12
      • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 16:23 , 06-Мрт-12
  • В GitHub устранена уязвимость, допускающая внедрение кода в ...,kuraga, 18:43 , 06-Мрт-12
    • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 23:25 , 09-Мрт-12
• В GitHub устранена уязвимость, допускающая внедрение кода в ...,Ya, 22:00 , 05-Мрт-12
  • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 23:20 , 05-Мрт-12
    • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 23:31 , 05-Мрт-12
      • В GitHub устранена уязвимость, допускающая внедрение кода в ...,hummermania, 09:47 , 06-Мрт-12
• В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 00:05 , 06-Мрт-12
• В GitHub устранена уязвимость, допускающая внедрение кода в ...,gegMOPO4, 00:23 , 06-Мрт-12
  • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Crazy Alex, 01:05 , 06-Мрт-12
    • В GitHub устранена уязвимость, допускающая внедрение кода в ...,gegMOPO4, 11:19 , 06-Мрт-12
      • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Alex, 13:24 , 06-Мрт-12
        • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Ваня, 13:30 , 06-Мрт-12
          • В GitHub устранена уязвимость, допускающая внедрение кода в ...,kuraga, 22:22 , 06-Мрт-12
            • В GitHub устранена уязвимость, допускающая внедрение кода в ...,kuraga, 22:25 , 06-Мрт-12
        • В GitHub устранена уязвимость, допускающая внедрение кода в ...,gegMOPO4, 14:57 , 06-Мрт-12
          • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Crazy Alex, 21:26 , 06-Мрт-12
  • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 07:13 , 06-Мрт-12
    • В GitHub устранена уязвимость, допускающая внедрение...,arisu, 07:18 , 06-Мрт-12
      • В GitHub устранена уязвимость, допускающая внедрение...,Аноним, 07:31 , 06-Мрт-12
        • В GitHub устранена уязвимость, допускающая внедрение...,arisu, 07:35 , 06-Мрт-12
          • В GitHub устранена уязвимость, допускающая внедрение...,Аноним, 16:24 , 06-Мрт-12
    • В GitHub устранена уязвимость, допускающая внедрение кода в ...,gegMOPO4, 11:24 , 06-Мрт-12
      • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Ваня, 13:11 , 06-Мрт-12
        • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 00:04 , 09-Мрт-12
          • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 00:08 , 09-Мрт-12
      • В GitHub устранена уязвимость, допускающая внедрение...,arisu, 19:05 , 06-Мрт-12
        • В GitHub устранена уязвимость, допускающая внедрение...,gegMOPO4, 21:10 , 06-Мрт-12
          • В GitHub устранена уязвимость, допускающая внедрение...,arisu, 21:14 , 06-Мрт-12
            • В GitHub устранена уязвимость, допускающая внедрение...,gegMOPO4, 21:20 , 06-Мрт-12
              • В GitHub устранена уязвимость, допускающая внедрение...,arisu, 21:25 , 06-Мрт-12
                • В GitHub устранена уязвимость, допускающая внедрение...,kuraga, 22:31 , 06-Мрт-12
                  • В GitHub устранена уязвимость, допускающая внедрение...,arisu, 22:44 , 06-Мрт-12
      • В GitHub устранена уязвимость, допускающая внедрение...,arisu, 19:07 , 06-Мрт-12
• В GitHub устранена уязвимость, допускающая внедрение кода в ...,chemtech, 06:21 , 06-Мрт-12
• В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 11:40 , 06-Мрт-12
  • В GitHub устранена уязвимость, допускающая внедрение кода в ...,AlexYeCu, 11:55 , 06-Мрт-12
    • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Andrey Mitrofanov, 12:03 , 06-Мрт-12
• В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 14:40 , 06-Мрт-12
  • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 15:23 , 06-Мрт-12
    • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 16:27 , 06-Мрт-12
      • В GitHub устранена уязвимость, допускающая внедрение...,arisu, 19:50 , 06-Мрт-12
        • В GitHub устранена уязвимость, допускающая внедрение...,Аноним, 23:46 , 09-Мрт-12
      • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 19:52 , 06-Мрт-12
        • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 23:33 , 09-Мрт-12
      • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Клыкастый, 23:05 , 06-Мрт-12
        • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 23:35 , 09-Мрт-12
          • В GitHub устранена уязвимость, допускающая внедрение...,arisu, 23:40 , 09-Мрт-12
            • В GitHub устранена уязвимость, допускающая внедрение...,Аноним, 23:49 , 09-Мрт-12
              • В GitHub устранена уязвимость, допускающая внедрение...,Клыкастый, 13:51 , 12-Мрт-12
    • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 17:03 , 06-Мрт-12
    • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 20:00 , 06-Мрт-12
• В GitHub устранена уязвимость, допускающая внедрение...,arisu, 19:08 , 06-Мрт-12
  • В GitHub устранена уязвимость, допускающая внедрение...,Аноним, 23:02 , 06-Мрт-12
    • В GitHub устранена уязвимость, допускающая внедрение...,arisu, 23:03 , 06-Мрт-12
    • В GitHub устранена уязвимость, допускающая внедрение...,Аноним, 23:56 , 09-Мрт-12
• В GitHub устранена уязвимость, допускающая внедрение кода в ...,Maxim Filatov, 11:31 , 07-Мрт-12
  • В GitHub устранена уязвимость, допускающая внедрение кода в ...,Аноним, 23:57 , 09-Мрт-12

Затейник )
Их же граблями да по голове )

Security circus, как говаривал один американский швед финского происхождения...

операться надо на многократно проверенное, а не на удобное...

... на Perl

Причем тут это?? Разрабы поленились написать код. Разница, какой язык? Никакой. Лень/неосведомленность.

Ну разве что если лень разработчиков рельсы, тогда да:

> функциональность необходимая для этого по-умолчанию отключена в стандартной инсталляции
> Ruby on Rails

Ну? А кто сказал, что она должна быть ВКЛЮЧЕНА? Программист проекта САМ должен заботиться о балансе между удобством и безопасностью. И описываемая опция в рельсах ВКЛЮЧАЕМА, А НЕ ОТСУТСТВУЕТ!!!

да вы че!! это одна строчка в модели, которая к тому-жу по умолчанию попадает, если скаффолдом создавать, как обычно и делают. Автор новости вообще не в теме. Это как утверждать что С не может печатать на экран, т.к. команда printf по умолчанию не включена.

ВКЛЮЧАЕМА - значит ее можно включить, ЕСЛИ она выключена. что по умолчанию это так - я НЕ говорил.

дьявол кроется в удобстве!

> дьявол кроется в удобстве!

...коммита в чужие проекты... ;]

да надо было сразу в ядро комитить )
вот шухер то был )

Да не, перец все правильно сделал, вкомитив фикс прямо виновникам бага. Эпик лулз! :)

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

> бага нет.

Добро пожаловать в матрицу! Бага нет, а левые коммиты - есть. Trollaface.jpg

> простой косяк разработчиков гитхаба с масс-ассайментс.

Как я понимаю такой косяк может иметь место на еще 100500 разных сайтов и по дефолту даже средства борьбы с геморроем не активны, хотя они и есть в природе. Просто потому что разработчики фреймворка - упертые бараны. Тест бараньего лба супротив ворот однако показал что ворота попались сцуко прочные, даже закрытие бага с разбега не пробирает.

> расходимся.

Скатертью дорога.

>>но это уведомление было закрыто с комментарием, что ошибка находится в зоне ответственности конечных разработчиков приложений на Ruby on Rails.

Если вы не имеете представления о рельсах и о какой уязвимости здесь идёт речь, то не нужно нести чепухи. В наличии уязвимости виноваты только разработчики гитхаба так как в документации по mass-assignment чёрным по белому написано что по умолчанию работает стратегия чёрного списка, другое дело что всякие быдлокодеры не читают эту документацию. Теперь разработчики рельсов сделают что бы по умолчанию была включена стратегия белого списка, и все эти разработчики из за своей тупости получат кучу гемороя в види прописывания attr_accessible для нужных моделей, но они заслужили этого гемороя.

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

> Если вы не имеете представления о рельсах и о какой уязвимости здесь
> идёт речь, то не нужно нести чепухи. В наличии уязвимости виноваты
> только разработчики гитхаба так как в документации по mass-assignment чёрным по
> белому написано что по умолчанию работает стратегия чёрного списка,

Слушайте, прыг по граблям - многофазный процесс. Один кладет грабли, второй не смотрит под ноги, третий ему шишак на лбу лечит.

Вот только исходно больше всех виноват тот кто грабли на дороге бросил (разработчики RoR). Те кто под ноги не смотрел конечно тоже виноваты, ибо под ноги смотреть все-же надо. Только первых это все не извиняет. Поэтому если кто-то возжелал почесать спину граблями тому кто их бросил - так ему и надо, нефиг разбрасывать! :)

Бред. Отключенный белый список - ровно такая же грабля, как и наоборот. Целью фреймворка не было создание безопасных приложений без участия программера. И слава богу. А то вообще думать перестанем.

> Бред. Отключенный белый список - ровно такая же грабля, как и наоборот.

Зато более безопасная грабля. Лучше пусть уж у грабель ручка будет обернута поролоном, лбы целее будут. Особенно у инфантильных и туповатых вебдевелов, имеющих крайне смутное представление о процессе разработки софта и как это делается в нормальном виде. Если системщикам с их сями и режимами ядра где 1 факап = взвис всей системы как-то не привыкать бегать по лезвию бритвы и квалификация позволяет (когда факап будет приводить к взвису системы - вы поневоле очень быстро и эффективно научитесь писать хорошо), то вот туповатые и раздолбайские вебдевелы обычно о секурити вообще в лучшем случае знают что вроде бы это где-то есть в природе, но за них все должен сделать и продумать шибко вумный фреймворк и потому им греть этим свой полугуманитарный мозг совсем не нужно. А фреймворк возьми да и выкинь им такую подставу...

Не ну как бы целевую аудиторию, их скиллы и прочая наверное надо представлять и делать поправку на ветер, или где?!

Да ладно, тролю напоминать про голову бесполезно.

Для тех кто не понял: Это не баг RoR, это баг самого GitHub.

В RoR есть стандартные средства для управления доступом к mass assignment.
То, что эти средства по умолчанию отключены - Ложь
Разработчикам GitHub и тем кто работает с RoR просто нужно за этим следить и расставлять
где надо attr_protected. Кроме того, в любом проекте на RoR можно запретить изменение
полей ActiveRecord через mass assignment как для любого класса в отдельности так и
глобально.

Читаем еще раз .... "За два дня до инцидента Егор оставил уведомление о найденной им
уязвимости для разработчиков проекта Ruby on Rails, но это уведомление было закрыто с
комментарием, что ошибка находится в зоне ответственности конечных разработчиков
приложений на Ruby on Rails."

Егору +1000. Такой проект как GitHub обязан следить за безопасностью, тем более, что все эти фичи в RoR очень хорошо документированы.

Следить, конечно, обязаны, тут они, конечно, ошиблись. Но есть более приличные способы указать на слабость замка, чем вламываться в дом.

а кто вламывался-то? O_O

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

Если владелец цифрового замка оставляет код 12345 (хотя в инструкции к замку настоятельно советуют его сменить, но кто ж читает инструкции?), это вина владельца замка, или производителя? И если кто-то попробовал эту комбинацию на чужом замке и она подошла, то законно ли ему после этого проникать в дом?

если не написано, что незаконно — то законно. разве в ToS гитхаба написано, что нельзя заходить в проекты, к которым есть открытый доступ и делать там что хочется?

А у вас на дверях написано, что нельзя входить и делать что хочется?

> А у вас на дверях написано, что нельзя входить и делать что
> хочется?

это в законе написано. в таком документе, который называется «Конституция». пожалуйста, укажи мне, где именно в Конституции написано что-то про репозитории исходных текстов. if you please.

> А у вас на дверях написано, что нельзя входить и делать что хочется?

Иногда - очень доходчиво написано :) Например как-то так: http://leprastuff.ru/data/img/20120213/c5cb12f12c0d1d0ccf93a...

> что все эти фичи в RoR очень хорошо документированы.

Для начала, дефолты должны быть безопасными. А не так что мы разбросаем на поле мины и честно вывесим табличку "осторожно, мины!" (а кто не увидел табличку - сам дурак!)

Согласен. Думаю, что всем разраобчикам ORM библиотек (не только ActiveRecord и не только в
Ruby) где есть возможность делать mass assignment полей обьекта, нужно об этом
позаботиться. Таких не мало ... есть PHP ActiveRecord, есть ASP.NET MVC, в Java скорее
всего тоже есть ORM-ы с такой возможностью ... везде свои настройки по умолчанию
и соответственно опасность mass assignment.  

К примеру в DataMapper (альтернативная ORM библиотека на Ruby) по умолчанию все поля
обьявленные ключевыми не возможно изменить через mass assignment, только через
геттеры\сеттеры.

Спорно. Ибо абсолютной безопасности пока нет. Поэтому и "безопасные по дефолту" - мнимо. "БОЛЕЕ безопасные, к ДАННОМУ виду атак" - если бы сказали так, то согласился бы. Безопасность - отсутствие возможностей :)

однако мне кажется, что более верный подход — делать потенциально опасные вещи как opt-in, а не opt-out. заодно люди и документацию прочитают, пока будут искать, как их включить.

Согласен. Но я считаю неправильным, если программист АПРИОРИ ПОЛАГАЕТ, что это так. Хотя бы потому, что потенциально опасно все. Вспомните Си и баги ядра с "=", "=="... Не запретишь ведь...

натурально, не панацея. но разумные умолчания ещё никому не мешали, думается.

> натурально, не панацея. но разумные умолчания ещё никому не мешали, думается.

Более того - сишные компилеры нынче насколько я помню умеют детектить подозрительные места такого плана и выкидывают по этому поводу варнинг. Что в общем то есть правильно, ибо присвоение в условии - странная конструкция. Придумать ей применение кроме как для раскидывания грабель довольно сложно.

Егор, успехов!

А утверждается что разработчики RoR пробакланили все и забили на багрепорт, отказавшись чинить баг. Ну и получили левый коммит в бубен для наглядной демонстрации.

Итого: пиплу EPIC WIN. А вот дятлам использующим рельсу следует очень крепко задуматься о том что у разработчиков рубирельсы - ЖИДКИЙ МОЗГ!

это не баг

Угу. "Это не баг, это фича". На дефолтное register_globals в PHP ругаться - так баг, а подобная же дыра в рельсах - фича? Нет уж, господа, фреймворки для того и нужны чтобы о подобном не думать.

> это не баг

С точки зрения хакеров и спецслужб - безусловно, фича офигительного калибра ;]

Может они от того и не хотели закрывать, что им "настоятельно рекомендовали" ;)

> это не баг

Конечно не Баг, это просто очередная такая фитча которая появляется время от времени.
Не надо забывать такой же баг в апаче, portsentry, ssh, proftpd, sftpd и еще многих десятков проектов включая iptables
Благодаря таким багам позор открытым проектам
Давно уже пора навести генеральный аудит кернела а то туда столько уже напихали таких фитч интересных что просто так уже их не выпилить
Блажен тот кто верует в то что это Баги

> Давно уже пора навести генеральный аудит кернела

1) RoR ну совсем никак не относится к кернелам.
2) Вы о каком кернеле? О том в котором недавно ремотно присылаемые UDP пакеты на закрытый порт код выполняли? Так это... MS исходники забыл выдать, так что пусть сам и аудитит. А у остальных таких лютых обсиронов что ремотно можно код с правами ядра выполнить уж сто лет как не было.

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

> Жидкий мозг у тех, кто не следит за своим кодом и документацией.

Честно говоря, у почти всех вебдевелов мозг довольно жидковат. Как минимум по части секурити. Типовой сферический вебдев в вакууме обычно является довольно странным бакланом, который не очень понимает как все это в целом работает, уповает на то что за него все сделают более высокоразвитые существа в фреймворке/рантайме/чем там блин еще. А эти более высокоразвитые возьми да и окажись такими же бакланами, подкладывающими свинью "братьем нашим меньшим". К большому облому этих самых меньших...

Радостно видеть, что ещё не все мозги из России уехали за рубеж... Респект мужику!

Ну ничего, вот получит рабочую визу от того же github :3

На колыму.

ЩО уже и там github???

Кстати, не из Питера он, не видел я его тут.

Ну молодец. В пятницу сообщил GitHub об уязвимости, а в воскресенье уже атаковал.

Такое надо фиксить моментально, вообще-то.

Ну вот моментально и пофиксили. Как только узнали. С кем он там переписывался в пятницу, с секретаршей или с вахтёром, и почему не стал ждать, пока после уик-энда вернутся те, кто уполномочен вносить изменения в конфигурацию ГитХаба, — неясно.

>Ну вот моментально и пофиксили. Как только узнали. С кем он там переписывался в пятницу, с секретаршей или с вахтёром, и почему не стал ждать, пока после уик-энда вернутся те, кто уполномочен вносить изменения в конфигурацию ГитХаба, — неясно.

Вообще-то багрепорт закрыли с сообщением, что это их не касается

http://mobile.opennet.ru/cgi-bin/openforum/vsluhboard.cgi?az...

Вообще то голову иногда полезно включать.

Я вообще не понимаю, как хакер нашел уязвимость и ступанул с тем, кому писать.

Хотя вот тут пишут, что это он так пошутил над RoR :)

Кто закрыл и кого не касается? И причём здесь ГитХаб?

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

> а в воскресенье уже атаковал.

Так обeзьяны делающие RoR не придумали ничего умнее как просто закрыть баг. Ну если на анонс о уязвимости столь лaмерская реакция - то по-моему самому вбрoсить фикс :) бага :) это вообще архиэпично и довольно благородно.

Блэкхэт бы найдя такое просто закoммитил втихую бэкдоры в кучу проектов и ржал втихарика над "этими идиoтами" использующими "это решeто" от "некомпетентных обeзьян". Попутно рубая килобаксы на черном рынке. А тут перец просто технично пофиксил баг сам, сам прописав себе права. Epic win! Нагляднее показать разработчикам сита что у них много дырок просто невозможно :)

в общем да, всё логично: раз это не баг, то какая проблема в том, что человек использовал *штатную фичу* тогда, когда захотел?

> в общем да, всё логично: раз это не баг, то какая проблема
> в том, что человек использовал *штатную фичу* тогда, когда захотел?

Вот именно, Капитан. В этом и состоит комизм ситуации ;]

ну, я на всякий случай расшифровал. Кэп я или нет? надо ж реноме поддерживать.

> реноме поддерживать.

Спасибо, Капитан :)

А при чём здесь RoR? Взломал он GitHub. Где ссылка на репорт в багтрекере ГитХаба?

Ну и баг он не фиксил. Он просто пролез в форточку и оставил на видном месте надпись «Здесь был Вася». Хорошо, конечно, что не насрал на стол, но это не такое уж и достижение.

Поручик Ржевский приехал к Безухову, но не застал того дома. "Может в рояль насрать? Ан нет, не поймут. Деревня..."

Так и здесь: не поймут. Деревня...

Ваня, надо быть скромнее...

> Ваня, надо быть скромнее...

И вытаскивать дерьмо из карманов, когда выходите в свет...

> А при чём здесь RoR? Взломал он GitHub. Где ссылка на репорт
> в багтрекере ГитХаба?

а бага нет. авторы RoR сказали, что это вообще не баг. а раз не баг — это штатная фича. не вижу, с каких пор стало нужно запрашивать разрешения или писать в багтрекер о штатной фиче.

Баг не в самом RoR, а в GitHub. Если программист на PHP напишет код, допускающий SQL-инъекции, куда багрепорт нужно слать — в PHP или авторам этого кода на PHP?

> Баг не в самом RoR, а в GitHub.

а гитхаб никто не трогал, например.

Как это не трогал? А новость о чём?

> Как это не трогал? А новость о чём?

о том, что немножко пошутили над авторами RoR. где в новости информация о том, что он тронул код гитхаба?

Ну он на него все равно че-т послал :) Та же инъекция-биекция)))))))

> Ну он на него все равно че-т послал :) Та же инъекция-биекция)))))))

таких «инъекций» — каждый первый коммит. %-)

p.s. гитхаб он не ломал. он воспользовался штатной фичей RoR, чтобы немножко улыбнуться над авторами RoR. которые страшно далеки от народа и не летают, пока по тестикулам не пнёшь.

Хочу заметить, что написано не просто "Егором Хомяковым", а "Егором Хомяковым из Санкт-Петербурга")

Безотносительно к факту, создаётся какое-то впечатление, что чувак не может внятно и связно изъясняться ни на русском, ни на английском. В этом тоже может быть проблема что его не услышали вовремя.

Использовал русский язык — не поняли.
Использовал английский язык — не поняли.
Использовал Ruby язык — поняли!

--2 наряда вне очереди. --Нэпанимаю. --3 наряда вне очереди! --Нэпанимаю. --5 нарядов вне очереди!! --Нэ имеишь права.

В Арче, оказывается, тоже есть страшный баг. Установка по-умолчанию не включает iptables!

Зачем iptables на десктопной системе? Или к чему это было написано?

> Зачем iptables на десктопной системе?

Мля, даже в домохозяечной win xp какое-то подобие файрвола и то есть. Такого от арчеводов я как-то не ожиждал. Хотя... памятуя о том что они подписи пакетов еще только собираются прикручивать несложно понять насколько они класть хотели на безопасность использования их системы :\

> Мля, даже в домохозяечной win xp какое-то подобие файрвола и то есть.

потому что без файрвола винда похожа не просто на решето, а на решето без сита. это раз.

два: покажи мне домохозяйку, устанавливающую арч.

три: давай проведём эксперимент: выставим в интернеты голую winxp и голый arch. и посмотрим, что с ними будет через пол-дня. дольше не предлагаю по очевидным причинам.

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

> потому что без файрвола винда похожа не просто на рeшето, а на
> рeшето без сита. это раз.

Там файрвол такой, конечно... умеет только на вход и правила примитивные как топор. В общем не понятно зачем каменным топором неандертальца козырять, неодобрительно косясь на сверхзвуковой истребитель :)

> голубчик, ты, возможно, удивишься, но основное назначение iptables — вовсе не
> «закрывать порты в дырявой системе».

Во первых, удавка лишнего траффа еще никому не мешала. В конце концов, эксплойт в принципе и в линухе может прилететь. Через браузер или что там еще. Ничему не противоречит, программы там ничем таким принципиально не отличаются. Ты же не проводил аудит всего софта на предмет дырок, правда? А фигня случается, например с libpng вон недавно было. То что оперативно заткнули - отлично, но до этого то дырень была. И о ней в принципе кто-то мог знать и раньше. Why not? :)

Еще бывает откровенно нежелательная активность типа брутфорса ssh в 200 потоков из публичной LAN в которой водится чуть более чем 9000 видов заразы и автоматизированной активности - тоже радости не особо добавит. Конечно можно рассказать что нефиг использовать ssh для доступа к компьютеру, но...

Ну и наконец, довольно тупо когда есть приличный движок фильтра но нет средств для управления оным. Впрочем у арчеводов вообще с логикой по жизни хило. Они вон и цифровые подписи к пакетам только прикручивают. А то что в принципе любой козел может при этом подменить пакет и отгрузить что угодно - их не волнует. Неуловимый Джо такой неуловимый :)

>Мля, даже в домохозяечной win xp какое-то подобие файрвола и то есть.

Назови хоть один случай когда нужно оперировать правилами iptables на десктопной системе.

> Назови хоть один случай когда нужно оперировать правилами iptables на десктопной системе.

А легко. Допустим хочу я раздать интернет с 3G свистка в ноуте по вайфаю нескольким окружающим. Айпитаблес - поможет. Ну и вообще, тупо иметь мощный фильтр в системе но не иметь интерфейса к нему. Машина с мощным двигателем но без руля - круто придумано :)

> Мля, даже в домохозяечной win xp какое-то подобие файрвола и то есть.

в юниксе файр нужен, чтобы закрывать входы, чтобы не пропустить вторжение
в венде - чтобы не выпускать наружу троянов и прочий гадюшник. естественно что оно там - есть. подобие.

несмотря на то, что товарисча резко минусанули, поддержу его и расширю вопрос: что именно по-вашему должен защищать файрвол на десктопе?

$ netstat -an | grep LIST | grep tcp
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN    

итак?

> итак?

Итак, если какой-то умник пустит злобный скан на порт 22 и начнет откровенно брутфорсить пассворды потоков так в 200, вам должно понравиться :)

да на здоровье.

> да на здоровье.

Я что-то не уверен что его пропрет что ремотная активность уперла его проц в потолок :). Особенно прикольно на ноуте, где батарейка в результате такой деятельности уйдет в 0 не за 8 часов а за 2-3.

>> да на здоровье.
> Я что-то не уверен что его пропрет что ремотная активность уперла его
> проц в потолок :). Особенно прикольно на ноуте,

ноут с гигабитным каналом и белым ip? однако...

К тому, что небезопасное поведение по-умолчанию, о котором упомянуто даже в официальных Rails Guides с рекомендацией "всегда используйте attr_accessible в моделях", как-то некорректно называть багом и уязвимостью.
Разработчики ГитХаба это прозевали? Прозевали. Но при чём тут Rails?
Однако, я всё же согласен с тем, что включение вайтлиста по-умолчанию - хорошая идея.

Что самое забавное, минусуют те, кто iptables в глаза не видел. Зато у них в голове прочно засел очередной миф из чудесного мира Windows, что если нет фильтрации пакетов, то все, ппц, из интернета атакуют злобные хакеры и заразят винлокером.

да, кстати. ведь у github насильный https — откуда уязвимость? ведь всем известно: стоит отрубить http и всех насильно переводить на https — и никаких уязвимостей. разве не так?

Не так. Но http при наличии https обязан быть отрублен.

> Не так.

как же это «не так»? а зачем тогда насильно впаривать https, который и неудобней, и тормозней, и нагрузка на сервера больше?

> Но http при наличии https обязан быть отрублен.

с чего бы?

> Не так. Но http при наличии https обязан быть отрублен.

Кто это придумал? И главное - что там такого ценного что предлагается шифровать? Я вот честное пионерское, не вижу никакой активности которую бы я производил на гитхабе и которая бы требовала сокрытия от посторонних глаз. Зато пока SSL сконектится, перекинется ключами и прочая, HTTP уже давно сгоняет запрос и получит ответ, а SSL еще только начинает конектиться поверх секурного туннеля... который рыли непонятно зачем, секуря вообще неизвестно что и зачем. Гениально, мля.

>> после столь демонстративного взлома, разработчики Rails внесли изменения в ветку, на базе которой будет сформирован релиз Ruby on Rails 3.2

А у кого тут машина времени?
Релиз Ruby on Rails 3.2 вышел 20-го января.

> А у кого тут машина времени?

У того самого хацкера, он коммит на 1000 лет вперед сделал, чтоли :)