Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциально приводящая к выполнению кода"	+/–
Сообщение от opennews (??), 14-Апр-26, 13:13
В поставляемых в составе CPython классах распаковки сжатых данных в форматах  lzma, bz2 и gzip (lzma.LZMADecompressor, bz2.BZ2Decompressor и gzip.GzipFile) выявлена уязвимость (CVE-2026-6100), приводящая к обращению к памяти после её освобождения. Проблема присвоен критический уровень опасности (9.1 из 10) -  в случае успешной эксплуатации уязвимость может привести к утечке информации из памяти процесса или выполнению кода атакующего при распаковке специально оформленных данных... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=65202
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+1 +/–
Сообщение от Аноним (1), 14-Апр-26, 13:13
Ну вот добрались и до биндингов к скриптовым языкам, которые всю дорогу писали как попало. Без сишных зависимостей этот питон даже ползать не сможет, так что впереди длинный путь )))
Ответить | Правка | Наверх | Cообщить модератору

2. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
Сообщение от Аноним Мю (?), 14-Апр-26, 13:17
Хорошо, а какие версии Python затронуты?
Ответить | Правка | Наверх | Cообщить модератору

	6. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+1 +/–
	Сообщение от Аноним (6), 14-Апр-26, 13:27
	Функция zlib'а в текушем виде как минимум 4 года существует, дальше по коммитам не прошёлся, потому что гитхаб - неудобное лагающее г~вно
	Ответить | Правка | Наверх | Cообщить модератору

	10. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	–2 +/–
	Сообщение от openssh_user (ok), 14-Апр-26, 13:33
	В чём проблема склонировать репо?
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+2 +/–
	Сообщение от Аноним (11), 14-Апр-26, 13:42
	На айфон не копируется.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+1 +/–
	Сообщение от Аноним (43), 14-Апр-26, 17:45
	Попросите Apple поработать.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+1 +/–
	Сообщение от Аноним (6), 14-Апр-26, 13:47
	В том что на простой вопрос на опеннетике дать простой ответ проще, чем достать комп чтобы скачать репу и быстро найти там, где функция появилась. Хотите - найдите. Я лично считаю что бага никакого и не было, либо его надо фиксить не там, потому что выглядят патчи как рандомный вброс типичных "ааааа нулл забыли", т.е. скорее всего ллмкой по популярному проекту прошлись и она что-то выбрзнула.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

3. Скрыто модератором	+3 +/–
Сообщение от Аноним (-), 14-Апр-26, 13:20
C moment?
Ответить | Правка | Наверх | Cообщить модератору

8. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
Сообщение от Аноним (6), 14-Апр-26, 13:30
Занулили какой-то рандомный указатель, который потом может нигде и не используется... С этими вашими лллмками только strcpy да рандомное отсутствие '= NULL' сейчас и будут исправлять всякие идиоты, которым нужно коммитов налутать для... чего-то... джиа-танов новых подготавливают наверное.
Ответить | Правка | Наверх | Cообщить модератору

	31. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	–1 +/–
	Сообщение от Сладкая булочка (?), 14-Апр-26, 16:21
	Тест добавили, однако какой-то phd чел пришел и сказал, что не нужно > Considering we need to hit an error path with a MemoryError, I'm not sure we really need a test. Sometimes we do add tests, sometimes not. I don't think there is a need to add a test. The test also don't assert that we hit the goto so I don't think we need it. Видите ли в своих же тестах питонисты не смогли создать способ задать кол-во доступной памяти.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от ruroruro (ok), 14-Апр-26, 16:59
	> питонисты не смогли создать способ задать кол-во доступной памяти Буквально следующий коммент после того что вы процитировали: > agreed, while it is neat that we have `_testcapi.set_nomemory` (I didn't realize that), it is a difficult thing to use in a deterministic manner to show that the specific case in desire of covering is hit. usually not worth it.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Сладкая булочка (?), 14-Апр-26, 17:10
	>> питонисты не смогли создать способ задать кол-во доступной памяти > Буквально следующий коммент после того что вы процитировали: >> it is a difficult thing to use in a deterministic manner to show that the specific case in desire of covering is hit. usually not worth it. Получается готового эксплойта нет? А что тогда столько шума? А если есть, то почему его в тест не засунуть?
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+1 +/–
	Сообщение от ruroruro (ok), 14-Апр-26, 17:49
	Лично я рабочего эксплоита не видел. Учитывая, что lzma/bz2/gzip под капотом все равно декомпрессию делают чанками и на большинстве современных машин память выделяется с overcommitом, на самом деле даже просто словить MemoryError в данной ситуации - не очень просто (если просто сделать скажем bz2 файл, который декомпрессится в больше данных чем есть оперативки, то процесс просто будет убит OOM Killerом, а не MemoryError). Тест, который изначально был в PR - синтетически симулирует истощение памяти (то есть `_testcapi.set_nomemory` просто делает так чтобы следующий `PyMem_Malloc` "прикинулся" что памяти нет). Это конечно хорошо, но просто такие тесты на самом деле не очень демонстрирует, что действительно уязвимости нет. То есть, например, в моих экспериментах эти тесты не приводят к крашу даже на версиях питона, в которых баг не исправлен. Так что ¯\_(ツ)_/¯. А на счет "столько шума", добро пожаловать в мир CVE. Вообще даже если бы был эксплоит, скора 9.1 он сто пудов не заслуживал бы (т.к. при "нормальном" использовании lzma/bz2/gzip никто в здравом уме не станет ловить MemoryError и после этого продолжать использовать тот же самый Decompressor объект). Ну это мое ИМХО.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Сладкая булочка (?), 14-Апр-26, 20:13
	> Учитывая, что lzma/bz2/gzip под капотом все равно декомпрессию делают чанками и на большинстве современных машин память выделяется с overcommitом, на самом деле даже просто словить MemoryError в данной ситуации - не очень просто (если просто сделать скажем bz2 файл, который декомпрессится в больше данных чем есть оперативки, то процесс просто будет убит OOM Killerом, а не MemoryError). Можно контейнер отдельный для этого теста сделать.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от ruroruro (ok), 14-Апр-26, 20:36
	>> Учитывая, что lzma/bz2/gzip под капотом все равно декомпрессию делают чанками и на большинстве современных машин память выделяется с overcommitом, на самом деле даже просто словить MemoryError в данной ситуации - не очень просто (если просто сделать скажем bz2 файл, который декомпрессится в больше данных чем есть оперативки, то процесс просто будет убит OOM Killerом, а не MemoryError). > Можно контейнер отдельный для этого теста сделать. Мои рассуждения на тему overcommit и OOM были относительно вопросов "есть ли готовый эксплоит" и "насколько реалистичная / значительная эта уязвимость на самом деле", а не "как сделать тест". Тащить docker как зависимость CPython просто ради этого теста - так себе идея. Функционала `_testcapi.set_nomemory` вполне достаточно для того чтобы симулировать MemoryError в нужном месте. Проблема с тем тестом, который убрали из PRа - не в том как вызвать MemoryError, а в том, как потом однозначно задетектировать, была ли "утечка" указателя или нет. Тот тест, который исходно был в PR - выполнял "проблематичную" последовательность операций с повторным decompress после MemoryError, но никак не проверял, была ли уязвимость. Утечка освобожденного указателя сама по себе вообще ничего не гарантирует. Может быть что этот указатель вообще нигде дальше использоваться не будет и тогда ничего не произойдет. Или может быть что кто-то что-то с этим указателем сделает (и формально будет use after free), но этот use after free не приведет к крашу - зависит от того, будет ли что-то mallocнуто "поверх" освобожденной памяти и что именно там будет размещено (какая-нибудь структура нужная интерпретатору или скажем просто какие-нибудь данные). Конечно, есть всякие fuzzerы, address sanitizerы и прочий инструментарий, с помощью которого можно было бы более точно убедиться в наличии / отсутствии этого use after free. Но это уже отдельная тема. Тот юнит тест, который был в исходном PRе однозначно детектировать утечку указателя в данной ситуации не позволял и соответственно этот тест выпилили.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Сладкая булочка (?), 14-Апр-26, 20:49
	>>> Учитывая, что lzma/bz2/gzip под капотом все равно декомпрессию делают чанками и на большинстве современных машин память выделяется с overcommitом, на самом деле даже просто словить MemoryError в данной ситуации - не очень просто (если просто сделать скажем bz2 файл, который декомпрессится в больше данных чем есть оперативки, то процесс просто будет убит OOM Killerом, а не MemoryError). >> Можно контейнер отдельный для этого теста сделать. > Тащить docker как зависимость CPython просто ради этого теста - так себе идея. Можно без всякого докера нативно на линуксе это сделать. И да, тест будет линукс only. > Конечно, есть всякие fuzzerы, address sanitizerы и прочий инструментарий, с помощью которого > можно было бы более точно убедиться в наличии / отсутствии этого > use after free. Но это уже отдельная тема. Ну да, логично тесты запускать с ubsan хотя бы. > Тот юнит тест, который был в исходном PRе однозначно детектировать утечку указателя в данной > ситуации не позволял и соответственно этот тест выпилили. Это понятно, но взамен ничего не принесли. Где гарантия, что "завтра" эти зануления указателей снова не пропадут? Понятно, что случай крайний, но он показывает, что готовой инфрастурктуры для тестирования в условиях настоящего исчерпания памяти нет.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от ruroruro (ok), 14-Апр-26, 21:15
	> Это понятно, но взамен ничего не принесли. Где гарантия, что "завтра" эти > зануления указателей снова не пропадут? Понятно, что случай крайний, но он > показывает, что готовой инфрастурктуры для тестирования в условиях настоящего исчерпания > памяти нет. Нууу... Я не очень вникал, но вроде как сборка со всякими SANами у них в CI есть https://github.com/python/cpython/blob/main/.github/workflow... и даже fuzzing какой-то есть https://github.com/python/cpython/blob/main/.github/workflow.... Так что инфраструктура точняк есть. Правда очевидно, что этот fuzzing данную уязвимость не нашел (но тут пожалуй тоже понятно, fuzzing сам по себе вряд ли мог бы edge case с MemoryError вызвать). Ну а то что сейчас взамен нормальный тест не добавили - idk. Может просто чтобы побыстрее фикс выкатить. Или может мэйнтейнеры (также как я) считают что данная уязвимость на самом деле не супер критичная. Или может как раз нужен более полноценный репродюсер. Если вам кажется что это мега срочно / критично - вы всегда можете самостоятельно оформить PR с нормальными тестами (ну или хотя бы выразить свое мнение в том треде комментариев, где решили эти тесты убрать). Опенсорс же.
	Ответить | Правка | Наверх | Cообщить модератору

9. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	–4 +/–
Сообщение от Аноним (9), 14-Апр-26, 13:33
Вот и в managed-языках бывают ошибки работы с памятью. А уж в компилируемом Расте, тем боллее, могут быть.
Ответить | Правка | Наверх | Cообщить модератору

	12. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+1 +/–
	Сообщение от Аноним (11), 14-Апр-26, 13:43
	Все эти ошибки по работе с памятью это пугалки для детей. Чтобы заставить их делать то что тебе выгодно, а не им.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "-"	–2 +/–
	Сообщение от Аноним (21), 14-Апр-26, 15:14
	Так и запишем: >Полицаи и турма - пугалки для детей, чтобы заставить их делать то, что им не нужно, на взрослых не работает.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "-"	+2 +/–
	Сообщение от Аноним (24), 14-Апр-26, 15:43
	Аналогии это вот прям вообще не твое. Тут скорее аналогия с рен тв и рептилоидами. Но ты конечно продолжай  включать защитную реакцию чтобы защитить своё ошибочное мировоззрение.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Аноним (60), 14-Апр-26, 20:21
	Поясните, что это значит, каким таким образом мне выгодны уязвимости в проекте ? Если я правильно вас понимаю, то разве такие вопросы решаются не политикой ? Я имею ввиду что если будет надо, то утекут и сорцы и ключи и политическое решение будет и всё что хочешь. Примеры с защищенными анклавами, тивоизацией мобильных устройств, даже хотя бы взять сорсы крупных закрытых проектов - всё утекает или взламывается. С другой стороны, если посмотреть на то что вы предлагает, это выглядит как страх, заставляющий принимать странные решения. Ведь проблема-то лежит не в уязвимостях как таковых, они всегда зло. И только на этом ресурсе в секции комментов я видел как люди предлагают борьбу на политическом поле инструментами downgrade'а. Больше ни где такого нет. Я не хочу видеть уязвимости ни в чем, чем я пользуюсь. И не понимаю людей, которые пытаются убедить меня что это хорошо, когда поверхность атаки (attack surface) того, чем я пользуюсь, шире для всех.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	19. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Аноним (19), 14-Апр-26, 14:32
	> Вот и в managed-языках бывают ошибки работы с памятью. Ошибка не в языке, а в конкретной реализации. Потому что реализация на dъряхе, а там всегда клали болт на безопасность и на работу с памятью.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	29. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	–2 +/–
	Сообщение от Аноним (9), 14-Апр-26, 16:13
	Ошибка в библиотеке на языке.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+2 +/–
	Сообщение от Аноним (32), 14-Апр-26, 16:28
	> Ошибка в библиотеке на языке. На каком языке? Ты там код на питоне увидел? Дырень в CPython. CPython это реализация (implementation) питона. Кроме него есть и другие - IronPython, Jython и тд. В них есть эта дыра?
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	–1 +/–
	Сообщение от Аноним (36), 14-Апр-26, 16:49
	Ещё раз, ошибка в библиотеке, а не языке.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	–1 +/–
	Сообщение от Аноним (9), 14-Апр-26, 19:18
	В голове у тебя дырень и уже давно.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	55. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Аноним (55), 14-Апр-26, 19:22
	> В голове у тебя дырень и уже давно. Ого какое хамство и агрессия. Вы наверное на СИ пишете? А если по делу. В файлах на каком языке нашли уязвимость? Спойлер: это не питон)
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Сладкая булочка (?), 14-Апр-26, 20:15
	>> Ошибка в библиотеке на языке. > На каком языке? Ты там код на питоне увидел? > Дырень в CPython. CPython это реализация (implementation) питона. > Кроме него есть и другие - IronPython, Jython и тд. В них > есть эта дыра? Еще rustpython вспомни. Кстати, где в проде хотя бы один из приведенных используется?
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

18. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	–1 +/–
Сообщение от Аноним (19), 14-Апр-26, 14:31
> Уязвимость в Python-библиотеках Какая прелесть! Дырени в _bz2module.c, _lzmamodule.c и zlibmodule.c
Ответить | Правка | Наверх | Cообщить модератору

	34. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от мимо проходил (?), 14-Апр-26, 16:44
	Ага, вот что случается если детям дать спички или питонячим погроммистам пописать на Си.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+2 +/–
	Сообщение от Аноним (49), 14-Апр-26, 18:22
	> Ага, вот что случается если детям дать спички или питонячим погроммистам пописать на Си. Да-да, Настостоящий Сишник™ такую бы ошибку никогда бы не допустил! А если бы допустил, то значит это ненастоящий сишник. Правда настощие сишники как единороги - никто сам никогда не видел, но всегда есть брат свата который слышал про такого.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Аноним83 (?), 14-Апр-26, 20:49
	Почему то это волнует только вас. Интересно что с вами не так?)
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	64. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Аноним (64), 14-Апр-26, 21:06
	> Почему то это волнует только вас. Не только меня Ваня, не только меня. > Интересно что с вами не так?) А что не так? Просто обратили внимание что питон к проблеме отношения не имеет.
	Ответить | Правка | Наверх | Cообщить модератору

	70. Скрыто модератором	+/–
	Сообщение от Аноним83 (?), 14-Апр-26, 23:55
	Вас то это всё как касается?
	Ответить | Правка | Наверх | Cообщить модератору

20. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+4 +/–
Сообщение от Аноним (20), 14-Апр-26, 15:05
Читаешь новость "Уязвимость в Python-библиотеках" "уязвимость, приводящая к обращению к памяти после её свобождения". Думаешь "да ладно? как же так?!" А потом открываешь патчик, а там cpython! И все сразу становится на свои места))
Ответить | Правка | Наверх | Cообщить модератору

22. Скрыто модератором	+/–
Сообщение от Аноним (22), 14-Апр-26, 15:15
Опять надо было просто уметь, но опять просто не смогли.
Ответить | Правка | Наверх | Cообщить модератору

23. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+3 +/–
Сообщение от Аноним (23), 14-Апр-26, 15:31
Всё это эдж кейсес, которые в реальных сценариях никак не_проявляют себя. Их устранение чаще всего не_обосновано из-за оверинжиниринга. Это как делать проверку словаря на нулевые значения, которые могут вызвать деление на ноль, хотя сам словарь априори заполняется правильно, чисто by design исключая нули.
Ответить | Правка | Наверх | Cообщить модератору

	26. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	–2 +/–
	Сообщение от Аноним (22), 14-Апр-26, 15:50
	> Всё это эдж кейсес, которые в реальных сценариях В реальных сценариях через это и ломают. > никак не_проявляют себя. Тебя Артемис 2 с Луны только что привёз? > Их устранение чаще всего не_обосновано из-за оверинжиниринга. Это правда. На си настолько неудобно и сложно писать, что хорошо сделанная работа требует слишком много усилий, поэтому сишники делают работу спустя рукава.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	–2 +/–
	Сообщение от Аноним (28), 14-Апр-26, 16:04
	> поэтому сишники делают работу спустя рукава. а никто их не учил ка надо делать, Си ведь для них "высокоуровневый" ЯП, который почему-то требует архитектурных знаний, ну вопрос - а зачем мне тогда Си? Усердный Сишник - на асм писать будет, а остальные ничем от питоновых "тяпляпщиков" не отличаются. А почему никто на асм не пишет, я объяснял в прошлых новостях, никто не хочет изучать архитектуру ЦПУ когда она через полгода протухает и никак не стабилизируется - ад одним словом. Бабла ради все? ну ок, тогда платите бабло за качественный код на том же Си. А так все заслуженно, и спецам на руку, им не нужен качественный софт это же угроза нац. безопасТности!
	Ответить | Правка | Наверх | Cообщить модератору

	66. Скрыто модератором	+/–
	Сообщение от Аноним (-), 14-Апр-26, 21:42
	> На си настолько неудобно и сложно писать Понятия не имею, с роду на си ничего не писал. Мой удел это Python. И даже на Python большинство багов, которые находят нейронки - edge cases, которые никак не влияют на работоспособность и безопасность, но их закрытие увеличивает размер модуля иногда раза в два.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	27. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Аноним (28), 14-Апр-26, 15:59
	> Их устранение чаще всего не_обосновано из-за оверинжиниринга. оверинжиниринг - бред, там должна быть проверка на нулевые значения, точнее на корректные значения.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	30. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	–3 +/–
	Сообщение от Аноним (30), 14-Апр-26, 16:19
	Ну так для СИшников дополнительные проверки и есть оверинжениринг. Они просто не могут номально проверять краевые случае и инварианты, в силу убогости инструмента и непривычности задачи. Как писал Теордор Тцо "check if directory block is within i_size". А там уже как повезет.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+1 +/–
	Сообщение от Аноним (28), 14-Апр-26, 16:42
	> Ну так для СИшников дополнительные проверки и есть оверинжениринг. Как понимать "дополнительные проверки"? - Проверки бывают либо необходимые и достаточные, либо - избыточные. Любой оптимальный корректный алгоритм имеет необходимые и достаточные проверки.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	–1 +/–
	Сообщение от Аноним (37), 14-Апр-26, 16:55
	> Как понимать "дополнительные проверки"? - Проверки бывают либо необходимые и достаточные,  либо - избыточные. Любой оптимальный корректный алгоритм имеет необходимые и достаточные проверки. Ээээ, ты это что-то на умном пишешь. Ты просто думай по другому. "Если проверка замедляет программу на 1% - значит выкинем ее, пофиг что возможно это приведет к CVE с получением рута" "Если проверка мне мешает - значит это неудобная и ненужная проверка" "Если мне лень - значит проверка не нужная" "В недоязыке ошибку приходится пробрасывать как отрицательный инт? ну и пофиг, сделаем просто функцию signed, а не такой как она должна быть" Как писал Дуглас Макилрой про первые CVE в только что изобретенном СИ "Overflowable buffers were common in those days. It was all too easy when programming to shrug one's shoulders and opine that nobody would ever want to input a 200-character line, say, so why bother writing the extra code to catch it?   Dennis once fed a couple-of-thousand-byte line on standard input to everything in /bin. Crashes abounded, but so what?" tuhs.org/pipermail/tuhs/2026-January/032966.html В общем всем было положить на качество и это не поменялось до сих пор.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Аноним (28), 14-Апр-26, 18:13
	> Ты просто думай по другому. Чтобы думать по твоему, необходимо дать пояснения всяким этим терминам "замедляет", "мешает", "неудобная", "ненужная", "лень", "пробрасывать". Моя твоя без этих пояснений - не понимать. > Crashes abounded, but so what? Ну и помирают люди, что с этого? Зачем лечить, так ведь? Зачем вообще программировать, оно же не съедобное. > В общем всем было положить на качество и это не поменялось до сих пор. потому-что, это банальные люди за конвейером, условно - человек закручивающий винты айфона, разве разбирается по какой причине условно он закручивает 4 винта, а не 1? Нет, конечно, так и в "программировании", точнее кодировании, это банальные "манки-кодеры".
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Аноним (50), 14-Апр-26, 18:23
	> Чтобы думать по твоему, необходимо дать пояснения всяким этим терминам "замедляет", "мешает", "неудобная", "ненужная", "лень", "пробрасывать". Моя твоя без этих пояснений - не понимать. Ладно термины "мешает" и "неудобная" могут быть неясным, хотя значат всего лишь "тут надо сделать проверку, но уже 6 вечера пятницы..." Но что неясно в термине "лень"?)) >> Crashes abounded, but so what? > Ну и помирают люди, что с этого? Зачем лечить, так ведь? Зачем вообще программировать, оно же не съедобное. Деньги) > потому-что, это банальные люди за конвейером, условно - человек закручивающий винты айфона, разве разбирается по какой причине условно он закручивает 4 винта, а не 1? Нет, конечно, так и в "программировании", точнее кодировании, это банальные "манки-кодеры". Не уверен что автор цитаты - чувак который разрабатывал юникс и вместе с создателями СИ переписывал его на СИшку - прям таки маникодер. Просто тогда была такая "культура работы". Ну и наверняка их подгоняли, что впрочем не дает оправляния бракодельству.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Аноним (28), 14-Апр-26, 19:35
	> Но что неясно в термине "лень"?)) Не хочешь делать, не делай вовсе. Лень - это моральный кнут. Раньше рабов кнутом заставляли работать, а теперь придумали слово "лень". Делайте выводы. Почему человеку не "лень" есть, пить, просыпаться по утрам и т.д.? Понятие "лени" возникает тогда когда есть выбор - делать или не делать. А там где природа не дает этого выбора - то и никакой "лени" нет. Отсюда, лень - всего лишь "отрицательный" (нежелательный) выбор и этот выбор - равнозначен и независим. Отсюда между "делать и не делать" никакой разницы нет и то и то можно считать "ленью", просто одна из них отрицательная. Аналогия с истиной, ложь ведь это отрицание истины. > Деньги) а ну да, я забыл, что они съедобные :) > Не уверен что автор цитаты - чувак который разрабатывал юникс и вместе с создателями СИ переписывал его на СИшку - прям таки маникодер. А кто он по вашему после таких утверждений? Мы будем, к примеру, воспринимать какого-либо математика, который бездоказательно что-либо утверждает или доказывает что-либо не строго, опуская некоторые важные детали? Думаю, НЕТ!!! А чем программирование - не математика? Ты "поленился" проверить на корректность входные параметры, итог - некорректный алгоритм. Иного быть не может. > Просто тогда была такая "культура работы". Культура работы где? В школьных математических кругах, могут не доказывать ни одну теорему, а вот в академических - вас даже слушать не будут без доказательств тех или иных утверждений. Делаем выводы, что вся ваша эта культура программирования сродни школьной математике, а реальность требует ведь академической. > Ну и наверняка их подгоняли, что впрочем не дает оправляния бракодельству. Как по мне, это банальная ловушка "автоматизации".
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Аноним (53), 14-Апр-26, 18:58
	>Всё это эдж кейсес, которые в реальных сценариях никак не_проявляют себя. Их устранение чаще всего не_обосновано из-за оверинжиниринга. Надо же. Оказывается, нормальная обработка данных сишниками не практикуется, так как они это попросту не умеют.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

35. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+3 +/–
Сообщение от ruroruro (ok), 14-Апр-26, 16:48
> The vulnerability is only present if the program re-uses decompressor instances across multiple decompression calls even after a `MemoryError` is raised during decompression. Using the helper functions to one-shot decompress data such as `lzma.decompress()`, `bz2.decompress()`, `gzip.decompress()`, and `zlib.decompress()` are not affected as a new decompressor instance is used per call. If the decompressor instance is not re-used after an error condition, this usage is similarly not vulnerable. То есть для того чтобы попасть на эту уязвимость нужно сделать что-то вроде: ``` d = lzma.LZMADecompressor() try:     d.decompress(malicious_data) except MemoryError:     pass d.decompress(more_malicious_data) ``` Ага, это явно CVE 9.1, Critical.
Ответить | Правка | Наверх | Cообщить модератору

	38. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Аноним (38), 14-Апр-26, 16:56
	> Ага, это явно CVE 9.1, Critical. А оно может прилитель снаружи? Типа запустил скрипт с интернета и он тебе подгадил?
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+3 +/–
	Сообщение от ruroruro (ok), 14-Апр-26, 17:02
	шта? Если ты запустил зловредный скрипт с интернета, то никакого CVE и не нужно, ты и так уже выполняешь arbitrary code.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Аноним (42), 14-Апр-26, 17:37
	Чуть проще (из недавнего): скачал модельку для блендера со встроенными скриптами...
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+1 +/–
	Сообщение от Аноним (28), 14-Апр-26, 18:16
	да у вас уже notepad.exe уже исполняет код при открытии .txt :)
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Аноним (57), 14-Апр-26, 19:43
	Ну малформед юникод кидал десятку в бсод (в линуксе он может даже не малформед, у майкрософта свой собственный юникод).
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
	Сообщение от Аноним (6), 14-Апр-26, 23:51
	> в линуксе В линуксе, как минимум в ядре, вообще пофигу на кодировку текста, пока это null-терминированные строки. В адекватных и с выключенными дебильными опциями, которые таки заставляют систему парсить юникод, файловых системах то же самое, только '/' в резолвере путей является разделителем. Да и вообще, utf-8 парсится элементарно в код-поинты, с которыми дальше можешь делать что хочешь.
	Ответить | Правка | Наверх | Cообщить модератору

45. Скрыто модератором	+1 +/–
Сообщение от Аноним (43), 14-Апр-26, 17:55
Для повышения безопасности нужно больше памяти, мой лорд.
Ответить | Правка | Наверх | Cообщить модератору

46. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
Сообщение от Аноним (43), 14-Апр-26, 18:00
Нужно больше ОЗУ, милорд.
Ответить | Правка | Наверх | Cообщить модератору

	51. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+1 +/–
	Сообщение от Аноним (49), 14-Апр-26, 18:25
	>  Нужно больше ОЗУ, милорд. Больше ОЗУ для чего? Чтобы в трех нужных местах сделать ххх->next_in = NULL; ?
	Ответить | Правка | Наверх | Cообщить модератору

52. "Уязвимость в Python-библиотеках lzma, bz2 и gzip, потенциаль..."	+/–
Сообщение от Аноним (52), 14-Апр-26, 18:42
Прям хоть рекламный слоган делай: "Си! Добавляем дыры даже в безопасны Питон!" Не даром говорят "C in CVE stands for C language".
Ответить | Правка | Наверх | Cообщить модератору

71. Скрыто модератором	+/–
Сообщение от Аноним (-), 15-Апр-26, 01:39
лутший линопс
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема