Skip to content

Denial of service of Minder Server with attacker-controlled REST endpoint

Moderate
JAORMX published GHSA-fjw8-3gp8-4cvx May 16, 2024

Package

No package listed

Affected versions

< 0.20240515.2124_ref.f1e2219

Patched versions

0.20240516.2125_ref.0650493

Description

The Minder REST ingester is vulnerable to a denial of service attack via an attacker-controlled REST endpoint that can crash the Minder server.

The REST ingester allows users to interact with REST endpoints to fetch data for rule evaluation. When fetching data with the REST ingester, Minder sends a request to an endpoint and will use the data from the body of the response as the data to evaluate against a certain rule. Minder sends the request on these lines:

req, err := rdi.cli.NewRequest(rdi.method, endpoint.String(), bodyr)
if err != nil {
return nil, fmt.Errorf("cannot create request: %w", err)
}
respRdr, err := rdi.doRequest(ctx, req)
if err != nil {
return nil, fmt.Errorf("cannot do request: %w", err)
}

… and parses the response body on these lines:

data, err := rdi.parseBody(respRdr)
if err != nil {
return nil, fmt.Errorf("cannot parse body: %w", err)
}

func (rdi *Ingestor) parseBody(body io.Reader) (any, error) {
var data any
var err error
if body == nil {
return nil, nil
}
if rdi.restCfg.Parse == "json" {
var jsonData any
dec := json.NewDecoder(body)
if err := dec.Decode(&jsonData); err != nil {
return nil, fmt.Errorf("cannot decode json: %w", err)
}
data = jsonData
} else {
data, err = io.ReadAll(body)
if err != nil {
return nil, fmt.Errorf("cannot read response body: %w", err)
}
}
return data, nil
}

Minder creates the URL of the endpoint via templating on these lines:

if err := rdi.endpointTemplate.Execute(endpoint, retp); err != nil {
return nil, fmt.Errorf("cannot execute endpoint template: %w", err)
}

As far as I can tell, at this stage in rule evaluation, users fully control the raw template and the params passed to the template via the RuleType type:

type RestType struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
// endpoint is the endpoint to fetch data from.
// This can be a URL or the path on the API.bool
// This is a required field and must be set.
// This is also evaluated via a template which allows
// us dynamically fill in the values.
Endpoint string `protobuf:"bytes,1,opt,name=endpoint,proto3" json:"endpoint,omitempty"`
// method is the method to use to fetch data.
Method string `protobuf:"bytes,2,opt,name=method,proto3" json:"method,omitempty"`
// headers are the headers to be sent to the endpoint.
Headers []string `protobuf:"bytes,3,rep,name=headers,proto3" json:"headers,omitempty"`
// body is the body to be sent to the endpoint.
Body *string `protobuf:"bytes,4,opt,name=body,proto3,oneof" json:"body,omitempty"`
// parse is the parsing mechanism to be used to parse the data.
Parse string `protobuf:"bytes,5,opt,name=parse,proto3" json:"parse,omitempty"`
// fallback provides a body that the ingester would return in case
// the REST call returns a non-200 status code.
Fallback []*RestType_Fallback `protobuf:"bytes,6,rep,name=fallback,proto3" json:"fallback,omitempty"`
}

I have not seen anything that enforces users to only send requests to GitHub REST endpoints. If there is such a constraint, it limits the ease with which this vulnerability can be exploited, but it is still possible. If there is not such a constraint, it is easy to exploit this vuln.

When Minder parses the response from a remote endpoint, it reads the response entirely into memory on these lines:

if err := dec.Decode(&jsonData); err != nil {

and

data, err = io.ReadAll(body)

If the response is sufficiently large, it can drain memory on the machine and crash the Minder server.

The attacker can control the remote REST endpoints that Minder sends requests to, and they can configure the remote REST endpoints to return responses with large bodies. They would then instruct Minder to send a request to their configured endpoint that would return the large response which would crash the Minder server.

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H

CVE ID

CVE-2024-35185

Weaknesses

No CWEs

Credits