Golang-1.13
Уязвимости
89
Эксплуатируемые
0
Макс. CVSS
9.8
Макс. EPSS
0.91969
Распределение по критичности
Критический
4
Высокий
44
Средний
39
Низкий
2
Также сопоставлено как (исходные строки): golang-1.13
Топ уязвимостей
CVE-2023-24538Шаблоны неправильно рассматривают обратные апострофы (`) как разделители строк в JavaScript и не экранируют их должным образом. Обратные апострофы используются с ES6 для шаблонных литералов JS. Если шаблон содержит действие шаблона Go внутри шаблонного литерала JavaScript, то содержимое действия может быть использовано для завершения литерала, внедряя произвольный код JavaScript в шаблон Go. Поскольку шаблонные литералы ES6 довольно сложны и могут выполнять интерполяцию строк, было принято решение просто запретить действия шаблона Go внутри них (например, "var a = {{.}}"), поскольку нет очевидно безопасного способа позволить такое поведение. Это принимает тот же подход, что и github.com/google/safehtml. С исправлением Template.Parse возвращает ошибку, когда встречает такие шаблоны, с кодом ошибки 12. Этот код ошибки в настоящее время не экспортируется, но будет экспортирован в версии Go 1.21. Пользователи, полагающиеся на предыдущее поведение, могут повторно включить его, используя флаг GODEBUG jstmpllitinterp=1, с оговоркой, что обратные апострофы теперь будут экранированы. Это следует использовать с осторожностью.
CVE-2023-24531Команда go env документирована как выводящая сценарий оболочки, содержащий среду Go. Однако go env не очищает значения, поэтому выполнение его вывода в качестве сценария оболочки может вызвать различное плохое поведение, включая выполнение произвольных команд или вставку новых переменных среды. Эта проблема относительно незначительна, поскольку, как правило, если злоумышленник может установить произвольные переменные среды в системе, у него есть более эффективные векторы атаки, чем заставлять "go env" выводить их.
CVE-2021-38297Go до 1.16.9 и 1.17.x до 1.17.2 имеет переполнение буфера из-за больших аргументов при вызове функции из модуля WASM, когда используется GOARCH=wasm GOOS=js.
CVE-2012-2666golang/go в версии 1.0.2 исправляет all.bash на общих машинах. dotest() в src/pkg/debug/gosym/pclntab_test.go создает временный файл с предсказуемым именем и выполняет его как shell-скрипт.
CVE-2024-45340Учетные данные, предоставленные через новую функцию GOAUTH, неправильно сегментировались по домену, что позволяло вредоносному серверу запрашивать учетные данные, к которым у него не должно быть доступа. По умолчанию, если не установлено иное, это затрагивало только учетные данные, хранящиеся в файле .netrc пользователей.
CVE-2023-39320Директива инструментария go.mod, введенная в Go 1.21, может быть использована для выполнения скриптов и бинарных файлов относительно корня модуля, когда команда "go" была выполнена в пределах модуля. Это относится как к модулям, загруженным с помощью команды "go" из прокси модуля, так и к модулям, загруженным непосредственно с помощью программного обеспечения VCS.
CVE-2023-29403На платформах Unix среда выполнения Go не ведет себя иначе, когда бинарный файл запускается с установленными битами setuid/setgid. Это может быть опасно в определенных случаях, например, при дампе состояния памяти или при предположении статуса стандартных файловых дескрипторов ввода-вывода. Если бинарный файл setuid/setgid выполняется с закрытыми стандартными дескрипторами ввода-вывода, открытие любых файлов может привести к неожиданному содержимому, которое будет прочитано или записано с повышенными привилегиями. Аналогично, если программа setuid/setgid завершает работу, либо через панику, либо через сигнал, она может утечет содержимое своих регистров.
CVE-2025-22865Использование ParsePKCS1PrivateKey для анализа RSA-ключа, в котором отсутствуют значения CRT, вызовет панику при проверке правильности сформированного ключа.
CVE-2024-34156Вызов Decoder.Decode для сообщения, содержащего глубоко вложенные структуры, может вызвать панику из-за исчерпания стека. Это является продолжением CVE-2022-30635.
CVE-2024-24789Обработка пакетом archive/zip некоторых типов недопустимых zip-файлов отличается от поведения большинства реализаций zip. Это несовпадение может быть использовано для создания zip-файла, содержимое которого варьируется в зависимости от реализации, читающей файл. Пакет archive/zip теперь отвергает файлы, содержащие эти ошибки.
CVE-2024-24788Неправильное сообщение DNS в ответ на запрос может заставить функции Lookup застрять в бесконечном цикле.
CVE-2023-45288Злоумышленник может заставить конечную точку HTTP/2 прочитать произвольные объемы заголовков, отправив чрезмерное количество кадров CONTINUATION. Поддержание состояния HPACK требует анализа и обработки всех заголовков HEADERS и CONTINUATION в соединении. Когда заголовки запроса превышают MaxHeaderBytes, память не выделяется для хранения избыточных заголовков, но они по-прежнему анализируются. Это позволяет злоумышленнику заставить конечную точку HTTP/2 прочитать произвольные объемы заголовков, все связанные с запросом, который будет отклонен. Эти заголовки могут включать закодированные данные Хаффмана, которые значительно сложнее для получателя декодировать, чем для злоумышленника отправить. Исправление устанавливает предел на количество избыточных заголовков, которые мы будем обрабатывать, прежде чем закрыть соединение.
CVE-2023-45283Пакет filepath не распознает пути с префиксом \??\ как специальные. В Windows путь, начинающийся с \??\, является корневым локальным устройством, эквивалентным пути, начинающемуся с \\?. Пути с префиксом \??\ могут использоваться для доступа к произвольным местоположениям на системе. Например, путь \??\c:\ эквивалентен более привычному пути c:\x. До исправления Clean мог преобразовать корневой путь, такой как \a\..\??\b, в корневой локальный путь \??\b. Теперь Clean преобразует это в .\??\b. Аналогично, Join(\, ??, b) мог преобразовать на вид неприметную последовательность элементов пути в корневой локальный путь \??\b. Теперь Join преобразует это в \.\??\b. В дополнение к исправлению, с исправлением IsAbs теперь правильно сообщает, что пути, начинающиеся с \??\, являются абсолютными, а VolumeName правильно сообщает префикс \??\ как имя тома. ОБНОВЛЕНИЕ: Go 1.20.11 и Go 1.21.4 непреднамеренно изменили определение имени тома в Windows путях, начинающихся с \?, в результате чего filepath.Clean(\?\c:) возвращает \?\c: вместо \?\c:\ (среди прочих эффектов). Предыдущее поведение было восстановлено.
CVE-2023-39325Злонамеренный клиент HTTP/2, который быстро создаёт запросы и сразу же сбрасывает их, может вызвать чрезмерное потребление ресурсов сервера. Хотя общее количество запросов ограничено настройкой http2.Server.MaxConcurrentStreams, сброс текущего запроса позволяет злоумышленнику создать новый запрос, пока существующий все еще выполняется. С применением исправления сервера HTTP/2 теперь ограничивают количество одновременно выполняемых обработчиков goroutines в соответствии с ограничением конкуренции потоков (MaxConcurrentStreams). Новые запросы, приходящие на пределе (что может произойти только после сброса клиентом существующего запроса), будут помещены в очередь до выхода обработчика. Если очередь запросов вырастет слишком большой, сервер завершит соединение. Эта проблема также исправлена в golang.org/x/net/http2 для пользователей, вручную настраивающих HTTP/2. Стандартный лимит конкуренции потоков составляет 250 потоков (запросов) на одно соединение HTTP/2. Это значение может быть настроено с помощью пакета golang.org/x/net/http2; смотрите настройку Server.MaxConcurrentStreams и функцию ConfigureServer.
CVE-2023-39322Соединения QUIC не устанавливают верхнюю границу на объем данных, буферизуемых при чтении сообщений после установки соединения, что позволяет злонамеренному соединению QUIC вызвать неконтролируемый рост памяти. С поправкой соединения теперь последовательно отклоняют сообщения больше 65KiB.
CVE-2023-39321Обработка неп полного сообщения после установки соединения QUIC может привести к панике.
CVE-2023-29405Команда go может выполнять произвольный код во время сборки при использовании cgo. Это может произойти при запуске "go get" для вредоносного модуля или при запуске любой другой команды, которая создает ненадежный код. Это может быть вызвано флагами компоновщика, указанными через директиву "#cgo LDFLAGS". Флаги, содержащие встроенные пробелы, обрабатываются неправильно, что позволяет проносить запрещенные флаги через очистку LDFLAGS, включая их в аргумент другого флага. Это влияет только на использование компилятора gccgo.
CVE-2023-29404Команда go может выполнять произвольный код во время сборки при использовании cgo. Это может произойти при запуске "go get" для вредоносного модуля или при запуске любой другой команды, которая создает ненадежный код. Это может быть вызвано флагами компоновщика, указанными через директиву "#cgo LDFLAGS". Аргументы для ряда флагов, которые не являются необязательными, ошибочно считаются необязательными, что позволяет проносить запрещенные флаги через очистку LDFLAGS. Это влияет на использование как компиляторов gc, так и gccgo.
CVE-2023-24537Вызов любой из функций Parse на исходном коде Go, который содержит директивы //line с очень большими номерами строк, может вызвать бесконечный цикл из-за переполнения целого числа.
CVE-2023-24536Парсинг форм многокомпонентного типа может потреблять большие объемы ЦП и памяти при обработке входных данных форм, содержащих очень большое количество частей. Это вызвано несколькими факторами: 1. mime/multipart.Reader.ReadForm ограничивает общее количество памяти, которое может потреблять разобранная многокомпонентная форма. ReadForm может недооценить количество потребляемой памяти, что ведет к тому, что он принимает большие входные данные, чем предполагалось. 2. Ограничение общего объема памяти не учитывает увеличенное давление на сборщик мусора от большого количества небольших аллокаций в формах с множеством частей. 3. ReadForm может выделять большое количество краткоживущих буферов, что дополнительно увеличивает давление на сборщик мусора. Сочетание этих факторов может позволить злоумышленнику заставить программу, парсирующую многокомпонентные формы, потреблять большое количество ЦП и памяти, потенциально приводя к отказу в обслуживании. Это затрагивает программы, использующие mime/multipart.Reader.ReadForm, а также парсинг форм в пакете net/http с методами Request FormFile, FormValue, ParseMultipartForm и PostFormValue. С исправлением ReadForm теперь лучше оценивает потребление памяти разобранных форм и выполняет значительно меньше короткоживущих аллокаций. Кроме того, исправленный mime/multipart.Reader накладывает следующие ограничения на размер разобранных форм: 1. Формы, разобранные с ReadForm, могут содержать не более 1000 частей. Это ограничение можно настроить с переменной окружения GODEBUG=multipartmaxparts=. 2. Части формы, разобранные с помощью NextPart и NextRawPart, могут содержать не более 10 000 заголовков. Кроме того, формы, разобранные с ReadForm, могут содержать не более 10 000 заголовков по всем частям. Это ограничение может быть настроено с помощью переменной окружения GODEBUG=multipartmaxheaders=.
CVE-2023-24534Парсинг HTTP и MIME-заголовков может потреблять большие объемы памяти, даже при разборе небольших входных данных, потенциально ведущих к отказу в обслуживании. Определенные необычные паттерны входных данных могут привести к тому, что общая функция, используемая для разбора HTTP и MIME-заголовков, выделяет значительно больше памяти, чем необходимо для хранения разобранных заголовков. Злоумышленник может использовать это поведение, чтобы заставить HTTP-сервер выделять большие объемы памяти из небольшого запроса, потенциально приводя к исчерпанию памяти и отказу в обслуживании. С исправлением, парсинг заголовков теперь правильно выделяет только память, необходимую для хранения разобранных заголовков.
CVE-2022-41725Возможен отказ в обслуживании из-за чрезмерного потребления ресурсов в net/http и mime/multipart. Парсинг многочастной формы с mime/multipart.Reader.ReadForm может потреблять практически неограниченные объёмы памяти и дисковых файлов. Это также затрагивает парсинг форм в пакете net/http с методами Request FormFile, FormValue, ParseMultipartForm и PostFormValue. ReadForm принимает параметр maxMemory и документирован как хранящий "до maxMemory байт +10 МБ (зарезервировано для не файловых частей) в памяти". Части файлов, которые не могут быть сохранены в памяти, сохраняются на диске во временных файлах. Неподдающаяся настройке 10 МБ, зарезервированных для не файловых частей, является чрезмерно большой и потенциально может открыть вектор отказа в обслуживании. Однако ReadForm не учитывал все ресурсы памяти, потребляемые парсенной формой, такие как накладные расходы на записи карты, имена частей и заголовки MIME, что позволяло злонамеренно созданной форме потреблять значительно более 10 МБ. В дополнение, ReadForm не содержал ограничения на количество создаваемых дисковых файлов, позволяя относительно небольшому телу запроса создать большое количество временных файлов на диске. После исправления ReadForm теперь правильно учитывает различные формы накладных расходов памяти и теперь должен оставаться в рамках своей документированной границы 10 МБ + объём памяти maxMemory. Пользователи всё равно должны быть осторожны, что это ограничение высоко и по-прежнему может быть опасным. Кроме того, ReadForm теперь создает не более одного временного файла на диске, объединяя несколько частей форм в один временный файл. Документация интерфейса типа mime/multipart.File указывает: "Если сохранён на диске, базовый конкретный тип файла будет *os.File.". Это больше не так, когда форма содержит более одной части файла, из-за этого объединения частей в один файл. Предыдущее поведение использования разных файлов для каждой части формы может быть повторно включено с помощью переменной среды GODEBUG=multipartfiles=distinct. Пользователи должны знать, что multipart.ReadForm и методы http.Request, которые его вызывают, не ограничивают объём дискового пространства, используемого временными файлами. Вызывающие функции могут ограничить размер данных формы с помощью http.MaxBytesReader.
CVE-2022-41724Большие записи рукопожатий могут вызвать паники в crypto/tls. И клиенты, и серверы могут отправлять большие записи рукопожатий TLS, которые вызывают панику серверов и клиентов соответственно при попытке сформировать ответы. Это затрагивает всех клиентов TLS 1.3, клиентов TLS 1.2, которые явно включают восстановление сеансов (путем установки Config.ClientSessionCache в ненулевое значение), и сервера TLS 1.3, которые запрашивают клиентские сертификаты (путем установки Config.ClientAuth >= RequestClientCert).
CVE-2022-41723Злоумышленно созданный поток HTTP/2 может вызвать чрезмерное потребление ЦП в декодере HPACK, достаточное для вызова отказа в обслуживании от небольшого количества мелких запросов.
CVE-2022-41720В Windows доступ к ограниченным файлам можно получить через os.DirFS и http.Dir. Функция os.DirFS и тип http.Dir предоставляют доступ к дереву файлов, расположенных в заданном каталоге. Эти функции разрешают доступ к файлам устройств Windows под этим корнем. Например, os.DirFS("C:/tmp").Open("COM1") открывает устройство COM1. И os.DirFS, и http.Dir предоставляют только доступ к файловой системе только для чтения. Кроме того, в Windows os.DirFS для каталога (корня текущего диска) может позволить злонамеренно созданному пути выйти за пределы диска и получить доступ к любому пути в системе. После применения исправления поведение os.DirFS("") изменилось. Ранее пустой корень обрабатывался эквивалентно "/", поэтому os.DirFS("").Open("tmp") открывал путь "/tmp". Теперь это возвращает ошибку.