Polish CWE-322: detect and exclude cases where host-checking is optional#261
Conversation
owen-mc
left a comment
There was a problem hiding this comment.
All looks good, except CI failing
| } | ||
|
|
||
| /** | ||
| * Identifies HostKeyCallbackFunc instances that reach CoientConfig.HostKeyCallback fields. |
There was a problem hiding this comment.
| * Identifies HostKeyCallbackFunc instances that reach CoientConfig.HostKeyCallback fields. | |
| * Identifies `HostKeyCallbackFunc` instances that reach `ClientConfig.HostKeyCallback` fields. |
There was a problem hiding this comment.
Ha, I vaguely remember thinking "Coient - what a weird word" as I read that. I didn't realise it was a typo! 😆
| import go | ||
| import DataFlow::PathGraph | ||
|
|
||
| /** ssh.InsecureIgnoreHostKey, which allows connecting to any host regardless of its host key. */ |
There was a problem hiding this comment.
| /** ssh.InsecureIgnoreHostKey, which allows connecting to any host regardless of its host key. */ | |
| /** The `ssh.InsecureIgnoreHostKey` function, which allows connecting to any host regardless of its host key. */ |
a13a1f7 to
5101933
Compare
max-schaefer
left a comment
There was a problem hiding this comment.
One minor nit, otherwise LGTM. Is it intentional that this is still in experimental? If we want to move it out of there, we'll need to evaluate performance.
| } | ||
|
|
||
| /** | ||
| * Identifies HostKeyCallbackFunc instances that reach `ClientConfig.HostKeyCallback` fields. |
There was a problem hiding this comment.
| * Identifies HostKeyCallbackFunc instances that reach `ClientConfig.HostKeyCallback` fields. | |
| * A data-flow configuration for identifying `HostKeyCallbackFunc` instances that reach `ClientConfig.HostKeyCallback` fields. |
5101933 to
1981e86
Compare
|
@max-schaefer amended and promoted out of experimental status. Also did the same to CWE-327. |
max-schaefer
left a comment
There was a problem hiding this comment.
A few more minor things. I can't quite tell from the diff whether you added a test for the newly added logic to detect optional host checks?
Once the performance evaluation is in, this should be good to merge.
| * @name Use of insecure HostKeyCallback implementation | ||
| * @description Detects insecure SSL client configurations with an implementation of the `HostKeyCallback` that accepts all host keys. | ||
| * @kind path-problem | ||
| * @problem.severity error |
There was a problem hiding this comment.
Needs a @precision now.
| // Either a call to InsecureIgnoreHostKey(), which we know returns an insecure callback. | ||
| this = any(InsecureIgnoreHostKey f).getACall() | ||
| or | ||
| // Or a callback function in the source code (named or anonymous) that always returns nil. |
There was a problem hiding this comment.
| // Or a callback function in the source code (named or anonymous) that always returns nil. | |
| // Or a callback function in the source code (named or anonymous) that always returns nil. |
1981e86 to
0a6239f
Compare
|
@max-schaefer all suggestions applied, and re: the test it already covered one case but not another, which I've added. It also turned out I'd partly broken the test without noticing :/ the results are now as expected, and I'm rerunning the LGTM tests to check if that's had any unexpected impact. |
f611221 to
3fabd2e
Compare
|
Btw if you look at the diff commit-by-commit you get a much nicer diff than the whole thing piled together |
3fabd2e to
f162a5b
Compare
…to include calls with multiple return types For example, https://godoc.org/golang.org/x/crypto/ssh/knownhosts#New returns a host-key checker and an error value, and we previously didn't consider the first return value a candidate checker function.
This produces a secure host-key checker; we assume by default that an opaque function not otherwise specified returns an acceptable checker, but we need to particularly cope with its multiple return values to handle this factory function.


No description provided.