| 1.1, Аноним (1), 20:38, 14/09/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Пользуюсь voidlinux, но рад, что дружественный проект исправил уязвимость.
| | |
| |
| 2.2, Оффтоп (?), 20:50, 14/09/2018 [^] [^^] [^^^] [ответить]
| –3 +/– |
кстати про voidlinux и уязвимости. Они до сих пор не переехали с гитхаба?
| | |
|
| 1.5, freehck (ok), 21:23, 14/09/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 Выполнить любой код в Alpine? Ммм, значит дистр, ориентированный на безопасность. :)
| | |
| |
| 2.6, Аноним (6), 22:14, 14/09/2018 [^] [^^] [^^^] [ответить]
| +3 +/– |
интересно, как в этом плане обстоят дела у apt/dnf/zypper
| | |
| |
| 3.16, DerRoteBaron (ok), 23:30, 15/09/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
 У dnf/zypper в их родной среде должно быть меньше проблем, так как rpm это не матрёшка из tgz/txz, а специфичный формат, содержащий подпись в заголовке и, если я правильно понял, подписывающей cpio-payload, а не файлики внутри по одному.
И собственно инвалидность подписи проверяется ещё до начала транзакции
| | |
| |
| 4.25, freehck (ok), 07:46, 01/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
> У dnf/zypper в их родной среде должно быть меньше проблем, так как
> rpm это не матрёшка из tgz/txz, а специфичный формат, содержащий подпись
> в заголовке и, если я правильно понял, подписывающей cpio-payload, а не
> файлики внутри по одному.
Ещё бы тебе уяснить, что на подписи отдельных пакетов, если таковые вообще имеются, никто и никогда не смотрит, потому что достаточно один раз проверить подпись репозитория, а дальше уже просто сверять хеш пакета с проверенным. И это общий подход для дистров, что для deb, что для rpm.
| | |
|
| 3.24, Аноним (-), 18:42, 27/09/2018 [^] [^^] [^^^] [ответить]
| +/– |
Лучше. За годы развития их все-таки в целом отучили от детских болезней. Тот же apt+dpkg вообще ничего распаковывать не будет если подпись или хэш кривые. До этого дело просто не дойдет.
| | |
| 3.26, EHLO (?), 10:29, 01/10/2018 [^] [^^] [^^^] [ответить]
| +/– | |
>интересно, как в этом плане обстоят дела у apt/dnf/zypper
предсказуемо хуже. Поиск по базе CVE в помощь.
| | |
|
|
| 1.8, Аноним (8), 00:38, 15/09/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Очень интересует, что употребляют люди, которые придумывают такие атаки, и можно ли эти вещества где-то купить без рецепта?
| | |
| |
| 2.13, test_test (?), 09:21, 15/09/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ничего они не употребляют. Просто используют метод научного тыка, курят мануалы и комбинируют мелкие уязвимости в большие. Просто чуваки оч умные.
| | |
|
| 1.9, Аноним (9), 04:25, 15/09/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
> проект Alpine Linux выпустил обновление 3.8.1, в который включено данное исправление.
...которое загружается тем самым пакетным менеджером?
| | |
| 1.15, нонима (?), 23:04, 15/09/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>> ошибка проявляется на стадии распаковки пакета, которая выполняется до проверки цифровой подписи
Л - логика. Распаковать и только потом проверять.
| | |
| 1.18, Аноним (18), 09:55, 16/09/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Это значит, что пакетные менеджеры следует разбивать на часть, которая принимает, распаковывает, проверяет КС и часть, которая на самом последнем этапе помещает прошедшие проверку файлы в ФС ОС. Первая часть должна перед началом работы сменить владельца процесса на какого-нибудь совсем бесправного пользователя.
| | |
| |
| 2.19, Аноним (19), 11:12, 16/09/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Это значит, что пакетные менеджеры следует разбивать на часть, которая принимает, распаковывает,
> проверяет КС и часть, которая на самом последнем этапе помещает прошедшие
> проверку файлы в ФС ОС. Первая часть должна перед началом работы
> сменить владельца процесса на какого-нибудь совсем бесправного пользователя.
А почему нельзя сделать, чтобы системное дерево и файлы принадлежало пользователю типа rootfs?
Чтобы никто кроме rootfs и root не мог изменить файлы.
| | |
|
|
