В Git LFS выявлена критическая уязвимость (CVE-2020-27955), позволяющая удалённому злоумышленнику выполнить свой код в системе жертвы, при клонировании жертвой специально оформленного репозитория. Проблема проявляется только на платформе Windows и устранена в предложенном несколько часов назад обновлении git-lfs 2.12.1. На Unix системах уязвимость не проявляется...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54029
Эх. Ничему Microsoft история не учит. Потому что в Виндах в принципе ущербно сделан поиск библиотек и исполняемых файлов.Помнится, ещё давно в Office была уязвимость, когда открываешь лежащие на Samba-шаре доки, Office подтягивал все лежащие DLL'ки (при наличие на шаре) в первую очередь с шары, и уже потом смотрел в системные папки. Так можно было спокойно захватить контроль над любой машиной в сети.
Или ещё один хак. В винде (на 7 точно делал) меняешь c:\windows\system32\sethc.exe на cmd.exe, жмёшь на стартовом экране входа несколько раз подряд клавишу Shift и наслаждаешься эксплуатацией командного интерпретатора с суперадминскими правами ;)
И че с правами юзера работает? Или то что ты такой крутой под админом на юнихах не работает?
> И че с правами юзера работает?Если знаешь волшебные команды винды, то конечно. Или о чём вопрос?
> Или то что ты такой крутой под админом на юнихах не работает?
Речь разве про них? В юнихах и своих дыр хватает. Не надо идеализировать.
> c:\windows\system32\sethc.exe на cmd.exeВот это возможно сделать от юзера? Или опять админ сам себя ломает?
Невозможно. Это один из способов сделать себе админа при наличии физического доступа к компьютеру (и файловой системе), например, если пароль забыт
Это можно сделать хоть с хацкерской флешки, лишь бы был физический доступ к диску с виндой и умение инструмента работать с NTFS. cmd.exe лежит в той же папочке, если что.
Флешка с Linux Live и ntfs-3g пойдёт?
подойдёт. так и работали.
А в чём прикол? Если запустил линукс с флешки хоть винт форматнуть можно, в чём новость?
> Или о чём вопрос?А, понял. Вы, вероятно, про саму подмену. Пишите более чётко. Нет, конечно, нужно хакать извне, то бишь грузиться не с целевой винды.
Это не уязвимость.
А я говорил про уязвимость? Просто пример наглой эксплуатации механизма работы исполняемых файлов в шиндоуз.
Лол, так и вход в систему без пароля (если юзер его не установил) тоже можно "наглым" назвать.А для защиты от твоего сценария ещё в 7-ке существовали:
- блокировка сеанса
- шифрование системного раздела (чтобы ты не проделал тот же трюк, сняв накопитель)
Лол походу ты. Какая нафиг блокировка сеанса, почитай внимательнее то, о чём я писал здесь.
И насчёт шифрования. Я так понимаю, речь о BitLocker. При установке оси об этом речи не было, если делать, то только опосля, и я очень сомневаюсь, что 95% хомячков ей заморачивались со всякими TPM и USB-ключами.
Напоминает троллейбус из буханки хлеба.
Но вообще это забавно и подчёркивает то, что даже Microsoft не умеет писать софт под свою же ОС. Что говорить о других несчастных, которым приходится программировать под это чудо с кучей интересных технических решений.
Категорически согласен. Как-то в молодости надо было сделать DLL. Взял толстую книжку по данной теме, немного посмотрел, выбросил её и написал свою.
Тебе не нравится? Ты бы был счастлив, если бы СВОЮ не сумел написать? Да что ж с вами, красно..., творится?
Мания величия, самоощущение _элитарности_ - вот что творится. Причем это не имеет отношения к собственно реальным аспектам программирования под ту или иную ОС. Просто одна группа убеждает себя в том, что использование Linux это _престижное потребление_, тогда как использование Windows таковым не является. Примерно как некоторые носители футболок с логотипом Гуччи считают себя лучше носителей футболок без такого, даже если, внезапно, и те, и другие футболки сделаны из хлопка одинакового качества, выкроены одинаково ровно и сшиты одинаково прочно (что не редкость).
Если привыкли делать это как в юниксах, то компилятор сам заменит .so на .dll
Так тебе и требовалось написать свою не ?Или ты свою книгу по длл написал ?)
Ты не поверишь, но там работают такие же люди как и везде у них нет никаких дополнительных сверхспособностей.
С той разницей, что майки могут позволить себе очень дорогой контроль качества, а Вася Пупкин - не может. Поэтому, когда софт пишет Microsoft под свою же ОСь, то качество должно быть на порядок выше того, что накалякал бы Васян.
> очень дорогой контроль качестваВ смысле из-под самого Бангалора, а не с той дальней деревни? :D
PS: что-то не слышал, чтоб в Эстонии некрософт мясоботов набирал...
В том то и дело, позволить могут, а нанимают бомжей.
Так вам и говорят что они должны нанимать архангелов для провеоки а не бомжей.
Ну почему бомжей, Go написала для них конторка денежная, хоть и забесплатно. ;) Перепишут теперь на C#, вот будет радости.
> Эх. Ничему Microsoft история не учит. Потому что в Виндах в принципе
> ущербно сделан поиск библиотек и исполняемых файлов.Поискал за Вас:
https://github.com/git-lfs/git-lfs/blob/74d5f2397f9abe4834bf...
https://github.com/git-lfs/git-lfs/blob/74d5f2397f9abe4834bf...
Может чему научитесь.
Кое-чему они все-таки научены: проекты, которые в самом ближайшем будущем не планируется "открывать", они в принципе не хранят на гитхабе ввиду его дырявости
а в линуксе, где путь /usr/lib хардкодится в экзишники и библиотеки при компиляции - нормально?
Не читаю астрологических прогнозов, но, видимо, был объявлен %промежуток времени% дыр в экосистеме GitHub.
Время пиара, которое мы запомним ни как повальную блокировку и удаление неугодных репозиториев - а страдание нивинного мелкософта атакуемого злобными дырами.
Ну а что, тема хайповая, всегда найдётся толпа любителей позлорадствовать.
а чего бы не позлорадствовать :-) .вся коллекция архитктурный проблем Windows на мой взгляд возникла из-за следущего принятого подхода:
1. все проблемы рашаются наиболее первым пришедшим простым способом, просто вставляем подпорку. ни каких огромных перепродумываний и переделываний.
2. соблюдаем обратную совместимость над тем что уже было сделано, не важно насколько оно выглядет убогим. копим это и приумножаем.
3. главная в софте -- это красивое GUI, оттестированное QA во множестве сценариев щёлканья мышкой во все места. то что под капотом -- дело вторичное.
------------------------------------------------------------
такой подход приводит как раз к тому что платформа сначала становится НЕдружилёбной к обычному разработчику, который не понимает почему он стокнлуся с куском нелогичной хрени.
затем платформа становится НЕдружелюбной уже и к собственным разработчикам. которые вроде как более квалифицированны и не пугаются простых сложностей.
а теперь вопрос -- а почему на этим бы и не глумиться? :-) ну сами виноваты -- сами получите порцию надсмеханий :-)
Это было бы злорадство, если бы это реально была ошибка в программе, а не ущербным дизайном ОС. Загружать по умолчанию бинарники и библиотеки из CWD - это верх маразма. Если CWD не находится в PATH, конечно. Это не норм, и это не то, что должен проверять рядовой разработчик. А для осознанной подмены exe/dll, когда человек знает, что он делает - должны быть отдельные механизмы, вроде того же LD_PRELOAD в Линуксах.И отдельного внимания стоит то, что такие ошибки регулярно допускают сотрудники Microsoft. Сначала с Office, теперь с Git LFS. И это даже не из-за некомпетентности сотрудников, а из-за broken-by-design механизма поиска библиотек и бинарников в ОС, т.к. у нормального человека не уложится в голове, что ОС пойдёт в CWD искать бинарник (который не зовётся явным образом из CWD).
И сколько у вас уже было _local_root_ а не "запуск не того гит от обычного юзера" из-за дыр в этом прекрасном "отдельном механизме", напомнить?> И отдельного внимания стоит то, что такие ошибки регулярно допускают сотрудники Microsoft.
обычный индус, кое-как освоивший игогошечку и прошедший собеседование. То что у него в визитке значится microsoft - ни разу не делает его специалистом по windows. Он ее в своей Калькутте и не видел может.
Это именно из-за некомпетентности сотрудников. Ну надо же, кто бы мог подумать - тут вам не линюпс, у нормального человека с образованием "рядом с гуру на улице видел экран через три чужих плеча" 'в голове не укладывается' что это другая система. Зато они дешевые!
Вы конечно правы, но нужно было это всё делать лет 50 назад.Сейчас арихитектура такая, что каждая прога может таскать с собой свои dll, и вспомогательные утилиты. Поэтому часто лучше загружать dll из той же папки где и прога.
Аналогично с запуском.Когда то была рекомендация кидать все dll в /system, но это привело к dll hell: когда разные проги были скомпилены с разными версиями одной dll, и каждая их кидала в /system, в итоге работала или одна прога или другая.
Это пофиксили как раз тем что dll порекомендовали кидать в папку с прогой, а потом ещё какой то мапинг/манифесты добавили, но тут я уже соскочил с венды и не вникал.Если кратко то сейчас с этим уже сделать ничего нельзя - софт просто перестанет работать.
> Сейчас арихитектура такая, что каждая прога может таскать с собой свои dll, и вспомогательные утилитывот только "с собой" это по смыслу НЕ должно быть синонимом "current work directory".
можно было бы придумать чтобы исполняемый файл линковал бы библиотеки по абсолютному пути. или по относительному пути относительно расположению самого себя. или ещё что-то.. но использование CWD это как нассать зимой себе в штаны -- сначало тепло и хорошо, но потом оно застыват на морозе
>> Сейчас арихитектура такая, что каждая прога может таскать с собой свои dll, и вспомогательные утилиты
> вот только "с собой" это по смыслу НЕ должно быть синонимом "current
> work directory".Понимаю, удобный случай позлорадствовать, но где вы все (и Вы в частности) увидели "current work directory"?
func LookPath(file string) (string, error)
LookPath searches for an executable named file in the directories named by the PATH environment variable. If file contains a slash, it is tried directly and the PATH is not consulted. The result may be an absolute path or a path relative to the current directory.
https://golang.org/pkg/os/exec/#LookPathИ при чём тут Микрософт?
Ну а че, злорадствовать, так злорадствовать? ;)
Microsoft купила GitHub, а вместе с ним ему досталась и поделка Git LFS. Так что эти уязвимости - теперь Микрософтовские. И (ни много, ни мало) Windows-эксклюзив.
Для тех учителей, кто даже после цитат и прямых намёков не понял -- "уязвимость" в библиотеке Go.
Текущий каталог в PATH в винде по умолчанию, но виновата библиотека? Неожиданный ход.
> Текущий каталог в PATH в винде по умолчаниюВ MSDN поведение документировано? Документировано. Разработчики под ту систему документацию читают и проблем с её кривым дизайном не имеют.
> но виновата библиотека?
"отличная кроссплатформенная совместимость." https://golangs.org/go-beginning
В документации к библиотеке поведение не документировано. Поведение различается меж платформами. Разработчики честно прочли документацию и свою часть контракта выполнили, на своём Макбуке проверили и пошли спать спокойно.
> Неожиданный
> ход.Да вполне ожидаемо, что мало кто посмотреть патчи удосужился, не говоря о подумать. Вот и спрашивают банальщину.
А что Майки блочат все неугодное направо и налево хотя с dmca хоть без. Как раз удобное время накинуть на Майков.
> МайкиЭто тебе твой господин запретил называть мелкософт неприятными для него словами ?
Windows всегда была дыркой, совсем не удивительно, что уязвимости продолжают находить.
То ли дело кocтылинупc, в котором ту же Dirty Cow видели почти 10 лет, но принципиально не закрывали.
Не видели - а держали в секрете. Копрорации кстати это делали.
>Git LFSЧего только народ не придумывает, лишь бы не юзать нормальные системы контроля версий.
Это какие?
Ради научного интереса, что вы считаете нормальной системой контроля?
Новая папка(244) конечно же!
SVN, Hg к примеру
>SVNВ 2020-м использовать нераспределённые системы контроля версий такое себе.
А чего вы хотели? Распределённость и частичный чекаут больших файлов взаимно противоречивые понятия. А эти ЛФСы и т.д. это жуткие костыли, которые кстати и являются классическим централизованным репозиторием.
> SVN, Hg к примеруSVN — не смешно.
Hg — ну да, конечно, там не нужен LFS. Там ведь есть свой костыль, который делает в точности то же самое: https://www.mercurial-scm.org/wiki/LargefilesExtension
Потому что, ой, у нас проблемки с большими файлами: https://www.mercurial-scm.org/wiki/HandlingLargeFiles
>для запуска нового процесса git используется вызов ExecCommand(), но не указывается полный путь к исполняемому файлу gitА не надо запускать процессы. Нужно импортировать dllки. Если разрабы Git против редизайна гита с прицелом на незапуск процессов - то нафиг разрабов Git, у GitHub inc. хватит финансирования MS, чтобы либо форкнуть небезопасный git, либо воссоздать с нуля на растишке, и потушить оригинал.
> либо воссоздать с нуля на растишке, и потушить оригинал.не так.
правильная фраза такая -- " либо воссоздать с нуля на растишке, и переорать оригинал."
А теперь объясни, с какой радости разрабы git должны переделывать всё так, как принято в винде, вместо того, чтобы продолжать использовать архитектуру, работавшую с рождения Unix? А как быть на платформах, где не поддерживаются разделяемые библиотеки, ты подумал? Ну и самое главное: в винде и exe, и dll ищутся одинаковым образом, так что в плане безопасности вообще никакой разницы нет.
>чтобы продолжать использовать архитектуру, работавшую с рождения UnixMesa у тебя тоже в отдельном процессе?
>А как быть на платформах, где не поддерживаются разделяемые библиотеки
На доработку такие платформы.
>Ну и самое главное: в винде и exe, и dll ищутся одинаковым образом, так что в плане безопасности вообще никакой разницы нет.
Дллки линкуются на этапе загрузки через таблицу импорта, о безопасности заботится линкер, и он не будет грузить из папки, где файл лежит, в первую очередь, у него другие папки в приоритете. Ручная загрузка через LoadLibrary - это редкий случай, применяется, например, для плагинов. К soшкам всё вышесказанное тоже применимо.
А смысл в том, что любой интерфейс, допускающий инъекцию, фундаментально небезопасен. И командная строка - как раз такой интерфейс. Даже если эту багу пофиксили, рядом ещё 100500 могут ждать своего часа. Использование же общих библиотек - лучший по всем параметрам подход.
Они там не запускают процессы, а вызывают стандартную функцию Go https://golang.org/pkg/os/exec/#Command
Внезапно, функция из "кроссплатформенной библиотеки" работает не везде одинаково. Но виноваты разработчики git-lfs и Микрософт, а Гугл умнички.
Вот что за бараны Вас минусуют
Кто-то по старой памяти, кому-то возразить нечего, а для кого-то я непонятно пишу.
Те, которые понимают, что делает эта стандартная библиотечная функция, и знают, что стандартные библиотечные функции для других языков работают точно так же.
> Те, которые понимают, что делает эта стандартная библиотечная функцияА "эта" функция, на которую я выше привел ссылку, ничего криминального и не делает. Но Вы же понимаете, и потому скажете, в какой конкретно дело?
Кстати, тут Вы угадали, уникальный случай. Аргументация "ваша любимая Microsoft" https://www.opennet.dev/openforum/vsluhforumID3/122328.html#76
это как раз уровень барана. То есть он банально не умеет даже по ссылкам на профиль кликать, или заметить, что я "МИКРОсофт" тут пишу. Нафантазировал красную тряпку перед носом и вперёд, гонимый ненавистью к вымышленному врагу.)
А ничего, что CWD в PATH по умолчанию в Винде, а виновата, внезапно, конечно же стандартная функция из "кроссплатформенной библиотеки" Go? Которая следует стандартам и соглашениям, принятым в данной ОС. И уж точно не создатели Git LFS и не ваша любимая Microsoft.Вы ещё скажите, что в былых эпидемиях флешечных autorun-вирусов во времена Windows XP были виноваты производители флешек. Ишь ты, съёмные диски повадились производить. А Autorun любой малвари по умолчанию со всех флешек - это грамотная, продуманная архитектура.
Такая поделка (Винда) нафиг не нужна, которая пихает CWD в PATH. Не зря экосистема Windows кишит малварью, потому что архитектура ОС представляет все мыслимые и немыслимые средства для распространения вредоносного кода.
> А ничего, что CWD в PATH по умолчанию в Винде, а виновата,
> внезапно, конечно же стандартная функция из "кроссплатформенной библиотеки" Go? Которая
> следует стандартам и соглашениям, принятым в данной ОС. И уж точно
> не создатели Git LFS и не ваша любимая Microsoft.Где она следует и как Вы про это узнали? Сами придумали? Или дадите цитату из документации библиотеки, что там "CWD в PATH по умолчанию в Винде"?
> Вы ещё скажите, что в былых эпидемиях флешечных autorun-вирусов во времена Windows
> XP были виноваты производители флешек. Ишь ты, съёмные диски повадились производить.Вы уже это сказали, приписали мне и начали с вымышленным мной спорить. Успехов в этом не лёгком деле. ;)
>Вы ещё скажите, что в былых эпидемиях флешечных autorun-вирусов во времена Windows XP были виноваты производители флешекВ том числе. На чипе контроллера во флешках есть специальная нога для защиты от записи. Производителям следовало бы эту ногу вывести на переключатель, а не предлагать пользователю это сделать самому кустарно. Но нет, будем экономить 1 цент.
> Mesa у тебя тоже в отдельном процессе?И причём здесь mesa?
> На доработку такие платформы.
О том, что доработка может быть нецелесообразна по объективным причинам, не задумывался? Да и вообще, это забота разработчиков прикладного софта обеспечить совместимость с определённой платформой, а не наоборот.
> любой интерфейс, допускающий инъекцию, фундаментально небезопасен
В винде любой интерфейс допускает инъекцию, так что нечего стрелки переводить.
> Использование же общих библиотек - лучший по всем параметрам подход.
Нет. Особенно в случае винды, где нет нормального пакетного менеджера, который обеспечил бы установку библиотеки совместимой версии.
> Да и вообще, это забота разработчиков прикладного софта обеспечить совместимость с
> определённой платформой, а не наоборот.Вот разработчики и написали за Гугль правильную LookPath(), когда узнали, что документация врёт.
Где же она врёт-то? Как написано, так и работает.
> Где же она врёт-то? Как написано, так и работает.Дайте цитату документации Go где написано, что будет запуск из текущего каталога. Вы же не врёте?
Т.е. по вашему, функция, которая ищет бинарники в PATH, внезапно, не должна искать бинарники в PATH? В Винде CWD входит в PATH, и более того, стоит на первом месте в PATH, как наиболее приоритетный источник загрузки бинарников, так что функция работает корректно, по документации, а главное, соблюдает принятые в Винде стандарты и соглашения, даже если они маразматичные.
> Т.е. по вашему, функция, которая ищет бинарники в PATH, внезапно, не должна
> искать бинарники в PATH? В Винде CWD входит в PATHВ Винде входит, о чём в документации Винды прямо написано. В Go в некоторых случаях входит, в остальных не входит, о чём в документации не написано. Поэтому пользователь "кроссплатформенной" библиотеки должен читать MSDN, а виновата Микрософт.
>О том, что доработка может быть нецелесообразна по объективным причинам, не задумывался?Значит это мёртвые ненужные платформы.
>Да и вообще, это забота разработчиков прикладного софта обеспечить совместимость с определённой платформой, а не наоборот.
Это забота разработчика платформы - реализовать mmap.
>Нет. Особенно в случае винды, где нет нормального пакетного менеджера, который обеспечил бы установку библиотеки совместимой версии.
Есть. Conda называется. И менеджер, и репозиторий. Сам менеджер, если честно, отвратительный - разрабы додумались туда вкорячить SMT-solver для разрешения зависимостей, типа это наиболее правильный путь, ибо задача из класса NP-полных. То что это говно теперь не работает (вернее, посчитав час, выводит вердикт, unsat, и **ись с таким вердиктом теперь сам как хочешь, проще снести всё нахрен и поставить заново), их, видимо, мало беспокоит. Зато репозиторий отличный, многое что есть в линуксовых дистрах, там есть.
Примечательно, что в описании функции Win32 API CreateProcessW() о подобном риске сказано https://docs.microsoft.com/en-us/windows/win32/api/processth...Но разработчики документацию не читали, вместо этого использовали "безопасный язык":
subprocess/subprocess_windows.go
@@ -10,6 +10,7 @@ import (
// ExecCommand is a small platform specific wrapper around os/exec.Command
func ExecCommand(name string, arg ...string) *Cmd {
cmd := exec.Command(name, arg...)
+ cmd.Path, _ = LookPath(name)
cmd.SysProcAttr = &syscall.SysProcAttr{HideWindow: true}
cmd.Env = env
return newCmd(cmd)
В описании говорится о другом риске. О риске запуска другого exe если путь содержит пробел.
> В описании говорится о другом риске.Простите, но я даже и не думал, что кому-то здесь придётся объяснять смысл слова "подобный".
> О риске запуска другого exe если
> путь содержит пробел.Потому что такое поведение не для всех очевидно. То что обсуждается в новости, для любого тамошнего разработчика очевидно, так же как для тутошних очевиден смысл ./. Если бы накосячившие работали с API системы, это был бы их косяк. Но они поверили в кроссплатформенность и взяли "безопасную" прослойку, которая данный случай не предусмотрела.
Надо Винде поторопиться с переходом на использование fork(). ;)
вот ток проблема втом что их "лёгкий" CreateThread() работает даже дольше тем "тяжёлый" fork() в linux.
Майкрософт прокляли!
Ещё 1 причина, чтоб не переходить на Wind'у.
Вряд ли это причина.
Тоесть все массово переходим таки?
> Тоесть все массово переходим таки?Да, и побыстрее. Чтоб Linux окончательно скатился к "Хроникам Нарнии" :)
Так баг починили. Так что можно лететь сломя голову.
Естественно на windows, где же ещё как ни на кривой системе с убогой архитектурой.
> Проблема проявляется только на платформе WindowsПоэтому на лоре этой новости не будет