Компания GitLab предупредила пользователей об увеличении активности злоумышленников, связанной с эксплуатацией критической уязвимости CVE-2021-22205, позволяющей удалённо без прохождения аутентификации выполнить свой код на сервере, на котором используется платформа для организации совместной разработки GitLab...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56110
Вот поэтому я люблю ставить новые версии по мере появления
Бустерные версии раз в полгода. Ради общества.
У вас сертификат поддельный. Наш тест показал это с достоверностью 99%. Пройдите на расстрел.
Ну да. И по полгода торчать с новой уязвимостью, пока её не пофиксят. Проверенные, фикшенные версии гораздо надёжнее.
На тот момент также была проверена.
> На тот момент также была проверена.Поэтому стоило подождать ещё дольше. Использовать не вчерашнюю версию, а трёх-четырёхгодичной давности. За это время все уязвимости уже находят и вычищают. А фичи не так важны, по сравнению с безопасностью.
А я люблю, во-первых, не регать домен, а прописывать его в hosts.
Во-вторых, добавлять спец. токен в заголовок HTTP запроса или выставлять спец. куку с дальнейшей проверкой на нжинксе.
А таких экспертов как ты, мы после собеседования быстренько и с радостью забываем.
Зачем вы врете. localhost в hosts уже прописан, а зарегистртровать данный домен вы бы все равно не смогли.
Однажды найдётся тот, кто сможет, и вам всем хана.
Ты однажды не прошел себеседование?
Сказал, что твой hosts лежит тут: c:\windows\system32\drivers\etc\hosts ?
Я извиняюсь, а синкать этот hosts как? Не боитесь, что хост, с которого синхронизируются hosts на всех хостах, окажется скомпрометированным, и вот тогда наступит такой звездец, что описанные в статье проблемы покажутся детскими играми?
Не надо нагонять фантастической отсебятины, попробуй дочитать до конца, то что написано после "во-вторых".
Не торопись.
Как определить, что запрос на сервис приходит от сотрудника компании, похоже, для некоторых является непосильной задачей.
Компрометация учётной записи сотрудника? Нет, не слышали. Взлом личного ПК сотрудника? Не бывает. Твои доморощенные ухищрения могут только позабавить взломщика.
Это называется "с кем угодно только не со мной"
Т.е. ты не в состоянии осознать, что от риска невозможно избавиться совсем, а лишь уменьшить его степень?
Ты зачем эту чушь сюда пишешь, тебе не хватает внимания?
> Ты зачем эту чушь сюда пишешь, тебе не хватает внимания?Не надо проецировать.
Не надо вступать в диалог, если ты не способен донести свои мысли до собеседника.
Я не распарсил, что ты мне важное хотел сообщить.
> Я не распарсилЭто твои проблемы.
ты свою глупость с hosts озвучивай еще на предварительном этапе - не придется собеседовать.
Чтобы кого-то собеседовать, нужно чтобы тебя сперва позвали проводить собеседование, оказали тебе доверие. Если ты еще на разобрался для чего нужен hosts файл, то шансов ноль.
Ну вот тебе оказали, а ты чужое время даром тратишь (если не нафантазировал, что больше похоже - кого админ локалхоста собеседовать-то будет). Ты бредни про хостс и свое сокровенное знание "для чего нужен" - с гордым таким пафосом - озвучивай еще когда договариваешься предварительно.
Сразу дело на лад пойдет.P.S. а идея хорошая. Добавлю-ка я вопрос в методичку. Позволит сразу же отсекать админов локалхоста. А то я им обычно сложные вопросы задаю, а это плохо.
>> с гордым таким пафосомПравка hosts это пафосно, да.
Гордо зашел в /etc.>> Добавлю-ка я вопрос в методичку
Добавь, на опеннете пригодится хе*ней страдать.
Методичка неотъемлемый аттрибут троля, спалился.>> А то я им обычно сложные
Если бы, обычно ты сидишь тут постя высокоиэмоциональные малоинформативные ментальные выделения.
Что за контора? Напиши, чтобы не ходить на собес к таким гениям.
Не знал, что в секту админов локалхоста собеседования проводят….
Думал они так кучкуются…
> Халатное отношение администраторовКривые руки разработчиков ни при чём.
Абсолютно!И зависимости всего от всего, как и сама идея в систему для ревью кода пихать обработку jpeg не jpeg на базе первой попавшей под руку библиотечки - тоже непричем.
Это все плохие, плохие админы, не ставящие каждый день новую версию, только что из под хвоста выпавшую (ну и что что она базу похерила? Зато уязвимость исправлена! И две но...ой. ну я уже исправил же ж!)
https://www.freebsd.org/cgi/ports.cgi?query=gitlab-ce&stype=allбедные админы, такую кучу апдейтить :)
> https://www.freebsd.org/cgi/ports.cgi?query=gitlab-ce&stype=all
> бедные админы, такую кучу апдейтить :)модераторы забаньте ету ссылку пожалуйста она опасна для психического равновесия
случайно накликанное по ссылке:
Requires: <blablabla>rubygem-sshkey-2.0.0<blablabla>
rubygem-sshkey-2.0.0
Generate private/public SSH keypairs using pure Ruby
Requires: <blablabla>indexinfo-0.3.1<blablabla>indexinfo-0.3.1
Utility to regenerate the GNU info page indexтеперь и вы это увидели. живите теперь с этим.
PS
утром увиденное на HN
Creating a simple React app with create-react-app makes us fetch an absolutely absurd amount of code, files and folders under node_modules:
Size: 138 MB (145 255 382 bytes)
Size on disk: 181 MB (190 013 440 bytes)
Contains: 35 894 Files, 5 503 Foldersтут не исправить уже ничего, Господь, жги!
А что это значит?
зависимости всего от всего.
Правда, у bsd pkg есть особенность - показывать те, что получаются если все делать по-умолчанию, никак это не комментируя. После ручных правок конфига оно иногда резко снижает аппетит.Но часто гораздо большего можно добиться правкой мэйкфайлов, просто повыбрасывав оттуда половину содержимого *DEPENDS
Пока у меня оставались еще фряхи в не-следовом количестве, примерно так это и делалось. Экономило терабайты траффика.
>модераторы забаньте ету ссылкубезобидная ссылка, кошмар когда после установки сделать pkg info :)
> на базе первой попавшей под руку библиотечкиНу так напишите альтернативу ExifTool, с дамами и оптимизациями, охватив хотя бы графические форматы :) На безопасном Rust, конечно, бо на ржавом из под хвостов почти ничего и не вываливается - всё в головах...
альтернативу exiftool для использования в гитшлаке можно написать вот так: /bin/false
Потому что она там вообще НАХРЕН не нужна.А если бы даже и была нужна - для того, что оно там делает - я тебе такую альтернативу напишу на shell+od.
Но макакам платят не за умение выбирать инструменты и не за умение правильно их использовать.
> Потому что она там вообще НАХРЕН не нужна.Вот - да.
Г-б имеет право на фанатов и существование, но как кусок софта - решение многогранное с признаками ненужного плохого. Кому неосмотрительно нравится - на здоровье. Но сам по себе содержит много, из-за чего не стал бы использовать (в т.ч. выставление ультиматумов заплатившим пользователям) и не рекомендую подсаживаться на Г.
хрен знает (мы не разработчики поэтому может просто слишком мелко для него плаваем) - но лично я в нем вообще не увидел причин его использовать во внутренней разработке. То есть чудище обло, озорно, стожопно и в дырьях, а полезного выхлопа около нуля.Все попытки его использовать были в режиме "ну нам же нужна какая-то авторизация и иерархия цвета штанов для доступа к гит репам!" - разумеется, это ровно то для чего он вообще не предназначен.
А те кому надо было именно совместную работу с кодом - ревью/ci/прочую чухню для команды - те даже не рассматривают, с чего бы это...
>>>ExifTools
>>>первой попавшей под руку библиотечкиdude.
>>>Это все плохие, плохие админы, не ставящие каждый день новую версию, только что из под хвоста выпавшую (ну и что что она базу похерила? Зато уязвимость исправлена!
получи свой экземпляр RCE и радуйся безоблачной жизни дальше.
> на базе первой попавшей под руку библиотечкиМожно подумать, вдумчиво отобранная библиотека гарантированно на 100% свободна от багов.
> Кривые руки разработчиков ни при чём.Уязвимость то по факту в 3rd party
Но ответственность за её проявление в GitLab целиком на разработчиках GitLab, которые сумели приплести в зависимости код с низкопробной репутацией в области безопасности. Про передачу загруженных без аутентификации файлов монстру, который выбирает обработчик по заголовкам, а не расширению файла я вообще молчу.
> которые сумели приплести в зависимости код с низкопробной репутацией в области безопасностиКак должны были поступить разработчики gitlab? Предложите план действий.
Не нравится exiftool? Что использовать вместо него?
> Как должны были поступить разработчики gitlab?пойти вон из профессии.
> Не нравится exiftool? Что использовать вместо него?
научиться кодить или пойти вон из профессии.
exiftool писали из соображения что его к своим exif'ам применяет владелец файла. А не что его в скрипте вызывают абы для чего для любого невалидированного мусора.
> пойти вон из профессии.
> научиться кодить или пойти вон из профессии.ясно-понятно
>Как должны были поступить разработчики gitlab? Предложите план действий.Как минимум сразу дропнуть нафиг запрос от хрен пойми кого, а не пытаться обрабатывать присланные им фоточки.
Даже без относительно наличия уязвимости - какого черта этот мусор вообще куда-то передается и обрабатывается? Зачем они тратят ресурсы на обработку заведомо мусорного запроса?
мир просто еще не понял что им управляют прагматичные русские, у которых каждый угол научно обоснован
>> Халатное отношение администраторов
> Кривые руки разработчиков ни при чём.Ты не задумывался ради чего назначаются виновные? Какой в этом смысл?
Один из ответов на этот вопрос: задача вины указать на того, кому в будущем следует изменить своё поведение, дабы не повторять ситуацию. Администраторы, которые ждут, что в софте в их серверах не найдут никогда дыр -- главные кандидаты на то, чтобы менять своё поведение. Программистам тоже следует быть внимательнее, но это "следует" говорят и пытаются привести во исполнение уже чуть ли не сто лет, и до сих пор никому не удаётся. Обвиняй программистов, не обвиняй программистов -- от этого ничего не меняется. С тем же успехом ты можешь обвинять гравитацию в том, что стоило тебе только шагнуть с обрыва, как она тебя разогнала вниз и ударила больно о камни: эти обвинения не приведут к тому, что в следующий раз гравитация поступит иначе. Программисты со своей стороны сделали всё возможное: баг-репорт приняли, выкатили патч, и с тех пор уже полгода прошло.
Или ты предпочитаешь другой ответ? Может задача вины указать на того, кто будет платить за повреждения? Но разработчики GitLab написали "WITHOUT ANY WARRANTY OF ANY KIND". А значит с них все взятки гладки.
А в целом, если тебе интересен вопрос назначения вины, то глянь сюда: https://en.wikipedia.org/wiki/Proximate_and_ultimate_causation
И ещё можно сюда: https://en.wikipedia.org/wiki/Proximate_cause или сюда: https://en.wikipedia.org/wiki/Why%E2%80%93bec...
За каждое действие нужно нести ответственность, как повашему кто несет большую ответственность, обезьяна с гранатой, человек оставивший без присмотра обезьяну и гранату, или создатель гранаты, может продавец?
мораль сей басни такова, виновный всегда найдеться, а ответственность не несет только дурак или обезьяна.
Работает - не трогай, да посоны?
Все верно, только у адекватов, подобные сервисы не торчат опой наружу - типа заходи любой и начинай сканить на уязвимости. А неадекваты, рано или поздно будут наказаны за свои головотяпство и детскую посредственность.
если убрать табличку "минное поле", то можно разбивать кемпинг и детскую площадку. это адекватно?
> если убрать табличку "минное поле", то можно разбивать кемпинг и детскую площадку.
> это адекватно?конечно. Заодно и мины сработают - вот и почистили.
Как-то с аналогией совсем все плохо.
Адекватно выстроить когруг забор от свободного проникновения третьих лиц, обычно так и делают.
Гарантирует ли это 100% защиту? Нет не гарантирует, тем не менее это снижает риск.
Тут прямо развернулась дискуссия про банальное, удивлен, что нужно что-то объяснять по этому поводу.
>формат определялся в ExifTool по MIME-типу содержимого, а не расширению файлаПора включать в олимпийские виды спорта прыжки на грабли
> GitLab вызывает ExifTool для всех файлов с расширениями jpg, jpeg и tiff для чистки лишних тегов)Что за безобразие? Почему какой-то там гитлаб решает что эти теги лишние? Какой криворукий это сделал?
Можно подумать, что там только один криворукий, а все остальные - няши.https://gitlab.com/gitlab-org/build/CNG/-/blob/master/shared...
Кто сколько косяков насчитает? (помимо того, что скрипт написан тем местом, на котором нормальные люди на стуле зиждятся)
>Халатное отношение администраторов серверов с GitLabШикарно!
Наговнокодить дырень эпических размеров, залатать её и сидеть молчать в тряпочку пока не начнется её активная эксплуатация - это мы можем.
Иметь инсталлятор который почти при каждом апдейте выдает какие-то проблемы которые приходится идти гуглить пока сервер лежит - это мы тоже можем.
Но виновато во всем конечно-же халатное отношение админов.
Какого вообще черта данные от неавторизованного пользователя как-то обрабатываются и куда-то там передаются?З.Ы. У апрельской статьи на хабре с описанием релиза 13.10 символичненькое такое название подобралось "Вышел релиз GitLab 13.10 с улучшениями для администраторов и управлением уязвимостями"
Ты как бы когда берешь софт, всегда его используешь на свой страх и риск.
И как бы да, задача админа в первую очередь сделать так, чтобы запросы от всякого левака в принципе не доходили до подобных сервисов. Это азы безопасности, нулевой уровень.
И как бы да, когда какая-то шваль пробьет корпоративный сервак, ты будешь с выпученными глазами окуня, с багровым лицом, пытаться объяснить как такое могло произойти.
а "шваль" за соседним столом будет тихо лыбиться в бороденку.И никакими, дурачок, своими подпрыгами и попердываниями ты от такого поворота не защитишься.
А иметь будут - тебя, дурака. И про азы и безопастность будешь подкудахтывать в процессе имения.У умного, разумеется, либо нет никакого гитхлама, либо есть подписанное руководством письмо с объяснениями, почему этот хлам изначально недоверенный и нет ни гарантий его работоспособности, ни гарантий от троянцев внутри и снаружи, и что риски принимает на себя тот, кто жить без этой мусорки никак не мог.
1) Откуда у "швали" с бородой токены к запросам?
2)
>> И никакими, дурачок, своими подпрыгами и попердываниями ты от такого поворота не защитишься.
>> А иметь будут - тебя, дурака. И про азы и безопастность будешь подкудахтывать в процессе имения.Похоже в моем тексте ты увидел себя, иначе как объяснить столь негативную эмоциональную реакцию?
3) Причем тут гитлаб? Он один в этом мире с дырами?
Пиши еще, жду с нетерпением.
> 1) Откуда у "швали" с бородой токены к запросам?а ты как думаешь?
> 3) Причем тут гитлаб? Он один в этом мире с дырами?
нет, гуанософта в мире дохрена. Это вовсе не означает что надо бежать вприпрыжку его ставить и потом всем рассказывать какой ты крутой и гениальный - аж закрыл его от интернетов (а на деле тебе никто внешний адрес и не даст - только это ни от чего не поможет). Может плохо обернуться.
>> а ты как думаешь?Мифический персонаж с бородой это плод твоей фантазии, ты и объясняй откуда у него токены.
>> ты крутой и гениальный
Неужели ты попал под огромное впечатление от "моей крутости", когда я озвучил простую мысль о том, что задача админа заниматься в том числе разграничением доступа к ресурсам?
> а на 29% систем определить номер используемой версии не удалосьУязвимость в GitLab, позволяющая определить версию установленного ПО.
> Судя по проведённому 31 октября сканированию глобальной сети из 60 тысяч публично доступных экземпляров GitLab, только на 29% систем определить номер используемой версии не удалось.
ftfy
> (metadata
> (Copyright "\
> " . qx{echo test >/tmp/test} . >\
> " b ") )Очередная победа свободы.
Очередной фанатик несвободы
И на затравочку:
#ЗАТОНЕГИТХАБ
ЗАТОНЕ ГИТХАБ ?Чеб ему тонуть...
А вот GitFlic неуязвим!
даже не знаю, с чего начать, все такое вкусное.во-первых, очередное стопятьсотое последнее китайское напоминание - не суй в eval() нечищеный ввод от пользователя.
во-вторых, настройки этого гитлаб комбайна по умолчанию доставляют:
A few months ago one of our customers found two suspicious user accounts with admin rights on its Internet-exposed GitLab CE server, and asked us to investigate what it looked like a security incident. Here’s what we found:
1) Between June and July 2021, two users were registered with random-looking usernames.
This was possible because this version of GitLab CE permits user registration by default. Moreover, the email address specified during the registration phase isn’t verified by default, thus the newly created user is automatically logged on without any further steps. In addition, no notifications are sent to the administrators.
прикольно, когда такое счастье торчит голым восьмидесятым портом в интернеты, да?
там, наверное, етот олень^Wкастомер еще и админский пароль adminadmin не поменял.
третье,
патч для этой дыры был доступен с апреля,
CVE опубликована в мае,
експлоет для дыры доступен на гитхабе с июня,
гитлабовское сесурити раздупляется постом "Action needed" в ноябре, когда уже новость о ботнете из гитлаб инсталляций на первой странице HN засветилась.
30 тысяч аленей^Wадминов етих гитлабов не знают про дыру до сих пор, и им норм. кто вообще читает ети устаревшие рассылки ети релиз нотесы с от такими большими буквами "GitLab Critical Security Release", только такие старые пердуны, как я.
/rant
Новые люди рождаются каждый день и так же каждый день появляются новые программисты, это для тебя стопятьсотое последнее китайское напоминание, а для них --- это первый раз.
и просто вдогонку:GitLab прекращает использование имени "master" по умолчанию
11.03.2021 20:57
https://www.opennet.ru/opennews/art.shtml?num=54743
зато тут и в бложике отметились, и в твиторе написали.
11 утра суббота 5 ноября, а я уже истратил месячный лимит на веру в человечество за декабрь.
> GitLab прекращает использование имени "master" по умолчаниюТеперь будет "black master"
Запретили мастер, теперь все заходят через черную дыру
BHM
Вся суть опенсорса - сторонняя библиотека, с открытым кодом, который никто и не собирался смотреть, кроме атакующих. Гыыы. Страдайте опенсосники.
Это называется квалификация. Только не та что теоремы да формулы в голове как ошибочно пологает большинство.
>> некорректной обработкой загружаемых файлов, позволяющей удалённо выполнить свой код на сервереКак это работает?
if ...
else
eval(args) & process.start(args);
??