Обнаружена уязвимость в интерактивном терминале psql PostgreSQL версий до 13.1, до 12.5, до 11.10, до 10.15, до 9.6.20 и до 9.5.24. Если ин…
Обнаружена уязвимость в интерактивном терминале psql PostgreSQL версий до 13.1, до 12.5, до 11.10, до 10.15, до 9.6.20 и до 9.5.24. Если интерактивный сеанс psql использует \gset при запросе к скомпрометированному серверу, злоумышленник может выполнить произвольный код в качестве учетной записи операционной системы, запускающей psql. Наибольшую угрозу от этой уязвимости представляет конфиденциальность и целостность данных, а также доступность системы.
Продукт реализует механизм защиты, опирающийся на список входных данных (или свойств входных данных), которые явно разрешены политикой как предположительно безопасные, однако этот список слишком разрешителен — то есть допускает небезопасные входные данные, что порождает производные слабости.
https://cwe.mitre.org/data/definitions/183.html →Открыть в коллекции CWE →Некоторые API удаляют определённые ведущие символы из строки параметров. Злоумышленник может намеренно вставлять ведущие «фантомные» символы (дополнительные символы, не влияющие на корректность запроса на уровне API), которые позволяют входным данным пройти фильтры и тем самым обрабатываются API целевого ресурса. Это происходит, когда целевой API принимает входные данные в нескольких синтаксических формах и интерпретирует их семантически одинаково, тогда как фильтр не учитывает полный спектр синтаксических форм, допустимых для целевого API.
https://capec.mitre.org/data/definitions/3.html →Открыть в коллекции CAPEC →Злоумышленник передаёт целевому программному обеспечению входные данные, содержащие последовательности специальных символов, предназначенные для обхода логики проверки входных данных. Атака основана на том, что целевая система выполняет несколько проходов по входным данным, обрабатывая «слой» специальных символов на каждом проходе. Таким образом злоумышленник может замаскировать входные данные, которые в противном случае были бы отклонены как недопустимые, скрыв их за слоями специальных символов и экранирующих последовательностей, удаляемых последующими этапами обработки. Цель состоит в том, чтобы сначала обнаружить случаи, когда уровень проверки входных данных выполняется до одного или нескольких уровней синтаксического анализа. То есть пользовательский ввод может проходить через следующую логику приложения: <parser1> --> <input validator> --> <parser2>. В таких случаях злоумышленнику необходимо предоставить входные данные, которые пройдут через валидатор входных данных, но после прохождения через parser2 будут преобразованы в нечто, что валидатор должен был заблокировать.
https://capec.mitre.org/data/definitions/43.html →Открыть в коллекции CAPEC →Злоумышленник может передавать Unicode-строку компоненту системы, не поддерживающему Unicode, и использовать её для обхода фильтра или сбоя классифицирующего механизма при правильной интерпретации запроса. Это может позволить злоумышленнику передать вредоносные данные через фильтр содержимого и/или вызвать некорректную маршрутизацию запроса приложением.
https://capec.mitre.org/data/definitions/71.html →Открыть в коллекции CAPEC →Злоумышленник применяет повторяющееся кодирование набора символов (то есть кодирует символ, уже закодированный с использованием кодировки символов) для обфускации полезной нагрузки конкретного запроса. Это может позволить злоумышленнику обойти фильтры, пытающиеся обнаружить недопустимые символы или строки, — в частности, те, которые могут использоваться в атаках выхода за пределы каталога или внедрения. Фильтры могут перехватывать закодированные недопустимые строки, но не способны перехватить дважды закодированные строки. Например, точка (.), часто используемая в атаках выхода за пределы каталога и потому нередко блокируемая фильтрами, может быть URL-закодирована как %2E. Однако многие фильтры распознают данное кодирование и всё равно заблокируют запрос. При двойном кодировании знак % в приведённом URL-кодировании снова кодируется как %25, что даёт %252E — строку, которую некоторые фильтры не распознают, однако интерпретаторы на целевой стороне по-прежнему могут трактовать как точку (.).
https://capec.mitre.org/data/definitions/120.html →Открыть в коллекции CAPEC →| Продукт | Вендор | Статус |
|---|---|---|
| libpq | Отслеживается | |
| libpq | Отслеживается | |
| libpq | Отслеживается | |
| libpq | Отслеживается | |
| postgresql | Отслеживается | |
| postgresql | Отслеживается | |
| postgresql | Отслеживается | |
| postgresql | Отслеживается | |
| postgresql | Отслеживается | |
| postgresql | Отслеживается | |
| postgresql | Отслеживается | |
| postgresql | Отслеживается | |
| postgresql | Отслеживается | |
| postgresql | Отслеживается | |
| postgresql-10 | Отслеживается | |
| postgresql-11 | Отслеживается | |
| postgresql-11 | Отслеживается | |
| postgresql-11 | Отслеживается | |
| postgresql-12 | Отслеживается | |
| postgresql-12 | Отслеживается |