The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Критическая уязвимость в Git LFS, проявляющаяся на платформе Windows

05.11.2020 11:05

В Git LFS выявлена критическая уязвимость (CVE-2020-27955), позволяющая удалённому злоумышленнику выполнить свой код в системе жертвы при клонировании жертвой специально оформленного репозитория. Проблема проявляется только на платформе Windows и устранена в предложенном несколько часов назад обновлении git-lfs 2.12.1. На Unix-системах уязвимость не проявляется.

Проблема вызвана тем, что на платформе Windows для запуска нового процесса git используется вызов ExecCommand(), но не указывается полный путь к исполняемому файлу git. Если полный путь не указан, то функция ExecCommand() проверяет наличие исполняемого файла в текущем каталоге. Так как запуск осуществляется в контексте текущего репозитория, атакующий может разместить в своём репозитории файлы git.bat, git.exe или git.cmd. После клонирования репозитория подставленные злоумышленником файлы будут выполнены вместо исполняемого файла git при выполнении операций с git-lfs.

Для проверки своих систем подготовлен рабочий эксплоит. Возможность эксплуатации уязвимости протестирована в пакете Git с дополнением git-lfs, а также в Git-клиентах Git for Windows, GitHub CLI, GitHub Desktop, SourceTree, Visual Studio Code, GitKraken и SmartGit, использующих Git LFS в конфигурации по умолчанию. Проблема также потенциально затрагивает интегрированные среды разработки Eclipse, fork, tig, GitExtensions, Magit, TortoiseGit, gmaster, GitAhead, Sublime Merge, Visual Studio, GitAtomic, Tower и git-cola.

Напомним, что дополнение Git LFS (Git Large File Storage) развивается компанией GitHub и позволяет использовать Git для отслеживания версий больших файлов, содержащих наборы данных, звук, видео и графику. В штатном Git-репозитории большие файлы заменяются на текстовые ссылки, указывающие на контент в отдельном внешнем репозитории, что позволяет избежать повторного копирования файлов при клонировании и извлечении репозитория. При выполнении операций checkout большие файлы не загружаются вместе с остальными данными, а синхронизируются с сервера и хранятся в единственной копии. Код распространяется под лицензией MIT.

Дополнение: О приводящем к проблеме поведении библиотечной функции языка Go LookPath() было сообщено ещё 29 апреля с указанием, что поведение не отражено в документации. Вызывающий проблему поиск в текущем каталоге добавлен в LookPath() в 2012 году для эмуляции поведения cmd.exe. Пока идёт обсуждение, добавлять ли новую функцию LookPathStrict(), в Docker Compose CLI принято исправление, похожее на Git LFS.

  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: Уязвимость в Git, приводящая к утечке учётных данных
  3. OpenNews: Обновление Git с устранением 8 уязвимостей
  4. OpenNews: В Git устранена уязвимость, которая может привести к выполнению кода атакующего
  5. OpenNews: Уязвимость в Git, Subversion и Mercurial, допускающая подстановку команд через URL ssh://
  6. OpenNews: GitHub выпустил Git LFS 2.6.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/54029-git
Ключевые слова: git, git-lfs
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (90) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:14, 05/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Эх. Ничему Microsoft история не учит. Потому что в Виндах в принципе ущербно сделан поиск библиотек и исполняемых файлов.

    Помнится, ещё давно в Office была уязвимость, когда открываешь лежащие на Samba-шаре доки, Office подтягивал все лежащие DLL'ки (при наличие на шаре) в первую очередь с шары, и уже потом смотрел в системные папки. Так можно было спокойно захватить контроль над любой машиной в сети.

     
     
  • 2.4, m.makhno (ok), 11:21, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Или ещё один хак. В винде (на 7 точно делал) меняешь c:\windows\system32\sethc.exe на cmd.exe, жмёшь на стартовом экране входа несколько раз подряд клавишу Shift и наслаждаешься эксплуатацией командного интерпретатора с суперадминскими правами ;)
     
     
  • 3.12, Дегенератор (ok), 11:57, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    И че с правами юзера работает? Или то что ты такой крутой под админом на юнихах не работает?
     
     
  • 4.20, m.makhno (ok), 12:20, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > И че с правами юзера работает?

    Если знаешь волшебные команды винды, то конечно. Или о чём вопрос?

    > Или то что ты такой крутой под админом на юнихах не работает?

    Речь разве про них? В юнихах и своих дыр хватает. Не надо идеализировать.

     
     
  • 5.23, nebularia (ok), 12:30, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > c:\windows\system32\sethc.exe на cmd.exe

    Вот это возможно сделать от юзера? Или опять админ сам себя ломает?

     
     
  • 6.26, Карабьян (?), 12:40, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Невозможно. Это один из способов сделать себе админа при наличии физического доступа к компьютеру (и файловой системе), например, если пароль забыт
     
  • 6.29, m.makhno (ok), 12:42, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это можно сделать хоть с хацкерской флешки, лишь бы был физический доступ к диску с виндой и умение инструмента работать с NTFS. cmd.exe лежит в той же папочке, если что.
     
     
  • 7.36, Аноним (36), 13:23, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Флешка с Linux Live и ntfs-3g пойдёт?
     
     
  • 8.40, Ph0zzy (ok), 13:42, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    подойдёт так и работали ... текст свёрнут, показать
     
  • 8.48, Козлетто (?), 14:58, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А в чём прикол Если запустил линукс с флешки хоть винт форматнуть можно, в чём ... текст свёрнут, показать
     
  • 5.39, m.makhno (ok), 13:37, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Или о чём вопрос?

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

     
  • 3.22, Аноним (22), 12:24, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это не уязвимость.
     
     
  • 4.31, m.makhno (ok), 12:44, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А я говорил про уязвимость? Просто пример наглой эксплуатации механизма работы исполняемых файлов в шиндоуз.
     
     
  • 5.49, AnonPlus (?), 16:00, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Лол, так и вход в систему без пароля (если юзер его не установил) тоже можно "наглым" назвать.

    А для защиты от твоего сценария ещё в 7-ке существовали:
    - блокировка сеанса
    - шифрование системного раздела (чтобы ты не проделал тот же трюк, сняв накопитель)

     
     
  • 6.50, m.makhno (ok), 16:22, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Лол походу ты. Какая нафиг блокировка сеанса, почитай внимательнее то, о чём я писал здесь.
    И насчёт шифрования. Я так понимаю, речь о BitLocker. При установке оси об этом речи не было, если делать, то только опосля, и я очень сомневаюсь, что 95% хомячков ей заморачивались со всякими TPM и USB-ключами.
     
  • 3.44, Аноним (44), 14:18, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Напоминает троллейбус из буханки хлеба.
     
  • 2.5, Аноним (1), 11:21, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Но вообще это забавно и подчёркивает то, что даже Microsoft не умеет писать софт под свою же ОС. Что говорить о других несчастных, которым приходится программировать под это чудо с кучей интересных технических решений.
     
     
  • 3.11, Аноним (11), 11:51, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Категорически согласен. Как-то в молодости надо было сделать DLL. Взял толстую книжку по данной теме, немного посмотрел, выбросил её и написал свою.
     
     
  • 4.13, Дегенератор (ok), 11:59, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Тебе не нравится? Ты бы был счастлив, если бы СВОЮ не сумел написать? Да что ж с вами, красно..., творится?
     
     
  • 5.75, IRASoldier_registered (ok), 07:19, 06/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мания величия, самоощущение _элитарности_ - вот что творится. Причем это не имеет отношения к собственно реальным аспектам программирования под ту или иную ОС. Просто одна группа убеждает себя в том, что использование Linux это _престижное потребление_, тогда как использование Windows таковым не является. Примерно как некоторые носители футболок с логотипом Гуччи считают себя лучше носителей футболок без такого, даже если, внезапно, и те, и другие футболки сделаны из хлопка одинакового качества, выкроены одинаково ровно и сшиты одинаково прочно (что не редкость).



     
  • 4.30, Карабьян (?), 12:43, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если привыкли делать это как в юниксах, то компилятор сам заменит .so на .dll
     
  • 4.32, Гудрон_из_саванны (?), 12:51, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Так тебе и требовалось написать свою не ?

    Или ты свою книгу по длл написал ?)

     
  • 3.25, Аноним (25), 12:39, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ты не поверишь, но там работают такие же люди как и везде у них нет никаких дополнительных сверхспособностей.
     
     
  • 4.42, Денис Попов (?), 13:57, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С той разницей, что майки могут позволить себе очень дорогой контроль качества, а Вася Пупкин - не может. Поэтому, когда софт пишет Microsoft под свою же ОСь, то качество должно быть на порядок выше того, что накалякал бы Васян.
     
     
  • 5.43, Michael Shigorin (ok), 14:09, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > очень дорогой контроль качества

    В смысле из-под самого Бангалора, а не с той дальней деревни? :D

    PS: что-то не слышал, чтоб в Эстонии некрософт мясоботов набирал...

     
     
  • 6.46, Денис Попов (?), 14:22, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В том то и дело, позволить могут, а нанимают бомжей.
     
     
  • 7.56, microsoft (?), 17:17, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Так вам и говорят что они должны нанимать архангелов для провеоки а не бомжей.
     
  • 7.57, n00by (ok), 17:19, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну почему бомжей, Go написала для них конторка денежная, хоть и забесплатно. ;) Перепишут теперь на C#, вот будет радости.
     
  • 2.18, n00by (ok), 12:11, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Эх. Ничему Microsoft история не учит. Потому что в Виндах в принципе
    > ущербно сделан поиск библиотек и исполняемых файлов.

    Поискал за Вас:

    https://github.com/git-lfs/git-lfs/blob/74d5f2397f9abe4834bf1fe1fa02fd6c141b77

    https://github.com/git-lfs/git-lfs/blob/74d5f2397f9abe4834bf1fe1fa02fd6c141b77

    Может чему научитесь.

     
  • 2.41, Lex (??), 13:48, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кое-чему они все-таки научены: проекты, которые в самом ближайшем будущем не планируется "открывать", они в принципе не хранят на гитхабе ввиду его дырявости
     
  • 2.86, еман (?), 11:06, 06/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    а в линуксе, где путь /usr/lib хардкодится в экзишники и библиотеки при компиляции - нормально?
     

  • 1.2, m.makhno (ok), 11:15, 05/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Не читаю астрологических прогнозов, но, видимо, был объявлен %промежуток времени% дыр в экосистеме GitHub.
     
     
  • 2.3, Аноним (-), 11:18, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Время пиара, которое мы запомним ни как повальную блокировку и удаление неугодных репозиториев - а страдание нивинного мелкософта атакуемого злобными дырами.
     
  • 2.6, Qwerty (??), 11:22, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну а что, тема хайповая, всегда найдётся толпа любителей позлорадствовать.
     
     
  • 3.8, Xasd7 (?), 11:42, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    а чего бы не позлорадствовать - вся коллекция архитктурный проблем Windows н... большой текст свёрнут, показать
     
  • 3.9, Аноним (1), 11:48, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это было бы злорадство, если бы это реально была ошибка в программе, а не ущербным дизайном ОС. Загружать по умолчанию бинарники и библиотеки из CWD - это верх маразма. Если CWD не находится в PATH, конечно. Это не норм, и это не то, что должен проверять рядовой разработчик. А для осознанной подмены exe/dll, когда человек знает, что он делает - должны быть отдельные механизмы, вроде того же LD_PRELOAD в Линуксах.

    И отдельного внимания стоит то, что такие ошибки регулярно допускают сотрудники Microsoft. Сначала с Office, теперь с Git LFS. И это даже не из-за некомпетентности сотрудников, а из-за broken-by-design механизма поиска библиотек и бинарников в ОС, т.к. у нормального человека не уложится в голове, что ОС пойдёт в CWD искать бинарник (который не зовётся явным образом из CWD).

     
     
  • 4.21, ms (??), 12:22, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И сколько у вас уже было _local_root_ а не "запуск не того гит от обычного юзера" из-за дыр в этом прекрасном "отдельном механизме", напомнить?

    > И отдельного внимания стоит то, что такие ошибки регулярно допускают сотрудники Microsoft.

    обычный индус, кое-как освоивший игогошечку и прошедший собеседование. То что у него в визитке значится microsoft - ни разу не делает его специалистом по windows. Он ее в своей Калькутте и не видел может.

    Это именно из-за некомпетентности сотрудников. Ну надо же, кто бы мог подумать - тут вам не линюпс, у нормального человека с образованием "рядом с гуру на улице видел экран через три чужих плеча" 'в голове не укладывается' что это другая система. Зато они дешевые!

     
  • 4.27, Ivan_83 (ok), 12:40, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вы конечно правы, но нужно было это всё делать лет 50 назад.

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

    Когда то была рекомендация кидать все dll в /system, но это привело к dll hell: когда разные проги были скомпилены с разными версиями одной dll, и каждая их кидала в /system, в итоге работала или одна прога или другая.
    Это пофиксили как раз тем что dll порекомендовали кидать в папку с прогой, а потом ещё какой то мапинг/манифесты добавили, но тут я уже соскочил с венды и не вникал.

    Если кратко то сейчас с этим уже сделать ничего нельзя - софт просто перестанет работать.

     
     
  • 5.35, Xasd7 (?), 13:20, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Сейчас арихитектура такая, что каждая прога может таскать с собой свои dll, и вспомогательные утилиты

    вот только "с собой" это по смыслу НЕ должно быть синонимом "current work directory".

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

     
     
  • 6.60, n00by (ok), 17:29, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Сейчас арихитектура такая, что каждая прога может таскать с собой свои 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

    И при чём тут Микрософт?

    Ну а че, злорадствовать, так злорадствовать? ;)


     
     
  • 7.61, M (?), 17:35, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Microsoft купила GitHub, а вместе с ним ему досталась и поделка Git LFS. Так что эти уязвимости - теперь Микрософтовские. И (ни много, ни мало) Windows-эксклюзив.
     
     
  • 8.63, n00by (ok), 17:40, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для тех учителей, кто даже после цитат и прямых намёков не понял -- уязвимость ... текст свёрнут, показать
     
     
  • 9.68, Аноним (68), 20:02, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Текущий каталог в PATH в винде по умолчанию, но виновата библиотека Неожиданный... текст свёрнут, показать
     
     
  • 10.77, n00by (ok), 09:09, 06/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В MSDN поведение документировано Документировано Разработчики под ту систему д... текст свёрнут, показать
     
  • 2.28, Аноним (25), 12:40, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А что Майки блочат все неугодное направо и налево хотя с dmca хоть без. Как раз удобное время накинуть на Майков.
     
     
  • 3.91, Аноним (-), 12:05, 07/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Майки

    Это тебе твой господин запретил называть мелкософт неприятными для него словами ?

     

  • 1.7, Иваня (?), 11:29, 05/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Windows всегда была дыркой, совсем не удивительно, что уязвимости продолжают находить.
     
     
  • 2.73, Аноним (73), 20:39, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    То ли дело кocтылинупc, в котором ту же Dirty Cow видели почти 10 лет, но принципиально не закрывали.
     
     
  • 3.92, Аноним (-), 12:07, 07/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не видели - а держали в секрете. Копрорации кстати это делали.
     

  • 1.10, Аноним (10), 11:49, 05/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >Git LFS

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

     
     
  • 2.14, morruth (?), 12:00, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это какие?
     
  • 2.17, Аноним (17), 12:06, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ради научного интереса, что вы считаете нормальной системой контроля?
     
     
  • 3.19, ms (??), 12:15, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Новая папка(244) конечно же!

     
  • 3.24, Аноним (10), 12:34, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    SVN, Hg к примеру
     
     
  • 4.34, Аноним (36), 13:12, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >SVN

    В 2020-м использовать нераспределённые системы контроля версий такое себе.

     
     
  • 5.66, Козлетто (?), 18:30, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А чего вы хотели? Распределённость и частичный чекаут больших файлов взаимно противоречивые понятия. А эти ЛФСы и т.д. это жуткие костыли, которые кстати и являются классическим централизованным репозиторием.
     
  • 4.45, Аноним (68), 14:21, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > SVN, Hg к примеру

    SVN — не смешно.
    Hg — ну да, конечно, там не нужен LFS. Там ведь есть свой костыль, который делает в точности то же самое: https://www.mercurial-scm.org/wiki/LargefilesExtension
    Потому что, ой, у нас проблемки с большими файлами: https://www.mercurial-scm.org/wiki/HandlingLargeFiles

     

  • 1.15, Аноним (15), 12:01, 05/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >для запуска нового процесса git используется вызов ExecCommand(), но не указывается полный путь к исполняемому файлу git

    А не надо запускать процессы. Нужно импортировать dllки. Если разрабы Git против редизайна гита с прицелом на незапуск процессов - то нафиг разрабов Git, у GitHub inc. хватит финансирования MS, чтобы либо форкнуть небезопасный git, либо воссоздать с нуля на растишке, и потушить оригинал.

     
     
  • 2.38, Xasd7 (?), 13:31, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > либо воссоздать с нуля на растишке, и потушить оригинал.

    не так.

    правильная фраза такая -- " либо воссоздать с нуля на растишке, и переорать оригинал."

     
  • 2.47, Аноним (68), 14:28, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А теперь объясни, с какой радости разрабы git должны переделывать всё так, как принято в винде, вместо того, чтобы продолжать использовать архитектуру, работавшую с рождения Unix? А как быть на платформах, где не поддерживаются разделяемые библиотеки, ты подумал? Ну и самое главное: в винде и exe, и dll ищутся одинаковым образом, так что в плане безопасности вообще никакой разницы нет.
     
     
  • 3.52, Аноним (15), 16:25, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Mesa у тебя тоже в отдельном процессе На доработку такие платформы Дллки линку... большой текст свёрнут, показать
     
     
  • 4.55, n00by (ok), 17:13, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Они там не запускают процессы, а вызывают стандартную функцию Go https://golang.org/pkg/os/exec/#Command
    Внезапно, функция из "кроссплатформенной библиотеки" работает не везде одинаково. Но виноваты разработчики git-lfs и Микрософт, а Гугл умнички.

     
     
  • 5.65, Карабьян (?), 18:07, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот что за бараны Вас минусуют
     
     
  • 6.67, n00by (ok), 19:26, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Кто-то по старой памяти, кому-то возразить нечего, а для кого-то я непонятно пишу.
     
  • 6.69, Аноним (68), 20:07, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Те, которые понимают, что делает эта стандартная библиотечная функция, и знают, что стандартные библиотечные функции для других языков работают точно так же.
     
     
  • 7.83, n00by (ok), 09:47, 06/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Те, которые понимают, что делает эта стандартная библиотечная функция

    А "эта" функция, на которую я выше привел ссылку, ничего криминального и не делает. Но Вы же понимаете, и потому скажете, в какой конкретно дело?

     
  • 6.84, n00by (ok), 10:00, 06/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, тут Вы угадали, уникальный случай. Аргументация "ваша любимая Microsoft" https://www.opennet.dev/openforum/vsluhforumID3/122328.html#76
    это как раз уровень барана. То есть он банально не умеет даже по ссылкам на профиль кликать, или заметить, что я "МИКРОсофт" тут пишу. Нафантазировал красную тряпку перед носом и вперёд, гонимый ненавистью к вымышленному врагу.)
     
  • 5.76, Аноним (76), 09:07, 06/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А ничего, что CWD в PATH по умолчанию в Винде, а виновата, внезапно, конечно же стандартная функция из "кроссплатформенной библиотеки" Go? Которая следует стандартам и соглашениям, принятым в данной ОС. И уж точно не создатели Git LFS и не ваша любимая Microsoft.

    Вы ещё скажите, что в былых эпидемиях флешечных autorun-вирусов во времена Windows XP были виноваты производители флешек. Ишь ты, съёмные диски повадились производить. А Autorun любой малвари по умолчанию со всех флешек - это грамотная, продуманная архитектура.

    Такая поделка (Винда) нафиг не нужна, которая пихает CWD в PATH. Не зря экосистема Windows кишит малварью, потому что архитектура ОС представляет все мыслимые и немыслимые средства для распространения вредоносного кода.

     
     
  • 6.78, n00by (ok), 09:14, 06/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А ничего, что CWD в PATH по умолчанию в Винде, а виновата,
    > внезапно, конечно же стандартная функция из "кроссплатформенной библиотеки" Go? Которая
    > следует стандартам и соглашениям, принятым в данной ОС. И уж точно
    > не создатели Git LFS и не ваша любимая Microsoft.

    Где она следует и как Вы про это узнали? Сами придумали? Или дадите цитату из документации библиотеки, что там "CWD в PATH по умолчанию в Винде"?

    > Вы ещё скажите, что в былых эпидемиях флешечных autorun-вирусов во времена Windows
    > XP были виноваты производители флешек. Ишь ты, съёмные диски повадились производить.

    Вы уже это сказали, приписали мне и начали с вымышленным мной спорить. Успехов в этом не лёгком деле. ;)

     
  • 6.87, Аноним (15), 13:30, 06/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Вы ещё скажите, что в былых эпидемиях флешечных autorun-вирусов во времена Windows XP были виноваты производители флешек

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

     
  • 4.58, Аноним (68), 17:21, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Mesa у тебя тоже в отдельном процессе?

    И причём здесь mesa?

    > На доработку такие платформы.

    О том, что доработка может быть нецелесообразна по объективным причинам, не задумывался? Да и вообще, это забота разработчиков прикладного софта обеспечить совместимость с определённой платформой, а не наоборот.

    > любой интерфейс, допускающий инъекцию, фундаментально небезопасен

    В винде любой интерфейс допускает инъекцию, так что нечего стрелки переводить.

    > Использование же общих библиотек - лучший по всем параметрам подход.

    Нет. Особенно в случае винды, где нет нормального пакетного менеджера, который обеспечил бы установку библиотеки совместимой версии.

     
     
  • 5.62, n00by (ok), 17:36, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Да и вообще, это забота разработчиков прикладного софта обеспечить совместимость с
    > определённой платформой, а не наоборот.

    Вот разработчики и написали за Гугль правильную LookPath(), когда узнали, что документация врёт.

     
     
  • 6.70, Аноним (68), 20:08, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Где же она врёт-то? Как написано, так и работает.
     
     
  • 7.80, n00by (ok), 09:16, 06/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Где же она врёт-то? Как написано, так и работает.

    Дайте цитату документации Go где написано, что будет запуск из текущего каталога. Вы же не врёте?

     
  • 6.79, Аноним (76), 09:14, 06/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Т.е. по вашему, функция, которая ищет бинарники в PATH, внезапно, не должна искать бинарники в PATH? В Винде CWD входит в PATH, и более того, стоит на первом месте в PATH, как наиболее приоритетный источник загрузки бинарников, так что функция работает корректно, по документации, а главное, соблюдает принятые в Винде стандарты и соглашения, даже если они маразматичные.
     
     
  • 7.81, n00by (ok), 09:18, 06/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Т.е. по вашему, функция, которая ищет бинарники в PATH, внезапно, не должна
    > искать бинарники в PATH? В Винде CWD входит в PATH

    В Винде входит, о чём в документации Винды прямо написано. В Go в некоторых случаях входит, в остальных не входит, о чём в документации не написано. Поэтому пользователь "кроссплатформенной" библиотеки должен читать MSDN, а виновата Микрософт.

     
  • 5.88, Аноним (15), 13:38, 06/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Значит это мёртвые ненужные платформы Это забота разработчика платформы - реали... большой текст свёрнут, показать
     

  • 1.16, n00by (ok), 12:04, 05/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Примечательно, что в описании функции Win32 API CreateProcessW() о подобном риске сказано https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-proces

    Но разработчики документацию не читали, вместо этого использовали "безопасный язык":



    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)


     
     
  • 2.71, Аноним (71), 20:18, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В описании говорится о другом риске. О риске запуска другого exe если путь содержит пробел.
     
     
  • 3.82, n00by (ok), 09:27, 06/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > В описании говорится о другом риске.

    Простите, но я даже и не думал, что кому-то здесь придётся объяснять смысл слова "подобный".

    > О риске запуска другого exe если
    > путь содержит пробел.

    Потому что такое поведение не для всех очевидно. То что обсуждается в новости, для любого тамошнего разработчика очевидно, так же как для тутошних очевиден смысл ./. Если бы накосячившие работали с API системы, это был бы их косяк. Но они поверили в кроссплатформенность и взяли "безопасную" прослойку, которая данный случай не предусмотрела.

     

  • 1.33, Аноним (36), 13:09, 05/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Надо Винде поторопиться с переходом на использование fork(). ;)
     
     
  • 2.37, Xasd7 (?), 13:24, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    вот ток проблема втом что их "лёгкий" CreateThread() работает даже дольше тем "тяжёлый" fork() в linux.
     

  • 1.51, Аноним (-), 16:23, 05/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Майкрософт прокляли!
     
  • 1.53, TastyApple (ok), 16:29, 05/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ещё 1 причина, чтоб не переходить на Wind'у.
     
     
  • 2.54, Аноним (54), 16:32, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вряд ли это причина.
     
     
  • 3.59, microsoft (?), 17:27, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Тоесть все массово переходим таки?
     
     
  • 4.64, TastyApple (ok), 18:04, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Тоесть все массово переходим таки?

    Да, и побыстрее. Чтоб Linux окончательно скатился к "Хроникам Нарнии" :)

     
  • 2.72, Аноним (71), 20:19, 05/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Так баг починили. Так что можно лететь сломя голову.
     

  • 1.74, Аноним (74), 00:10, 06/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Естественно на windows, где же ещё как ни на кривой системе с убогой архитектурой.
     
  • 1.89, Аноним (89), 15:35, 06/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Проблема проявляется только на платформе Windows

    Поэтому на лоре этой новости не будет

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру