Открою Вам маленький секрет - не все, что имеет свою CVE, по настоящему считается уязвимостью.
Если не верите, подумайте о CVE, которая говорит о том, что контекст запроса PostgreSQL вида `copy * from <command>` - это уязвимость.
Плюс ко всему, я навел справки. К примеру - в документации к RabbitMQ говорится о том, что `erlang cookie` генерируется случайным образом. В документации к продукту, о котором говорится в статье, об этом ни слова.
В общем - непонятно к чему написана статья. Интересного чейна тут нет, это самая базовая "недоcve", которая не должна быть принята в качестве серьезной уязвимости, ИМХО.
А если и должна - welcome регистрировать подобное поведение в остальных продуктах. К примеру в Zabbix, RabbitMQ, Grafana. Только вот проблема заключается в том, что ни 1 адекватный вендор не скажет вам, что это уязвимость, так как уязвимость, в первую очередь - это нестандартное поведение, баг или существенная, недокументированная недоработка. Тут же - все документировано.
С таким же успехом можно начать конфигурировать кластер k8s без использования лучших практик и потом жаловаться и кидать репорты о том, что инфраструктуру разнесли и все секреты вычитали.
Команда безопасности CouchDB обещала исправить инсталлер в будущих релизах, не особо заботясь о текущих инсталляциях.
Это не проблема "инсталлера" как Вы сказали, это проблема, связанная с тем, что многие не столь внимательно знакомятся с документацией, в которой, как Вы сказали, подсвечена WARNING'ом (!!) Информация о том, как этот кластер защищен.
Т.е сказать что это реальная критическая уязвимость - это тоже самое, что и сказать о том, что дефолтные креды к тому же заббиксу - ужасное упущение.
Только вот, повторюсь - нужно внимательно читать документацию перед эксплуатацией продуктов, особенно тех, что используют под капотом целый кластер.
Реальная проблема в том, что за 1 запуск программы, используя нативную библиотеку, нельзя взять и получить значения всех подпарсеров. На Stack эта проблема всплывала и раньше, но ее никто не решал. Поэтому - можно рекурсивно скармливать методу parse_known_args оставшиеся аргументы или решить проблему в корне
А нужно мне это для следующего:
Представим ситуацию, в которой каждый может добавлять "плагины" в программу. Каждый плагин может использовать парсинг аргументов, но при этом есть необходимость контролировать подобные действия. Это и вправду специфика бэкенда, как Вы и сказали, но в этом то и суть. Не решается глобальная проблема, но решается локальная и рассматривается, хоть и не во всех красках, что происходит за кулисами в этой либе.
Открою Вам маленький секрет - не все, что имеет свою CVE, по настоящему считается уязвимостью.
Если не верите, подумайте о CVE, которая говорит о том, что контекст запроса PostgreSQL вида `copy * from <command>` - это уязвимость.
Плюс ко всему, я навел справки. К примеру - в документации к RabbitMQ говорится о том, что `erlang cookie` генерируется случайным образом. В документации к продукту, о котором говорится в статье, об этом ни слова.
В общем - непонятно к чему написана статья. Интересного чейна тут нет, это самая базовая "недоcve", которая не должна быть принята в качестве серьезной уязвимости, ИМХО.
А если и должна - welcome регистрировать подобное поведение в остальных продуктах. К примеру в Zabbix, RabbitMQ, Grafana. Только вот проблема заключается в том, что ни 1 адекватный вендор не скажет вам, что это уязвимость, так как уязвимость, в первую очередь - это нестандартное поведение, баг или существенная, недокументированная недоработка. Тут же - все документировано.
С таким же успехом можно начать конфигурировать кластер k8s без использования лучших практик и потом жаловаться и кидать репорты о том, что инфраструктуру разнесли и все секреты вычитали.
Это не проблема "инсталлера" как Вы сказали, это проблема, связанная с тем, что многие не столь внимательно знакомятся с документацией, в которой, как Вы сказали, подсвечена WARNING'ом (!!) Информация о том, как этот кластер защищен.
Т.е сказать что это реальная критическая уязвимость - это тоже самое, что и сказать о том, что дефолтные креды к тому же заббиксу - ужасное упущение.
Только вот, повторюсь - нужно внимательно читать документацию перед эксплуатацией продуктов, особенно тех, что используют под капотом целый кластер.
Реальная проблема в том, что за 1 запуск программы, используя нативную библиотеку, нельзя взять и получить значения всех подпарсеров. На Stack эта проблема всплывала и раньше, но ее никто не решал. Поэтому - можно рекурсивно скармливать методу parse_known_args оставшиеся аргументы или решить проблему в корне
А нужно мне это для следующего:
Представим ситуацию, в которой каждый может добавлять "плагины" в программу. Каждый плагин может использовать парсинг аргументов, но при этом есть необходимость контролировать подобные действия. Это и вправду специфика бэкенда, как Вы и сказали, но в этом то и суть. Не решается глобальная проблема, но решается локальная и рассматривается, хоть и не во всех красках, что происходит за кулисами в этой либе.