LINUX.ORG.RU

Исследователям удалось добавить в ядро Linux уязвимый код

 ,


4

1

Исследователи из университета Миннесоты — Цюши У и Канцзе Лу в рамках исследования «небезопасности» OSS модели пытались выяснить, насколько вероятно намеренное добавление уязвимостей в проекты. Среди прочего патчи были отправлены в ядро Linux.

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

>>> Ссылка на исследование

anonymous

Проверено: xaizek ()
Последнее исправление: xaizek (всего исправлений: 2)

Это какой-то позор. А если серьёзно, то это наглядная демонстрация того факта, что OSS не более безопасный, чем проприетарный код.

hummer
()
Ответ на: комментарий от hummer

это наглядная демонстрация того факта, что OSS не более безопасный, чем проприетарный код

Этого какого рода органом ты породил подобную мысль? Потому что мозг тут определённо не участвовал - иначе была бы хоть какая-то логика.

zabbal ★★★★★
()
Ответ на: комментарий от hummer

А если серьёзно, то это наглядная демонстрация того факта, что OSS не более безопасный, чем проприетарный код.

Нет, более безопасный и причин тут две:

  1. за каждый патч отвечает конкретная персона: автор патча или тот кто его подтвердил, ответственность у проприетарщиков размазана на всё юрлицо.
  2. Множество внедрённых бекдоров на конкретной системе могут оказываться вне игры после отключения входе перекомпиляции ядрва неиспользуемых модулей и функционала, чего нельзя сделать с проприетарным блобом.
torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от hummer

А если серьёзно, то это наглядная демонстрация того факта, что OSS не более безопасный, чем проприетарный код.

Только у даунов это наглядная демонстрация.

anonymous
()
Ответ на: комментарий от torvn77

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

Никак не отвечает и никакой ответственности не несёт.

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

Речь идёт не о хипстерах, сидящих на source based и красноглазящих в компиляцию и в её параметры. К этому надо добавить ещё и то, что какой нибудь RHEL или Oracle накладывает кучу своих патчей.

hummer
()
Ответ на: комментарий от anonymous

Только дауны хамят из под анонимуса. Выпей яду.

hummer
()
Ответ на: комментарий от Shaman007

Коммитер может быть и не с улицы, но автор (в git - это два разных поля) может быть кто угодно. Аудит присылаемых патчей явно страдает и именно это продемонстрировал эксперимент. Теперь представь, что какая-то спецслужба хочет иметь бекдор. Для этого им нужно прислать достаточно полезный патч или серию патчей, в которых этот бекдор находится в достаточно завуалированном виде. И хорошо, если это обнаружат лет через 10, а ведь могут и вообще не обнаружить.

hummer
()
Ответ на: комментарий от hummer

Никак не отвечает и никакой ответственности не несёт.

Как не несёт если институт вот только что ответил?

torvn77 ★★★★★
()
Ответ на: комментарий от hummer

Речь идёт не о хипстерах, сидящих на source based и красноглазящих в компиляцию и в её параметры.

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

torvn77 ★★★★★
()
Ответ на: комментарий от anonymous

Да не 15, по-моему с самого начала создания линукса об этом говорили.

И вот вам пожалуйста, отродясь такого не бывало и опять то же самое. Теперь и с пруфами банного вкуса.

beck ★★★★
()
Ответ на: комментарий от beck

Вот именно. Внезапно оказалось, что эта ваша хваленая открытость снижает безопасность.

В закрытом проекте уязвимость будет добавлена по решению тайного суда (их же ещё не отменили?), но об этом никто никогда не узнает.

anonymous
()
Ответ на: комментарий от anonymous

по решению тайного суда

с распитием крови христианских младенцев!

anonymous
()
Ответ на: комментарий от anonymous

но об этом никто никогда не узнает.

Как же блин тогда дыры в венде находят? Гаданием на кофейной гуще? Магией? Про процессоры я вообще молчу.

hateyoufeel ★★★★★
()
Ответ на: комментарий от anonymous

В закрытом проекте уязвимость будет добавлена по решению тайного суда (их же ещё не отменили?), но об этом никто никогда не узнает.

Да ладно. Вона, например корпорация зла MS легко даёт исходники на аудит, только NDA подпиши.

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

Проблема, как выяснилось, что любой васян не находит дыры в открытом коде, наоборот, он их туда вносит. И это не проверяется, не контролируется, не ловится.

Видимо, нужно что-то менять в процессе разработки?

beck ★★★★
()
Ответ на: комментарий от beck

Хороший коммент. На него дальше можно давать ссылку.

anonymous
()
Ответ на: комментарий от hateyoufeel

Про процессоры я вообще молчу. Запланированный слив.

anonymous
()
Ответ на: комментарий от hateyoufeel

Как же блин тогда дыры в венде находят? Гаданием на кофейной гуще? Магией? Про процессоры я вообще молчу.

Чтобы найти уязвимость в C коде ядра уже должна быть какая-то определённая квалификация. Без кода она должна быть ещё выше. А в процессорах и вовсе единицы могут.

anonymous
()
Ответ на: комментарий от anonymous

Чтобы найти уязвимость в C коде ядра уже должна быть какая-то определённая квалификация. Без кода она должна быть ещё выше.

Если бы это было так, дыр в венде находили бы гораздо меньше. Но нет, за один только 2021, который только недавно начался, их уже довольно дохрена.

hateyoufeel ★★★★★
()
Ответ на: комментарий от beck

В чём принципиальная разница всё равно не понятно. В гугле 44 тысячи сотрудников. В Майкрософте тоже десятки тысяч. Недавно в Daily Telegraph была статья, рассказывающая о том, что в менеджменте всех топовых компаний по неск. членов компартии Китая сидит. Спекулировали на тему того, что те получают коммерч. тайну и приватную информацию. Что мешает условной компартии/ISIS’у/гэбне иметь своих людей среди сотрудников любых тех. компаний? Они совершенно точно уже есть. Тут то вопрос конкретно в недостаточности код ревью процесса вообще вне зависимости от лицензии. Так то можно и opensource пилить, принимая коммиты только от знакомых. Проблему это всё равно не решает.

anonymous
()
Ответ на: комментарий от anonymous
Что мешает условной компартии/ISIS’у/гэбне иметь своих людей среди сотрудников любых тех. компаний```
в этом и есть прелесть компаний с международными сотрудниками. Как бы ты не старался всем угодить найдется тот кто тебя ненавидит
anonymous
()
Ответ на: комментарий от torvn77

Как не несёт если институт вот только что ответил?

Университет не ответил, на него просто обиделись. Не получи этот эксперемент огласки, так бы и остались эти дырки в ядре ещё какое-то время, скорее всего несколько лет. Тут речь идёт об эксперементе, а кто-то может намеренно завуалировать дыру под случайный баг и доказать преднамеренность этого «бага» будет весьма сложно, если вообще. Никакой ответственности, всё AS IS.

hummer
()
Ответ на: комментарий от hummer
Ну пойди расскажи КрасноШляпе и прочим энтерпрайзам, что они неправильно готовят этот ваш Linux.

а ваш линукс какой?

anonymous
()
Ответ на: комментарий от anonymous

Тут то вопрос конкретно в недостаточности код ревью процесса вообще вне зависимости от лицензии.

Увы, но нет. GPL, да и вообще процесс разработки ядра и не только линукс - это любой васян может натолкать в ядро что угодно. Кто он, этот васян, откуда он, кто ему платит, всё это типа неважно и за кадром.

В каком-нибудь MS васян проверен собственной СБ, подписал NDA, есть аудиторы, которые проверяют всю деятельность васяна, от написания кода до какой рукой он подтирает задницу в сортире. Несомненно, и MS может натолкать бэкдоров, просто выдав васяну задание это сделать.

Но с линуксом ситуация печальна вдвойне. Оказалось, что код по факту не контролируется (и сколько лет уже, кстати?), оказалось, что сказки про сообщество, которое… оказались туфтой, оказалось, что в целом модель oss и открытого кода порочна в своей основе, by design так сказать.

beck ★★★★
()
Ответ на: комментарий от beck

Оказалось, что код по факту не контролируется

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

Но пустили бы вот так в ядро патчи от не имеющего репутации и известности человека?
Думаю что нет.

torvn77 ★★★★★
()
Ответ на: комментарий от hateyoufeel

Как же блин тогда дыры в венде находят?

MS без проблем даёт свои исходники, и код аудитирует много кто. Один мой знакомый работал в Oracle, ну так у них были исходники винды.

beck ★★★★
()
Ответ на: комментарий от beck

С воспроизводимой сборкой компилятором, к которому есть исходники (тоже с воспроизводимой сборкой)? Иначе - те бинарники, что выполняются, и те аудитируемые исходники - не одно и то же.

gag ★★★★★
()
Ответ на: комментарий от beck

есть аудиторы, которые проверяют всю деятельность васяна

ЛОЛ. «Аудиторы» 25 корпораций просмотрели уязвимость, спрятанную в нескольких коммитах Васяна. А в МС, конечно, всё будет по другому. 20-рукий и 10-глазый Бхаратия проблему порешает. Нельзя сделать так, чтобы в сотнях тысяч строк низкоуровневого кода не было ошибок, намеренных ли или случайных.

anonymous
()
Ответ на: комментарий от torvn77

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

beck ★★★★
()
Ответ на: комментарий от anonymous

в МС, конечно, всё будет по другому

Да, и я даже объяснил, почему. Но вы не читаете, коллега.

beck ★★★★
()
Ответ на: комментарий от beck

Это всё да, но дыры очень часто находят и без исходников.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hummer

Никакой ответственности, всё AS IS.

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

GPLv2:

  1. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW
  2. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR
gag ★★★★★
()
Ответ на: комментарий от hummer

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

gag ★★★★★
()
Ответ на: комментарий от hummer

Это какой-то позор. А если серьёзно, то это наглядная демонстрация того факта, что OSS не более безопасный, чем проприетарный код.

Я как-то говорил, что открытй код не даёт ничего. Плюс нужно проверять каждую сборку(собрать можно что-то другое или добавить в процессе сборки) каждого дистряба отдельно на ошибки. Это подтверждение моих слов. Наивные детишки, такие наивные...

xwicked ★★☆
()
Ответ на: комментарий от xwicked

Я как-то говорил, что открытй код не даёт ничего.

открытый код дает все. Не только мэнтейнеры могут видеть и анализировать код, что и происходит. Кучу ошибок отлавливают рядовые линуксоиды

anonymous
()
Ответ на: комментарий от anonymous

открытый код дает все

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

anonymous
()
Ответ на: комментарий от anonymous

И что же они не отловили этот многолетний цирк с конями и дамами в обтягивающих с перьями купальниках вьедающихся меж жирных ляжек?

Ответ прост, это иллюзия.

anonymous
()
Ответ на: комментарий от anonymous

открытый код дает все. Не только мэнтейнеры могут видеть и анализировать код, что и происходит. Кучу ошибок отлавливают рядовые линуксоиды

В том-то и дело, что отлавливаются только ошибки, сделанные непреднамеренно. Грубые ошибки, лежащие на поверхности и которые могут отловить даже рядовые линуксоиды.

А внесенные намеренно уязвимости благополучно проскальзывают мимо тысяч глаз. Чтобы обнаружить такую уязвимость нужно, чтобы квалификация просматривающего была гораздо выше квалификации генерящего эти уязвимости. На деле же всё наоборот. И плюс ещё и безалаберность и расслабленность

Chord ★★★★
()
Последнее исправление: Chord (всего исправлений: 1)
Ответ на: комментарий от Chord
 Чтобы обнаружить такую уязвимость нужно, чтобы квалификация просматривающего была гораздо выше квалификации генерящего эти уязвимости.

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

И плюс ещё и безалаберность и расслабленност```

однозначно согласен. Поэтому и говорю, что все что не делается - к лучшему. Есть надежда, что после этого случая примутся радикальные меры по улучшению
anonymous
()
Ответ на: комментарий от xwicked

Солидарен. А тред показал исследования, что 80% ЛОРА даже не понимает, что произошло.

P.S. Вот вам и Астра. Вот и сколько надо работы даже забрав пакеты с, допустим, Debian.

shleemypants
()
Ответ на: комментарий от xwicked

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

hummer
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.