Есть такой миф, что открытое программное обеспечение более качественное и безопасное, чем закрытое. Много раз это обоснованно ставилось под сомнение. Существует примеры, когда в открытом коде находили эпичные уязвимости, которые скрывались от разработчиков и пользователей долгие годы. Я считаю, что качество проекта зависит от того, как руководители разработки построили процесс и какие методологии/инструменты используются, а не от того, открыт или закрыт проект.
Тем не менее по-прежнему живо поверье, что открытый проект — это хорошо. Мол, тысячи глаз людей могут изучать код, и кто-то да заметит ошибку. Мысль развивать не буду, думаю, вы понимаете, что я имею в виду.
Как разработчик PVS-Studio, нашедший несколько тысяч ошибок в открытых проектах, я очень скептически к этому отношусь. Во-первых, я сомневаюсь, что так уж часто кто-то из этих абстрактных сторонних людей на самом деле ищет ошибки и уязвимости. Во-вторых, будучи как раз этим редким человеком, я могу утверждать, что разработчикам часто до балды эти старания. То есть самим разработчикам может быть неинтересно качество и надёжность их проектов. Им интересны новые фичи или что-то ещё, а не потенциальные проблемы и дефекты безопасности.
Множество раз мои сообщения про найденные ошибки игнорировались или откладывались в дальний ящик авторами открытых проектов. Хочется proof'ов? Пожалуйста. Сегодня у меня как раз есть красивый жирный пример.
Меня cподвигло написать эту мини-заметку неожиданное письмо от багтрекера проекта Samba. Я сначала даже не понял, что это за письмо такое. Оказывается, добрались до ошибок, отписанных мной ещё 9 лет назад! Bug 9320 — PVS-Studio.
Девять лет всем всё равно, что в проекте баги. Девять лет всем всё равно, что в проекте присутствуют старые версии библиотек с потенциальными уязвимостями типа CWE-14. Да, собственно, и сейчас, пока я пишу эти строки, в коде присутствуют всё те же опасные вызовы memset. Например, здесь:
static void
md_result(MD_CTX * ctx, unsigned char *dst)
{
SHA256_CTX tmp;
memcpy(&tmp, ctx, sizeof(*ctx));
SHA256_Final(dst, &tmp);
memset(&tmp, 0, sizeof(tmp));
}Или здесь:
static void
calc(struct md2 *m, const void *v)
{
unsigned char x[48], L;
const unsigned char *p = v;
int i, j, t;
....
memcpy(m->state, x, 16);
memset(x, 0, sizeof(x));
}Вызовы этих memset компилятор удалит, и приватные данные будут продолжать находиться в памяти. Если вы далеки от этой темы, то разобраться, что к чему, поможет статья "Безопасная очистка приватных данных".
Возможно, конкретно эти баги и дефекты безопасности никакой реальной беды и угрозы не представляют. Дело в другом. Разработчикам проекта всё равно. И сторонним разработчикам всё равно. Никто не берёт и не исправляет хотя бы те баги, которые можно взять и найти с помощью PVS-Studio. И даже уже найденные баги не торопятся исправлять.
Бомбанул. Стало полегче. Спасибо, кто выслушал :). Буду ссылаться на эту заметку, когда кто-то вновь заведёт шарманку на тему того, что открытый код безопаснее.
Комментарии (114)
uuuuuuuu
16.12.2021 18:54+15А сколько закрытых проектов вы проверили? И сколько багов в них обнаружили?
Andrey2008 Автор
16.12.2021 19:05+18Не так уж много, но проверяли. Подробности не расскажу в силу NDA. Ощущение: качество кода также варьируется, как и качество открытых проектов. Пруфов не будет, сорри. Вывод тот-же: от открытости почти ничего не зависит.
Lure_of_Chaos
16.12.2021 18:58+16Открытый софт не более безопасный, а *потенциально* более безопасный.
Более того, искать баги будут те, кто в этом заинтересован. А это - разработчики и преступники. Причем, про разработчиков (имею ввиду не конкретно девелоперов, а в целом бизнес) правильно отметили, что они больше заинтересованы в фичах и всяких свистелках, потому что это генерирует денежный поток. Исправление же ошибок всегда менее важно, особенно если эти ошибки не сразу заметны.
Остаются преступники, которые заинтересованы в поиске уязвимостей и совершенно не заинтересованы в их исправлении, по понятным причинам.
Кто остаётся? Энтузиасты? Да, они могут находить баги, но всё упирается в п.1 - желание разработчиков заниматься этими тикетами. Есть и ещё несколько "бонусов": чтобы находить ошибки, нужно обладать знаниями и опытом чуть выше среднего (в противном случае их бы исправляли ещё до релиза); ещё больше знаний, опыта и времени требуется чтобы найденный баг воспроизвести (поймать) и исправить. И зачастую как раз времени не хватает, т.к. сами девелоперы загружены требованиями бизнеса выкатить новые фичи и без того фантастически быстро.
Так мы приходим к интересной ситуации: да, открытый код может просмотреть и в теории исправить большее количество людей. но с другой: бОльшими для этого ресурсами обладают как раз крупные компании, а они открывать код до сих пор не очень любят.
-
В завершение вспомню эпизод из собственного прошлого, когда начальник мне втолковывал, что рабочее время необходимо тратить на код, "привносящий ценность продукта для клиента", а рефакторингом и мелкими улучшениями я могу заниматься в свободное время бесплатно, если у меня есть такое желание. Хорошо, что ему не пришла мысль штрафовать за баги, но я не стал этого дожидаться и ушёл из компании.
Случай может показаться надуманным, но он правдив, и хотя (к счастью) таких заявлений я больше не слышал, он показывает общее стремление бизнеса и объясняет, почему софт настолько забагован, а ошибки не исправляются независимо от открытости кода.
borovinskiy
16.12.2021 20:30-3Ну собственно начальник прав, программа нужна чтобы нести ценность клиенту.
Про "писать в свободное время", это он про расстановку приоритетов (компания платит не за идеальный код, а за такой, который устраивает клиента), его не надо буквально понимать -)
cepera_ang
16.12.2021 21:33+5Только ценность клиенту не нужно понимать однобоко — тормозная глючная программа конечно несёт клиенту больше ценности, чем никакая. Но быстрая и надёжная несёт ещё больше и зачастую именно сочетание скорости и надёжности открывает новые возможности и сценарии использования, даже в самом насквозь энтерпрайзном и скучном софте.
Проблема в том, что клиент и знать не будет о том, что это возможно пока не попробует. Представьте мир, в котором поиск в интернете выполнялся бы, ну хотя бы за минуту, а ещё лучше за 10 минут, а не за 0.1сек. И раз в десять запросов выдавал бы мусорный ответ. Насколько меньше бы люди пользовались поиском? Нес бы гугл такую ценность миру как сейчас, даже если результаты были бы идентичны?
Earthsea
17.12.2021 09:49-3Представьте мир, в котором поиск в интернете выполнялся бы, ну хотя бы за минуту, а ещё лучше за 10 минут, а не за 0.1сек.
Лучше сутки. Мир был бы прекрасен. Люди не искали бы всякую чушь, и не тратили бы время на чтение буллшита и покупку всякой ненужной дряни. Было бы меньше гугл-специалистов, которые без интернета под рукой не могут ничего выполнить, и больше реальных специалистов с твердыми знаниями. А кому надо что-то поискать по делу, могли бы заранее записывать свои запросы в блокнот, расставлять приоритеты, вычеркивать лишнее.
Lure_of_Chaos
17.12.2021 18:04+4Такие времена уже были - когда компьютер не умещался у вас в кармане, а занимал целое здание. Когда отлаживать программу приходилось не в удобной IDE пошагово, а (в уме) на листочке, затем регистрироваться на доступ к компьютеру, и на следующий день приходить проверять - сработало или нет. Если нет - то снова думай, почему, и запись на следующий день. Причем программа выполняется примерно тот часовой промежуток времени, на который ты регистрировался. Т.е., запустил вычисления - жди, через час тебе результат, иди домой думай.
И в этом не было ничего прекрасного - ту программу, которую сегодня может за полчаса написать вчерашний студент, писали единичные профессионалы месяцами; результаты достигались не просто нервами, а потом и почти кровью. Но - чуши меньше не было, просто она была оффлайн - в кафе, на улицах, домашних кухнях.
Спасибо Интернету и в целом техническому прогрессу за то, что мне не нужно учить в самом деле чушь - таблицы чисел с точностью до 8 знака после запятой, названия функций и порядок параметров, тонкости различий процессоров и т.д., а могу заняться именно тем, чем мне нравится заниматься - созданием софта, который работает приемлемо неплохо.
svr_91
17.12.2021 09:53+2И раз в десять запросов выдавал бы мусорный ответ.
Ну сейчас он 9 раз из 10 выдает мусорный ответ. В итоге таже минута на поиск и получается (на самом деле гораздо больше)
cepera_ang
17.12.2021 13:20+1Минута и даже десять на результативный поиск — это же отлично. Лучше только если вы уже знаете ответ — тогда можно за 30 секунд воспроизвести из головы. Ещё лучше — когда за вас думать начнёт и само себе вопросы задавать. Но до этого пока не дошли.
А если бы у вас на каждую попытку уходило десять минут, а то и день (как во времена библиотек), то вы бы просто не стали делать подавляющее число запросов. Как сейчас не делаете никаких спонтанных запросов в архивы, типа "о, любопытно, а где мой прадед по отцовской линии жил в такие-то годы? А в эти? А кто соседи были? А то? А сё?"
svr_91
17.12.2021 14:56Я думаю, это от порядка величин зависит. Если на одну попытку будет уходить минута, ничего страшного, переживем. Врядли чтото сильно изменится. Если 10 минут - то уже да, сильно хуже
cepera_ang
17.12.2021 17:37А вы попробуйте. Откройте DevTools, Network и создайте кастомный профиль сети с задержкой 60 000 мс и попробуйте прожить так денёк (придётся оставить открытыми девтулс, да). Только честно, без "да я попробовал загуглить
хабр, ну подождал минутку, нашёл что ожидалось, ничего не изменилось в ощущениях, дальше нет смысла продолжать и так всё понятно".svr_91
17.12.2021 17:46Ну вот сейчас я попробовал на старом телефоне (которым только бросил пользоваться) выполнить свой стандартный путь "найти что-нибудь": разблокировать экран, запустить wifi, открыть браузер, ввести запрос, дождаться загрузки. На это у меня ушло 36 секунд. Всего в 2 раза меньше минуты. А мне это приходилось делать каждый раз, когда хотелось чтонибудь найти, и я этого даже не замечал
cepera_ang
17.12.2021 18:48+1Если не умничать и не углубляться во всякие сложности типа latency amplification (не гуглите! это займет минимум десять минут даже с нормальным гуглом), но даже ваш старый телефон — это не тоже самое, что каждый запрос и всегда по минуте, с одной стороны, то, как используется гугл, дающий мгновенные ответы — с другой.
- На телефоне, после всех этих долгих стартовых действий, каждый очередной запрос, например уточняющий запрос по результатам поиск — занимает уже не по 40 секунд, а скорее "время ввода + пара секунд" и можно аргументировать, что время ввода вообще нужно исключить, потому что оно зависит от пользователя и тут чудес нет (хотя голосовой ввод + подсказки вносят приличный вклад). Итого серия из 10 запросов будет не 6 минут, а скорее 2-3. С минутным ожиданием было бы 15 минут.
- Ваш пример с телефоном звучит как довольно долгий доступ к гуглу, который гарантированно повлиял на ваше желание что-то искать, даже если вы этого и не замечали. Зная, что поиск займет "36 секунд" вы заранее отфильтровываете "ерунду", которая не стоит того, чтобы тратить на неё столько времени. Открытый же в отдельной вкладке на 4к экране поиск позволяет искать любые вещи практически без трения, и это пробуждает скрытый до этого спрос на эти действия. Почему не сослаться на доступные через 10 секунд (в худшем случае через минуту) данные в разговоре на хабре? Почему не узнать что такое харамамбура, если вдруг пришла такая мысль? У меня сегодня был спокойный день и я ничего целенаправленно не ресёрчил, но поиск по истории браузера (ха, опять поиск, который легко сделать) показывает, что я сделал около сотни запросов. Сколько было бы с минутной задержкой? Ну, наверное самые важные пять.
svr_91
17.12.2021 19:10каждый очередной запрос, например уточняющий запрос
Как правило, на какой-то итерации я обычно бросал это дело и садился за комп. Но скорее не из-за долгого отклика чего либо, а из-за моей неспособности набирать что либо на мобильной клавиатуре.
Но у меня есть и опыт пользования компьютером в детстве, когда инет был очень медленным (уж не знаю, насколько, но точно медленнее чем сейчас). И привычки формируются быстро - например, открыть сразу несколько вкладок с результатами поиска, и пока читаешь одну, остальные уже догрузятся
Зная, что поиск займет "36 секунд" вы заранее отфильтровываете "ерунду", которая не стоит того, чтобы тратить на неё столько времени
Видимо у нас и правда разные паттерны использования интернета. Я и сейчас, с быстрым интернетом, всегда фильтрую "ерунду", и ни разу не гуглил что такое харамамбура, даже сейчас, представьте, не хочу. Так что может быть я и вправду намного легче переживу резкое замедление интернета, в отличие например от вас
cepera_ang
17.12.2021 19:34+1Гугл — это был просто пример, но общий паттерн один и тот же: люди неосознанно избегают действий, которые воспринимаемо "дорого стоят". Методы работы, креативные возможности и т.д. — радикально меняются, когда очередная итерация возможна в интерактивном режиме. А замедление интернета я переживать не собираюсь, также как не готовлюсь, ну не знаю, жить в мире без унитаза и душа с горячей водой.
Wesha
17.12.2021 10:56+1Представьте мир, в котором поиск в интернете выполнялся бы, ну хотя бы за минуту, а ещё лучше за 10 минут, а не за 0.1сек.
Есть такой мир, Марсом называется.
cepera_ang
17.12.2021 13:21+1Думаю там вполне себе будет стоять локальная копия индекса, во временем.
Shaz
16.12.2021 22:59-1А если из-за багов программа ещё и уносит ценности клиентов налево?
Хотя понятно что это будет проблема клиента и юристов а не начальника.
borovinskiy
17.12.2021 12:38Клиент заведет тикет, баг исправят.
Программист, устраняя баг из тикета, будет нести пользу бизнесу.
Здесь все-таки надо правильно акценты расставить, не что баги - это хорошо, не что плохой код - это хорошо, а что в оплачиваемое время работнику надо работать то, что от него работодатель хочет, а не то, что работнику кажется важным, а работодателю не важным.
Что хочет работодатель - доносит менеджер проекта или начальник, если такая иерархия.
Mike-M
18.12.2021 02:47+1Клиент заведет тикет, баг исправят.
При этом:- Клиент будет вынужден потратить свое время на заведение тикета, хотя изначально на это не рассчитывал.
- Клиент будет вынужден ждать выхода исправления. Кроме того, не все баги удается исправить корректно с первого раза.
- Пара-тройка таких тикетов, и репутация Вашей компании/продукта в глазах клиентов будет основательно подорвана.
Программист, устраняя баг из тикета, будет нести пользу бизнесу.
Программист принесет еще больше пользы, если вместо того чтобы постоянно отвлекаться на тикеты, он будет заниматься новым функционалом. Ибо давно и многократно доказано, что Task switching is a costly process.borovinskiy
18.12.2021 08:46Здесь видимо каждый о своём.
Проекты, в которых 3 ошибки - это много и повод отказаться от подрядчика - это какие-то микропроекты.
Mingun
18.12.2021 12:53Тут, так, к слову, а вы на новом интерфейсе хабра или на старом?
borovinskiy
18.12.2021 13:11А не знаю, на новом наверное.
Mingun
18.12.2021 13:28+1Просто тут за последний месяц было очень много жалоб на новый редактор хабра. И параллели с этим тредом уж очень четкие просматриваются.
Am0ralist
18.12.2021 10:39Пара-тройка таких тикетов, и репутация Вашей компании/продукта в глазах клиентов будет основательно подорвана.
Гы… на моём счету сотни тикетов от заказчика поставщику САПР при внедрении оного на производство.
А другие местные ещё хуже, иностранные — дороже на порядки и тоже не сахар в плане автоматизации производстваMike-M
18.12.2021 12:50+2Помнится, в советские времена большинство автолюбителей ездили на Жигулях, Москвичах и Запорожцах. Некоторым удавалось пересесть на лучшее, что было в те времена — Волгу. Но даже Волга была барахло по сравнению с Мерседесом.
Когда деваться некуда, приходится выбирать лучшее из худшего. И допиливать по ходу пьесы, как в Вашем примере. Тут вопросов нет.Am0ralist
18.12.2021 12:57Скажем так, мерсы купить можно было. Но допиливать их бы пришлось уже СВОИМИ руками.
Не, я знаю такую контору, у которых одних только вакансий программистов C# висело постоянно столько, что можно было уже свою студию разрабов запилить, при этом на части производства, кстати, использовался уже тот российский САПР (то есть в основном для дизайнеров делалось)… Зато солидворкс же! И да, грубая оценка затрат на разрабов за много лет и стоимостей лицензий солида, а так же процессы обучения, почему-то у меня в голове превышает стоимость покупки студии из коломны целиком или хотя бы на 50%)))
Lure_of_Chaos
17.12.2021 17:51+1Разговор изначально был о том, что квалифицированный программист сразу пишет идеальный код, и закладывать рабочее время на исполнение технического долга - нельзя, это трата впустую. Ну а если ты не можешь предусмотреть сразу все возможные сценарии, ошибаешься и т.д. - ты плохой программист, трать нерабочее время на свои (что может быть чужие и т.д. - не рассматривается) косяки.
Ну т.е. да, до штрафов исполнителей за баги там было недалеко.
И это не расстановка приоритетов, это вынесение задач за рамки. И я очень рад, что в основном бизнес (уже?) не представляет себе радужных пони, а понимает, что это нормально, что программы могут содержать ошибки и на их выявление и устранение нужно закладывать время и деньги.
borovinskiy
17.12.2021 18:01Это какой-то странный бизнес. В нем поди и тестировщиков нет, раз у программистов сразу идеальный код?)
Lure_of_Chaos
17.12.2021 19:03Дайте-ка вспомнить. Это было давно, около 9 лет назад, да и проработал я там всего полгода... Но, по-моему, да, у них и тестировщиков не было - каждый программист нёс персональную ответственность за свой участок кода. Т.е. кто последний правил - тот и обязан проверить на идеальность, а заодно не внести собственных ошибок.
Wohlstand
16.12.2021 23:43+5А как же энтузиасты, которые не просто находят баги, а ещё исправляют их самостоятельно и отправляют разработчикам патчи? У меня как раз именно так и происходит, одна часть жалоб от простых пользователей, которые тупо нашли баг, но исправить не могут, или даже не знают её причины; и другая часть - те, кто присылает мне патч с исправлением и объяснением причин бага. С первой частью разработчики чинят ошибки в зависимости от настроения и приоритетов, а со второй частью разработчики даже спасибо говорят, если всё сделано всё чётко и качественно (ага, потому что сразу на блюдечке подали готовый результат, остаётся только заценить и принять или отправить лесом).
IkaR49
17.12.2021 09:37+3Возьмем, например, bullet. Там куча готовых к мерджу пулл реквестов висит больше 2 лет, а мейнтейнерам и дела нет.
Я лично тут в одну мелкую тулзину 3 ПР оформил на критические баги, и они уже больше месяца висят, но там это пет-проект одного человека, и я готов понять, почему у него нет времени.
Lure_of_Chaos
17.12.2021 18:07+1И вот в этом есть плюс открытого софта - можно его форкнуть, подправить баги, добавить фичи и поддерживать самостоятельно. Конечно, если и вам это надоест, но пользователям вашего форка будет больно, но, будем надеяться, найдётся другой неутомимый специалист, который форкнет ваш проект и продолжит поддержку.
khim
17.12.2021 00:07-3Открытый софт не более безопасный, а *потенциально* более безопасный.
Он и потенциально и реально более безопасный.
Просто если в коммерческом софте ошибки встречаются, условно, по штуке на тысячу строк, то в опен-сорсе — штука на десять тысяч строк.
Но и там и там уязвимостей — вагон и маленькая тележка.
Andrey2008 Автор
17.12.2021 16:43+2Просто если в коммерческом софте ошибки встречаются, условно, по штуке на тысячу строк, то в опен-сорсе — штука на десять тысяч строк.
Это мнение и фантазии, не более того.
Koval97
17.12.2021 05:16У меня был подобный начальник, когда еще был совсем зелёный. Тоже много прикалывался, подшучивал, душевный человек, но Team Lead из него такой себе - кормил директора завтраками, а ни одного прототипа за целый год не сделал.
С опытом повзрослевше понимаешь, что не всё нужно доносить таким начальникам, некоторые лучше понимают на контрасте, когда неожидано для себя замечают, кого они упустили. И умоляют вернуться обратно - часто это путь к гарантированному повышению, и договорится с ними по работе команды значительно проще после таких кейсов.
Всё это к тому, что не всё в этом мире делается так однобоко. Нужно понимать, что однажды на месте этих самых "руководителей" окажешься ты сам.
Lure_of_Chaos
17.12.2021 18:09+1Всё это к тому, что не всё в этом мире делается так однобоко. Нужно понимать, что однажды на месте этих самых "руководителей" окажешься ты сам.
Неожиданно, но... спасибо за предупреждение. Очень постараюсь так не делать.
Carburn
17.12.2021 12:12а если делать рефакторинг во время работы над задачей приносящей ценность клиенту?
panzerfaust
17.12.2021 13:48Прямой путь к постоянному регрессу. И с QA быстро отношения испортятся. Они взяли на проверку кейс А, а вы попутно нарефакторили еще и кейсы В и С, на которые ресурсы никто не выделял.
Lure_of_Chaos
17.12.2021 18:20Было в практике такое. Сразу вопросы в стиле "а чего так медленно?" со всеми санкциями.
Откровенно говоря, однажды меня так уволили за "профнепригодность". Наняли как Java-разработчика, а посадили на Javascript (который тогда я ещё не знал, это сейчас я могу хвастаться умным словом фуллстек), дали задачу, который я делал одновременно с изучением и языка и фреймворка и всех подводных камней, потом постоянно требовали переделать, а через неделю "забыли", что я только учусь и что вместо одного я делал несколько вариантов и с аргументом "на двухчасовую фичу потратил неделю??" распрощались. Я даже сопротивляться не стал, поскольку с моей стороны также хватило (например, там не пользовались никакой версионной системой, а девелопили напрямую в тест - спасибо, не прод; или переводы делали прямо на клиенте гуглотренслейтом пока в гугле не забанили)
Поэтому сразу видно, кто начальник ("исполнять!") и лидер. Поэтому важны честные диалоги, а не ухищрения (с любой из сторон)
semibiotic
16.12.2021 19:00+6Надо заметить, что в закрытых проектах ошибки те же, только их еще и нельзя увидеть ...
Andrey2008 Автор
16.12.2021 19:07+2Нельзя. Но это не значит, что возможность их видеть, так уж сильно влияет на качество.
0xd34df00d
16.12.2021 21:19+3Возможность их увидеть влияет на то, выберете ли вы эту библиотеку или нет.
Wesha
17.12.2021 06:13+2Но это не значит, что возможность их видеть, так уж сильно влияет на качество.
Это влияет на Ваше знание об этом качестве. И, соответственно, на Ваше знание о том, с чем Вам в процессе пользования продуктом придётся столкнуться — и, соответственно, на желание этим продуктом вообще пользоваться.
Когда я (в процессе ремонта) узнал, что кронштейны жалюзи в купленной мной квартире прикреплены при помощи не шурупов, а термопластичного клея; прокладка в кране, который в теории должен перекрывать воду к умывальнику, не садится полностью в седло; а трубка, которая подаёт водопроводную воду в холодильник (для изготовления ледяных кубиков) вообще непонятно куда подсоединена и как перекрывается (но вода из неё продолжает течь), стены дома узнали много новых матерных слов.
Та же фигня и с программными продуктами.
Lure_of_Chaos
17.12.2021 18:24Уточню: юридическая возможность, т.е. лицензия.
Т.е. в принципе возможно пропатчить бинарники (и я этим занимался, т.к. приходилось использовать стороннее решение, забагованное по самое небалуйся, но разраб исходники принципиально не хотел давать, а документация сводилась к "спроси у кого-то из разрабов"), но насколько хорошо и правильно ты это сделаешь, никто не гарантирует, как не гарантирует и отсутствие судебных исков.
aleks_pingvin
16.12.2021 19:11+1Таким образом если взять одну "сферическую команду разработчиков в вакууме" и попросить сделать два схожих приложения, но одно проприетарно, а другое опенсоурсно, то их баги приводящие к критической уязвимости в проприетарном коде всплывут (если всплывут) очень не скоро, а в опенсоурсном - может найти любой желающий, но велик шанс не обращать на них внимание годами (как с log4j2), но при этом ушлый злоумышленик может о них знать и потихому эксплуатировать.
mayorovp
16.12.2021 19:30+2Не уверен что там (в log4j) вообще баг был. Кажется, исходно он как фича задумывался, пока его эксплуатировать не начали.
sshikov
16.12.2021 19:51+1А велика ли разница? Там язык, если угодно. На котором можно было написать выражение, и его результат будет вставлен в лог вместо выражения. Но выж понимаете, выражение которое вызывает некий (произвольный) класс, а особенно взятый непонятно откуда, это потенциальная дыра. Даже если не считать багом в коде отсутствие проверки (белый список и т.п.), то баг в спецификации тут точно имеет место.
Потому что например в похожих API к примеру, можно написать "${expression}", но нельзя этот ${expression} интерпретировать просто так из переменной. Ну т.е. выражение — фича времени «компиляции» или времени конфигурирования, но в рантайме их формировать нельзя.borovinskiy
16.12.2021 20:37+1А как узнать, "оттуда" класс вызван или не "оттуда"? В логгере-то? Который по дизайну должен быть суперуниверсальным.
sshikov
16.12.2021 20:51+2Речь вообще про класс JndiPlugin.
Ну т.е. если у меня в конфиге log4j написано ${jndi:...}, то я ССЗБ, но я знаю, что я делаю, а если такое не написано (конфиги-то свои я могу проанализировать, надеюсь) — то в этих условиях он вызываться не должен вообще.
Те редкие люди, которые его реально применяли, вполне могут и доработать свое приложение. А остальные — кто его в глаза не видел никогда, просто его вырубят, чтобы он ничего не делал, не лазал на внешние хосты непонятно зачем, и все такое.
Логгер — он супер универсальный только в отрыве от конкретного приложения. В рамках же приложения вы вполне можете контролировать, что он будет логировать.
mayorovp
17.12.2021 10:34+1Разница в том, что фичу делали намеренно. Её же, блин, вообще можно параметром командной строки отключить!
sshikov
17.12.2021 10:38+1Ну конечно делали как фичу. Не считая того, что кто-то мог иметь в уме и другие варианты :) По умолчанию она включена. Опять же, я склонен считать, что баг в требованиях — нельзя было такую дырку делать, не продумав безопасность.
mayorovp
17.12.2021 10:52+1Вот-вот, баг именно в требованиях. Про это я и пишу.
Lure_of_Chaos
17.12.2021 18:29Думаю, баг в том, что не подумали, что в такое закрытое, как логи, можно протащить что-то извне. Да, сработал принцип "не доверяй внешним данным", да, можно было отключить, использовать проверки и песочницы, но по идее, в логи ничто не должно попадать "извне" и тем более не должно отдаваться наружу.
Честно говоря, мне всё ещё кажется несколько странным фильтровать и не выводить некоторые данные в лог, такие, как номера кредиток, заменяя их звездочками (для понимания поясню, например, замена регулярками)...
toxicdream
17.12.2021 12:28Проприетарный софт обычно продают. И если баги вылезают у клиента, то разработчиков дрючат, и соответственно над "выявленными" багами работают.
Условно можно разделить работу над багами по следующим критериям: выявляемость и исправляемость.
В проприетарном софте баги выявляются тестировщиками и пользователями, исправляются разработчиками в силу обязательств возникших при продаже.
В опенсурсном софте баги могут выявить другие программисты, которые условно и являются пользователями и тестировщиками, и это если ошибка возникнет уже у их пользователей, или же программисты-пользователи таки найдут ресурсы для чтения и анализа исходников, а изначальные программисты могут даже выявленные ошибки не исправлять поскольку у них может не быть заинтересованности, да и обязательства у них лишь моральные.
Баги будут в любом софте в силу человеческой природы. А вот от формы распространения софта отношение к багам уже отличается. Однако это различное "отношение" совсем никак не коррелирует с количеством "выявленных" и "исправленных" багов.
aleks_pingvin
17.12.2021 12:52+3проприетарный софт обычно продают. И если баги вылезают у клиента, то разработчиков дрючат, и соответственно над "выявленными" багами работают.
Да если бы так... Зависит от SLA. Чаще же всего звучит "ваше обращение зарегистрировано, спасибо за обратную связь, всего вам доброго, досвидания". В лучшем случае еще добавят номер тикета который может висеть бесконечно долго.
Lure_of_Chaos
17.12.2021 18:32Благодаря LGPL и иже с ними мы можем форкнуть либу, исправить баги и пользоваться форком.
Однако, следует различать "в теории можем" и "будут делать все". По-моему, пост именно об этом.
vdudouyt
16.12.2021 19:02>> 1000 глаз, которые не хотят проверять код открытых проектов
Интересно, как бы их проверил@Andrey2008, будь бы их исходники коммерческой тайной за семью печатями.Andrey2008 Автор
16.12.2021 19:07+5Ну вот проверил 9 лет назад. И что? :)
Wesha
17.12.2021 03:05А то, что пистон надо вставлять тому, кто решает, какому багу приоритет отдавать.
MAXH0
17.12.2021 06:31Вопрос, наверное еще и в том, что разработка за 35 лет шагнула далеко вперёд и это уже не интивидуальный процес свободного художника, как в лохматом 1985, а коллективный индустриальный труд. На тысячу глаз нужны сотня кошельков и десяток рук. И структура с невысокими накладными расходами, которая свяжет их во едино.
uuuuuuuu
17.12.2021 17:09-3А что разработчики должны были делать с таким баг-репортом? Куча замечаний в несвязанных между собой местах, которые могут привести к неправильному поведению, а могут и не влиять ни на что.
Andrey2008 Автор
17.12.2021 17:16+1И действительно, что это я. Потенциальная уязвимость CWE ведь может стать уязвимостью CVE, а может ведь и не стать. Так что пофиг. :)
Только не надо тогда ля-ля про качество открытого кода.
Lure_of_Chaos
17.12.2021 18:34А влияет ли иерархия форков на качество? Как Вам кажется? (в том смысле, что, по идее, форкают для исправлений и улучшений)
KanuTaH
16.12.2021 19:30+11По моему опыту, любые мейнтейнеры куда больше любят патчи, чем баги. Когда уже есть разумный патч, мейнтейнеры особо не сопротивляются его включению в основную ветку. Это я к чему - вместо открытия issue "а тут у вас memset" попробуйте предложить сразу исправление в виде pull request на GitHub или там патч в Gerrit. Мейнтейнеры открытых проектов работают над ними в свое свободное время за бесплатно, уважайте их труд.
fougasse
16.12.2021 19:47Очень смелое утверждение про время и бесплатность. Доказательств у вас, конечно же, есть достаточно?
Wesha
17.12.2021 07:13+3Ну вот я, например, мейнтейнер свободного проекта и делаю это бесплатно, в свободное время. И это не фигура речи.
Lure_of_Chaos
17.12.2021 18:36Хм, ну отчего же. Проверить и принять патч куда менее трудоёмко, чем самостоятельно выяснять и исправлять. Наверное, лучше, когда своё время и деньги потратит другой, и по "доброте душевной" предложит готовое решение, которое от вас не будет стоить почти ничего.
Semy
19.12.2021 00:26Есть личный опыт. Процентов 90 коллег по этому (международному) проекту были именно "в свое свободное время и за бесплатно". Остальные имели либо гранты, либо пожертвования, но все же имели основную работу, и только единицы были full-time.
Bobovor
16.12.2021 20:13-12Никогда не мог читать эту фразу иначе, как "уважайте меня за то что я делаю хрень".
Нет.
Терпеть, сожительствовать и принимать - да. Уважать - нет.
Эта фраза пахнет оголтелым коммунизмом из капиталистических страшилок 50-60 годов, где есть некий вася, который ничего не может, но претендует на такие же блага (в данном случае уважение) как некий петя, который может и умеет.KanuTaH
16.12.2021 20:18+10Если петя может и умеет, то что ж не делает? Пока от пети вместо дел одни претензии к васе, который что-то делает и дает пете пользоваться сделанным бесплатно и без ограничений.
Bobovor
16.12.2021 20:22-6Это строится на 2х допущениях.
Вася делает то, что кому-то нужено.
Петя этим пользуется.
KanuTaH
16.12.2021 20:27+13Samba - это весьма популярный проект, я бы сказал. Это как с OpenSSL - пользуются буквально все, а после истории с heartbleed оказалось что делают его три с половиной человека на $2K пожертвований в год, какая неожиданность. И рассказчики про вась с петями немедленно нарисовались, а как же.
Mingun
17.12.2021 20:27-2Интересно, а эти три с половиной человека пытались привлечь побольше народу? Ну хотя бы объявление вывесить на главной сайта и в Readme? Или как никто не ругал, так грудь колесом, а как пальцем тыкнули, так сразу я не я и вообще пилите сами?
Mingun
17.12.2021 20:22+1И тем не менее уже готовые PR даже всего в одну строчку висят годами, даже уже зааппрувленные людьми с правами мерджить (и это не единичный пример). Вот, кстати, завтра как раз годовщина, надо опять пингануть. Вы вот правильно сказали, что уважать можно за труд, только вот что-то этого труда-то и нет...
vvadzim
16.12.2021 20:05+17Основная проблема не в том, что
людипроекты смертны, а в том что закрытые проекты внезапно смертны. Умирает фирма, или решает закрыть проект - и вы остаётесь с бинарниками. Хотя мне по молодости было прикольно с бинарными патчами играться. Договора на поддержку не спасают. С открытым проектом шансы хоть какие то, они как-то дольше дохнут. Инерция у них что ли больше.
Vasyutka
16.12.2021 23:05+7вот да. открытый код - вообще не про "твори добро по всей земле - да еще 1000 глаз вам в помощь". Это вообще про другое - уменьшение рисков "смерти" мейнтейнера, внедрение открытых решений в существующий бизнес с в общем-то простой целью заработать впоследствии на его саппорте и/или подписке. В общем что-то сродни пиратских копий аудиокассет/дисков в 90х - потом просто собирать с концертов. Не понятно почему у автора пригорает.
Lure_of_Chaos
17.12.2021 18:43+4Кстати, да, спасибо. Открытостью решается именно тупиковая в закрытом софте ситуация "собаки на сене", когда софт или умер (разрабы забросили, обанкротились и т.д.) или зомби(софт вроде бы под разрабами, но его не развиваю), но взять под своё крыло мешает лицензия. Конечно, далеко не факт, что это будет (отчего у ТС и пригорело), но хотя бы не запрещено.
Mike-M
18.12.2021 03:04Точно.
Классический пример — Punto Switcher под крылом Яндекса.
Последнее обновление — 07.02.2019.Mingun
18.12.2021 13:01А зачем ему обновляться? Я даже не последнюю версию использую и обновляться не собираюсь, потому как в новых версиях только какого-то рекламного барахла добавили.
Версия 4.4.2 от 13.03.2018
сборка 334Работает, как часы
Mike-M
18.12.2021 14:43Как часы, говорите?
- Punto Switcher до сих пор не умеет переводить в правильную раскладку такие общепринятые слова как UEFI, .pst, FPS, LED, UI, firmware и еще нескольких дюжин.
- Нет возможности экспортировать список этих слов для оперативного импорта после переустановки программы или на другом ПК.
- Нет даже элементарной сортировки списка этих слов, чтобы исключить повторное внесение тех же элементов списка.
- Некоторые из этих слов не обрабатываются вообще, другие обрабатываются не во всех приложениях.
- Автозамена не всегда срабатывает в Word.
- После многодневного использования режима hibernate Punto Switcher начинает работать вообще непонятно как.
В любом случае, проект не обновляющийся больше года, — мертвый проект. И место таким проектам, на мой взгляд, на открытых площадках типа GitHub.
Наверняка найдутся желающие поддерживать, в целом, хорошую программу.
Если Яндекс поступит так со своим Punto Switcher, то компания, думаю, ничего не потеряет. Наоборот, многие скажут «спасибо!», и уважение аудитории к компании от такого подарка только повысится.
BarakAdama, просьба передать это ответственным за принятие решения лицам.
1fid
16.12.2021 22:54+5Первая проблема, описанная в вашем письме, поправлена 5 лет назад https://github.com/samba-team/samba/commit/caff67082a22b4b5250eb73b09e57bb9ab99c346
То есть 1000 глаз всё таки видят и даже правят баги, и опенсорс не так плох как вы описываете. Скорее дело в том, что ребята редко заглядывают в багзиллу.UPD а, так этот коммит и правит баг из багзиллы. Но другой баг, внесенный не вами. Выходит, что у ребят бардак в трекере, и ваш репорт просто-напросто потерялся.
Koval97
17.12.2021 06:07+1@Andrey2008 Не вы ли тут уже сотню раз объясняли, что в memset опасно передавать sizeof only, потому что оно считает размер первого элемента массива, а не всего массива. Попахивает, что разработчики по старой памяти из более высокоуровневых языков так пишут, а оно работает здесь немного с нюансом.
Теперь я прекрасно понимаю, откуда у начальника на моей первой работе была привычка определять предкомпиляцией размеры массивов и буферов (defined buffer size). Полезная практика, когда нужно передать не количество элементов, а размер в байтах. Оно и понятно, всё таки он игры делал под Windows 95/98 и после на заре 2000-х.
svr_91
17.12.2021 10:06Вызовы этих memset компилятор удалит, и приватные данные будут продолжать находиться в памяти
Видел гдето интересное обсуждение, а есть ли вообще смысл в "безопасной" очистке данных? Тоесть получается, что данные все равно какуюто часть времени пробыли открытыми, какая разница, удалят их потом или нет? Это с человеческой точки зрения есть разница между секундой и минутой (да и то не всегда), а с точки зрения компьютора в чем разница? Мне кажется, атаку можно придумать и на первый случай, когда ничего не очищается (снять в какойто момент времени дамп памяти и неспеша его просмотреть), так и на второй (снимать дампы памяти по чуть-чуть и смотреть на те данные, которые живут недолго). Или вообще поставить breakpoint на безопасный memset, и все пароли будут как на ладони :)
kovdan01
17.12.2021 10:21Не специалист, но сделаю предположение. Ваш процесс рано или поздно завершится, и его место в оперативной памяти сможет занять кто-то другой, и он сможет читать данные, оставшиеся "по наследству". От этого, думаю, и защищаются.
mayorovp
17.12.2021 10:35+1Ну нет, "по наследству" между процессами ничего не передаётся, ОС не позволяет.
kovdan01
17.12.2021 12:39Спасибо! Люди на форумах и в блогах действительно говорят, что и в Linux, и в Windows страницы памяти зануляются перед передачей другому процессу. Но я не смог найти никаких "официальных" подтверждений этому (скажем, статей на kernel.org или MSDN). Подскажите, пожалуйста, где можно найти системное изложение темы? Хочется иметь какое-то подобие документации, с которой можно сверяться и на которую можно ссылаться.
mayorovp
17.12.2021 12:45Это настолько общепринятое поведение, что я не уверен что оно его вовсе надо указывать. Но можно увидеть подтверждение, например, вот тут: https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc
Wesha
17.12.2021 11:04Совершенно верно. Когда компьютер были однозадачными, а данные ходили по Интернету незашифрованными, память никто не чистил. Были, в частности, функции
malloc(memory allocate, "дайте мне памяти, какая бы ни была") иcalloc(clear and allocate, "дайте мне памяти, заполненной нулями"), и вот в первом случае Вы и получали блок, заполненный тем, что в него клала предыдущая пользовавшаяся им программа. Это было время непуганыхидиотовюзеров. А потом — червь Морриса, эксплоиты с переполнением стека, и всё заверте...Lure_of_Chaos
17.12.2021 18:54Рискуя быть заминусованным, выскажу предположение, что с развитием абстракций (языков без прямого доступа к памяти, в т.ч. интерпретируемых, скриптовых), данное действие становится всё сложнее до невозможности.
Т.е., утрируя, если хочешь написать червь - пиши его на ассемблере! Что очень сокращает число специалистов (а вместе с ним и риск), чтобы заботиться об этом в каждой софтине.
И это уж не говоря о требуемом изначальном уровне доступа. Я вспоминаю истерию по поводу Meltdown\Spectre, а реально много ли было бед из-за них? Возможно, я мало читаю, но не слышал.
Отчего делаю вывод: пусть лучше мой софт будет уязвим для хакеров выше скрипткидди, но я сделаю его лучше (например, быстрее), чем я параноидально обмажусь всеми проверками, которые мне, возможно, ещё и свинью подложат.
Semy
19.12.2021 00:42данное действие становится всё сложнее до невозможности.
Есть люди, которым это под силу. А значит, опастность существует и игнорироваться не должна.
По поводу Meltdown\Spectre, часто очень сложно определить каким способом утекла некая информация (например, приватный ключ), если она не передавалась в открытом виде. Поэтому, тут тоже достаточно самой возможности, что бы начинать беспокоиться. Тем более, что рабочие экплоиты были продемонстрированы - это не какая то мифическая возможность.
IkaR49
17.12.2021 10:27+2Абсолютно любой замок можно вскрыть или сломать. А раз так, то зачем они вообще нужны? Вы готовы никогда не закрывать дверь своей квартиры?
Lure_of_Chaos
17.12.2021 18:58+1Кстати, практика подсказывает, что да, можно. Однако, никогда не знаешь, будет ли одномиллиардный шанс именно твой, когда кто-то зайдет в твой подъезд, зайдёт на твой этаж, дёрнет твою ручку и твоя квартира откроется, являя вкусную плазму, топовый ноут и $1000 прямо на тумбочке для жены, а то ещё и саму жену на "закуску"
Так что всё же лучше закрывать. Хоть на 1 замок, не на 10, но чтоб войти было сложнее, чем просто нажать на ручку...
IkaR49
17.12.2021 19:45Как подсказывает практика, то зайдет к вам не случайный человек с улицы, а сосед-алкоголик.
А количество замков уже зависит от того, что вы прячете за дверью, и как много человек об этом знает.
Wesha
17.12.2021 21:03Так что всё же лучше закрывать. Хоть на 1 замок, не на 10, но чтоб войти было сложнее, чем просто нажать на ручку...
"Мне не надо бежать быстрее медведя, мне надо бежать быстрее тебя" (c)
MinimumLaw
17.12.2021 10:50-9@Andrey2008, при всем уважении к Вам и вашей компании, все же считаю необходимым напомнить тезис о том, что Хабр - не жалобная книга. Тем более, в ситуации с открытым ПО. Со стороны выглядит просто великолепно. Это вы 9 лет знаете о существовании ошибки, знаете пути их исправления, и... Кроме как жаловаться ничего не делаете.
А по сути, @Lure_of_Chaos чуть выше вполне разумно высказался. Мне особо добавить нечего. Разве что посокрушаться. Давно собираюсь написать статью об эволиционном развитии программного кода и о том, что эволючионно почти всегда выживает тот, кто обеспечивает массовость, пусть и ценой короткой жизни. Отличное было выступление Михаила Никитина на "УПМ-7". Так и подбивает повторить, но применительно к коду. Даже ченовик давно лежит. Только вот меня постоянно упрекают в том, что демагог. И мои аналогии ничего не доказывают. Потому и двигается данная статья очень и очень медленно.
По сути мы на одной стороне. Что PVS-Studio, что Rust, что MISRA и прочие стандарты... Все они про надежность и безопасность. Но увы. О безопасности и надежности вспоминают ровно в тот момент, когда под угрозой оказывается массовость воспроизводства и скорость вывода итогового на рынок. Или (опять же строго эволюционно) или в очень нишевых областях. Тех областях, которые не интрересны массовому рынку по причине очень малого питания. Мне повезло (???) работать в одной из таких областей. Но я прекрастно понимаю почему в других местах совершенно противоположный подход к качеству кода. Не важно открытого или закрытого.
Подводя итог скажу лишь одно. Вы делаете очень важную работу публикуя типичные ошибки. Отдельно спасибо за оформленные баг-репорты к открытым проектам. Но точно не стоит писать статьи типа этой. Тут полный спектр всякого. От личной обиды (мы нашли и сказали, а нас игнорят) до ошибки выжившего (вы же проверяете и закрытый код и в курсе того, как там дела обстоят). А жизнь... Жизнь она всегда несправедлива...
Andrey2008 Автор
17.12.2021 11:22+6Эээ... это какое-то Ваше восприятие статьи :). Это не жалоба. Это фиксация примера, что открытость проекта сама по себе почти ничего не значит и борьба с вредным мифом. Личная обида? Вообще мимо. Я ржал, когда я понял, что за уведомление я получил :). Но раз испытал лёгкий шок, решил его зафиксировать в виде заметки.
MinimumLaw
17.12.2021 12:04+2Что делать. Не все одинаково прочитанное воспринимают.
На самом деле ваш цикл статей очень хорош. Сколько потенциальных ошибок copy-paste было не допущено ровно потому что вы всегда с них начинаете! Я даже посчитать не возьмусь. А ведь именно разработчику их просто не видно. Мозг сам себя обманывает выдавая желаемое за действительное. И инструмент безусловно хорош.
Что до мифа.... Ну не знаю. Каждый серьезный RCE в ядре Linux ставит под угрозу Android. Хотя, казалось бы Google, разработчики на зарплате в хорошем количестве и с хорошей зарплатой. Да не один год по времени уже. Можно было или вычистить или переписать. Я бы не взялся ни опровергать этот миф, ни вступаться за него. Открытый код уже неоднократно доказал свое право на существование. Как и закрытый. Не мне судить кто из них более качественный. Мое дело свой код качественно писать. И даже шире - свои изделия качественно проектировать. Ибо код - это только винтик в огромном механизме изделия, а чаще даже комплекса изделий.
Потому ничего личного. С нетерпением жду следующую статью.
sshikov
Проверьте log4j 2.*
aleks_pingvin
Лучше openJDK
sshikov
Да, можно обоих, чего уж там. Но я исхожу из того, что продукт, в котором уже обнаружили дырищу, скорее всего содержит их еще. Это такое эмпирическое правило, если угодно.
fougasse
Если написанная программа сработала "правильно", то это значит, что во время ее работы выполнилось четное число ошибок.
LynXzp
Выполнилось количество ошибок не равное одной. Три ошибки могли последовательно себя скрыть.
amarkevich
Баг связан с фичей версии 2.х, в 1.х такого нету. Если бы в процессе прикручивания очередной свистелки подумали бы о нестандартном использовании - то проблема была бы только у пользователей, явно включивших эту фишку.
sshikov
Ну в общем да. Просто тут фича — ну такой полноценный язык выражений. Просто подумать, что не стоит разрешать любые выражения — было достаточно очевидным. И если в конфиге эта фича норм — то в тексте, который мы не контролируем, не норм совсем. Кстати, когда я перечитывал на днях документацию, у меня долгое время было впечатление, что это можно писать только в конфиге — то есть, документация не очень четко описывает, что можно и в тексте сообщения это сделать. И я до сих пор так и не нашел явного указания на вот это вот все нигде, кроме исходников.
Shaz
Самой популярной версии 1.8ххх?