jfrog / jfrog-cli-core

Apache License 2.0
32 stars 55 forks source link

[🐸 Frogbot] Update version of golang.org/x/net to 0.23.0 #1175

Closed github-actions[bot] closed 2 months ago

github-actions[bot] commented 3 months ago
[![🚨 This automated pull request was created by Frogbot and fixes the below:](https://raw.githubusercontent.com/jfrog/frogbot/master/resources/v2/vulnerabilitiesFixBannerPR.png)](https://docs.jfrog-applications.jfrog.io/jfrog-applications/frogbot)

📦 Vulnerable Dependencies

✍️ Summary

| SEVERITY | DIRECT DEPENDENCIES | IMPACTED DEPENDENCY | FIXED VERSIONS | CVES | | :---------------------: | :-----------------------------------: | :-----------------------------------: | :-----------------------------------: | :-----------------------------------: | | ![](https://raw.githubusercontent.com/jfrog/frogbot/master/resources/v2/applicableMediumSeverity.png)
Medium | github.com/jfrog/jfrog-client-go:v1.40.1
golang.org/x/net:v0.22.0 | golang.org/x/net v0.22.0 | [0.23.0] | CVE-2023-45288 |

🔬 Research Details

Description: The net/http package in Go is used for handling HTTP requests and responses. HTTP/2 is a binary protocol where the client and server exchange binary frames instead of text lines as in HTTP/1.x. HTTP/2 resolves numerous concerns found in HTTP/1.1 by organizing each HTTP message into a series of HTTP/2 frames. These frames include frame type, length, flags, stream identifier (ID), and payload.

The HEADERS frame type allows sending HTTP headers of, both, request and response. The HEADERS frame contains many flags. The CONTINUATION frame type is similar to the HEADER frame, but it has just one flag: END_HEADERS. When it is not set, the peer knows that more headers are coming in the following CONTINUATION frames.

This mechanism allows an attacker to send an HTTP/2 stream with CONTINUATION frames, without setting the END_HEADERS flag in any of the frames. This can cause denial-of-service when sending an excessive number of these crafted frames due to caching all frames in memory.

Though the net/http package uses HTTP/2 by default, a Golang web server must have HTTPS configured to be vulnerable to exploitation. The x/net/http2 package is vulnerable by default.

Remediation:

Development mitigations

From Golang version 1.6, the net/http package is using the HTTP/2 protocol by default when using HTTPS. You can disable HTTP/2 by setting Server.TLSNextProto (for servers) to a non-nil, empty map.

For example:

package main

import (
    "log"
    "net/http"
    "crypto/tls"
)

func main() {
    m := http.NewServeMux()
    srv := &http.Server{
        Handler:      m,
        Addr:         "127.0.0.1:8080",
        TLSNextProto: make(map[string]func(*http.Server, *tls.Conn, http.Handler)),
    }
    log.Fatal(srv.ListenAndServe())
}

Alternatively, the following GODEBUG settings are also supported, which disables the HTTP/2 server support:

GODEBUG=http2server=0

[🐸 JFrog Frogbot](https://docs.jfrog-applications.jfrog.io/jfrog-applications/frogbot)