Skip to content
This repository has been archived by the owner on Jan 5, 2023. It is now read-only.

CWE-117 False positive #635

Closed
theAntiYeti opened this issue Dec 13, 2021 · 12 comments
Closed

CWE-117 False positive #635

theAntiYeti opened this issue Dec 13, 2021 · 12 comments

Comments

@theAntiYeti
Copy link

CWE-117: Improper Output Neutralization for Logs
CWE-117 is being reported by CodeQL in the following code:

func makeErrorForHTTPResponse(resp *http.Response) error {
	bodyBytes, err := ioutil.ReadAll(resp.Body)
	if err != nil {
		return err
	}
	url := resp.Request.URL.String()
	safeURL := strings.Replace(url, "\n", "", -1)
	safeURL = strings.Replace(safeURL, "\r", "", -1)
	return fmt.Errorf("%s %s returned HTTP %s; \n\n %#q", resp.Request.Method, safeURL, resp.Status, bodyBytes)
}

Despite this code being near identical to the provided "good" example

func handlerGood(req *http.Request) {
	username := req.URL.Query()["username"][0]
	escapedUsername := strings.Replace(username, "\n", "", -1)
	escapedUsername = strings.Replace(escapedUsername, "\r", "", -1)
	log.Printf("user %s logged in.\n", escapedUsername)
}

here.

Here is a screen shot of the output logs for further clarification
Screenshot from 2021-12-13 18-14-19

It appears that CodeQL completely ignores the above two functions performing the string replacement.

@hmakholm
Copy link
Contributor

Thanks for the report; I agree this looks weird. If this is happening on a public repository, can you share a link to the repo and the analysis result?

@theAntiYeti
Copy link
Author

Hi @hmakholm, I have been trying some things in the meantime but I have now reset to the commit I submitted this false positive under.
The branch.
CodeQL analysis result.

@trdyer
Copy link

trdyer commented Dec 13, 2021

I have also been seeing this, but in a private repository.

In my case it appears that the lines I have fixed are being added as a "fixed" item, but an equivalent item is being created.

@smowton
Copy link
Contributor

smowton commented Dec 14, 2021

Thanks for the heads-up; fixed in #637

@llhuii
Copy link

llhuii commented Dec 16, 2021

Can we handle the case below?

nodeName := req.Header.Get("Node-Name")

err := validateNodeName(nodeName)
if err != nil {
           return err
}
log.Printf("%s has been connected", nodeName)

here: https://github.com/llhuii/sedna/security/code-scanning/10?query=ref%3Arefs%2Fheads%2Fmain

@smowton
Copy link
Contributor

smowton commented Dec 16, 2021

looks like it's actually

	rawNodeName := req.Header.Get("Node-Name")

	nodeName, err := validateNodeName(rawNodeName)

So yes that ought to be noticed by the sanitizer written in the PR above.

If it was a sanitizer guard as you've written it in your comment we'd need to do a bit more.

@smowton
Copy link
Contributor

smowton commented Dec 16, 2021

Fix committed; will be reflected on code scanning at the next distribution upgrade, which will likely go live mid-January

@smowton smowton closed this as completed Dec 16, 2021
@llhuii
Copy link

llhuii commented Dec 17, 2021

If it was a sanitizer guard as you've written it in your comment we'd need to do a bit more.

I would prefer this sanitizer guard rather over reassignment nodeName, err := validateNodeName(rawNodeName).

Reassignment would be weird since it has already been checked.

@smowton
Copy link
Contributor

smowton commented Dec 17, 2021

So replacing and then comparing is a weird sanitizer guard, since you've done the work and may as well just use the replaced string. I'd be happy to make read-only string-searching operations sanitizer guards though.

@olix0r
Copy link

olix0r commented Jan 22, 2022

olix0r added a commit to linkerd/linkerd2 that referenced this issue Jan 22, 2022
CodeQL has caught several instances where we may be susceptible to [log
forgery][cql].

This change ensures that we strip newlines from log messages that
include potentially user-supplied strings. Several redundant error logs
are removed--we should generally not log an error when returning an
error. Errors should be logged where they are handled.

This change also properly escapes URL paths when constructing them from
protobuf messages.

Note that CodeQL continued to mark some of these uses as issues, but
we've marked them as false-positive. See github/codeql-go#635 and
github/codeql-go#650.

[cql]: https://codeql.github.com/codeql-query-help/go/go-log-injection/

Signed-off-by: Oliver Gould <ver@buoyant.io>
olix0r added a commit to linkerd/linkerd2 that referenced this issue Jan 22, 2022
CodeQL has caught several instances where we may be susceptible to [log
forgery][cql].

This change ensures that we strip newlines from log messages that
include potentially user-supplied strings. Several redundant error logs
are removed--we should generally not log an error when returning an
error. Errors should be logged where they are handled.

This change also properly escapes URL paths when constructing them from
protobuf messages.

Note that CodeQL continued to mark some of these uses as issues, but
we've marked them as false-positive. See github/codeql-go#635 and
github/codeql-go#650.

[cql]: https://codeql.github.com/codeql-query-help/go/go-log-injection/

Signed-off-by: Oliver Gould <ver@buoyant.io>
adleong pushed a commit to linkerd/linkerd2 that referenced this issue Jan 24, 2022
CodeQL has caught several instances where we may be susceptible to [log
forgery][cql].

This change ensures that we strip newlines from log messages that
include potentially user-supplied strings. Several redundant error logs
are removed--we should generally not log an error when returning an
error. Errors should be logged where they are handled.

This change also properly escapes URL paths when constructing them from
protobuf messages.

Note that CodeQL continued to mark some of these uses as issues, but
we've marked them as false-positive. See github/codeql-go#635 and
github/codeql-go#650.

[cql]: https://codeql.github.com/codeql-query-help/go/go-log-injection/

Signed-off-by: Oliver Gould <ver@buoyant.io>
@owen-mc
Copy link
Contributor

owen-mc commented Jan 26, 2022

@olix0r When I look at the codescanning results for that PR it's saying that 7 alerts were fixed, including the one from your screenshot. I'm not sure if things got sorted out after a delay or if the place where you took the screenshot just didn't make it very clear that it was showing a fixed alert.

@olix0r
Copy link

olix0r commented Jan 26, 2022

@owen-mc Thanks, it's possible I was confused by the UI--I thought that was indicating that some issues were fixed and others were still active. As I recall, the workflow did not succeed until all of those issues were acknowledged.

In any case, we're no longer impacted by this :)

olix0r added a commit to linkerd/linkerd2 that referenced this issue Apr 14, 2022
CodeQL has caught several instances where we may be susceptible to [log
forgery][cql].

This change ensures that we strip newlines from log messages that
include potentially user-supplied strings. Several redundant error logs
are removed--we should generally not log an error when returning an
error. Errors should be logged where they are handled.

This change also properly escapes URL paths when constructing them from
protobuf messages.

Note that CodeQL continued to mark some of these uses as issues, but
we've marked them as false-positive. See github/codeql-go#635 and
github/codeql-go#650.

[cql]: https://codeql.github.com/codeql-query-help/go/go-log-injection/

Signed-off-by: Oliver Gould <ver@buoyant.io>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants