7 ms·
> Govulncheck analyzes your codebase and only surfaces vulnerabilities that actually affect you, based on which functions in your code are transitively calling
by psanford 4y ago
> Govulncheck analyzes your codebase and only surfaces vulnerabilities that actually affect you, based on which functions in your code are transitively calling vulnerable functions.
This is huge! Every existing vulnerability scanner that I've worked with have just looked at go.sum, which ends up reporting a lot of vulnerabilities that you don't actually care about because your code isn't actually linking to the optional transitive dependency that has the vulnerability in it.
Thank you, Go team!
- auspex 4y ago
- psanford 4y agoWhat? How does a piece of code that isn't compiled into your binary make you vulnerable?
- auspex 4y agoI should have been more clear that I was referring to external dependencies that are included. I did some research and there’s so much extra stuff included in the go.sum. You’re right that would result in a lot of false positives.
- umvi 4y agoWell if RCE is possible, then why is it going to matter if you have uncalled vulnerable functions or not? Attacker can execute anything they want.
- Someone 4y agoNot necessarily. RCE may start with being able to run ‘something’ that has restrictions such as “can’t inject code that has zero bytes in it” or “injected code can only be X bytes long”. In such cases, having another vulnerability available may be the easiest way to get rid of those restrictions. Also, the second vulnerability may be complementary. For example, the first may get you onto the machine, but not out of the sandbox, while the second won’t get you on the machine, but will get you out of the sandbox. In this case, I think the go linker won’t include the never-called vulnerable function in the executable (it only would if the vulnerability checker were smarter than the linker in detecting never-called code. That’s theoretically possible, but highly unlikely)
- tptacek 4y agoNo, this is not at all a valid argument.
- masklinn 4y ago> Just because you don’t link to or call it… if you include vulnerable code you’re still vulnerable. That makes no sense. If you never use the vulnerable code, how would an attacker access the vulnerability through your system? Especially with DCE, the vulnerability might not even be in the binary.
- freeqaz 4y agoThe only argument I can think of here is with NPM post install hooks. But for Golang, unless you import the code, I'm pretty certain that there is no way to exploit or backdoor an app. Or is there something I'm missing?
- ikiris 4y agoI guess I just found an interview question. Thanks!
- codelion 4y agoGood to see Govulncheck doing a vulnerable methods analysis for surfacing only the relevant issues. Many app sec vendors do it now for languages like Java and .NET. I originally created the vulnerable methods analysis back in 2015 - https://www.veracode.com/blog/managing-appsec/vulnerable-methods-under-hood https://www.veracode.com/blog/managing-appsec/vulnerable-met... the same idea has been now implemented by WhiteSource (Mend), Snyk etc.
- deleted 4y ago[deleted]
- seth123456 4y agoThe great thing is that when it becomes part of the toolchain it will also be available for the latest version of go as it is released. Right now veracode is stuck at go 1.17 support - maybe this will also help being up to date for such vendors more easily
- goodpoint 4y agoIf only it was language-independent I would consider it. Reinventing supply chain and vulnerability management for each language... not a good use of our time.
- klysm 4y agoIt doesn't seem possible to implement that in a language agnostic way. How do you propose doing such a thing?
- teraflop 4y agoLet's train a neural network to take source code in an arbitrary language as input, and produce a call graph as output. What could go wrong?
- tgv 4y agoAnd then clamp the output to generate vulnerabilities? Could be worth a shot.
- klysm 4y agoSide-note: how do you make a nn output a graph topology? I'm having a hard time imagining how to make a matrix represent that.
- haneefmubarak 4y agoGraph Neural Networks! https://distill.pub/2021/gnn-intro/ https://distill.pub/2021/gnn-intro/ In a nutshell, you perform NN operations on the nodes and edges of the graph and then send updates across the graph
- goodpoint 4y agoVery simple: implement language-specific static analysis backends and a general frontend and vuln management. Just like every Linux distribution does distributes packages and manages security in a language-agnostic way. Nothing new. Amazing how people here dismissed my point by downvoting and providing no reasoning.
- freeqaz 4y agoThis is really cool to see because this is the #1 problem with current tools (as you said). I call it "alert fatigue" in my head because it's meaningless when you have 100+ vulns to fix but they're 99% unexploitable. I have a bit of a bone to pick with this space: I've been working on this problem for a few months now (link to repo[0] and blog[1]). My background is Application Security and, as is often the case with devs, rage fuels me in my desire to fix this space. Well, Log4Shell helped too. As another comment said, doing this in a language agnostic way is a big PITA and we haven't fully built it yet. We are using SemGrep to do very basic static analysis (see if vulnerable function is ever imported + called). But we're not doing fancy Inter-process taint analysis like CodeQL can. (We have a big Merkle tree that represents the dependency tree and that's how we are able to make the CI/CD check take only a few seconds because we can pre-compute.) Anyway, if you have a second to help, we have a GitHub App[2] that you can install to test this out + help us find bugs. It's best at NPM now but we have basic support for other languages (no dep tree analysis yet). There are so many edge cases with the ways that repos are setup so just have more scans coming in helps a ton. (Well, it breaks stuff, but we already determined that rage sustains me.) Thank you. climbs off of soap box 0: https://github.com/lunasec-io/lunasec https://github.com/lunasec-io/lunasec 1: https://www.lunasec.io/docs/blog/the-issue-with-vuln-scanners/ https://www.lunasec.io/docs/blog/the-issue-with-vuln-scanner... 2: https://github.com/marketplace/lunatrace-by-lunasec https://github.com/marketplace/lunatrace-by-lunasec
- biomcgary 4y agoThis seems like a lot of work to identify the vulnerable functions that are called transitively. Could this work be reused to perform tree-shaking, so that Go only compiles the code you actually need? (Or, does Go already do this at compilation?)
- lukax 4y agoGo is a compiled language that uses a linker which means that only the functions that are called end up in the final binary. So yes, go does "tree-shaking".
- jrockway 4y agoIt's important to read the caveats: https://github.com/golang/go/blob/master/src/cmd/link/internal/ld/deadcode.go#L298 https://github.com/golang/go/blob/master/src/cmd/link/intern..., the most important of which is: // The third case is handled by looking to see if any of: // - reflect.Value.Method or MethodByName is reachable // - reflect.Type.Method or MethodByName is called (through the // REFLECTMETHOD attribute marked by the compiler). // // If any of these happen, all bets are off and all exported methods // of reachable types are marked reachable. Basically, if you do certain kinds of reflection, then more code is theoretically reachable and will be included in your binary. In practice, you end up with a large binary in anything that calls into autogenerated APIs.
- tucnak 4y agoThe autogenerated APIs aren't something as prevalent as one may think.
- biomcgary 4y agoThat is a useful clarification. It seems to explain why the use of the fmt Go's std lib formatting and printing package, seems to pull in so much. Surely, it is performing a fair amount of reflection under the hood.
- 4y ago
- salmo 4y agoOh my goodness I hate that so much. Every time I have to explain that go.sum lists every compatible version, not the version baked in. But this is even an improvement over any other language I've seen. All just flag CVEs in dependent libraries when 99% of the time it's like "to be vulnerable you have to do [really stupid thing]". Let's hope that vulnerability scanning vendors adopt using this. For my own stuff or minor work things, it's great. When I fall under the specter of officialness, I'll still get popped by the Enterprise Security Scanning Standard Tool.
- Thaxll 4y agoWhy would some people even care or look at go.sum where go.mod is clean and self explanatory?
- salmo 4y agoWell, I do understand that the actual version used there is ambiguous. Probably the best would be to take the newest from go.sum. That’s what some scanners are doing now. Filed bugs with 2 vendors over this though.
- preseinger 4y agoThe newest from go.sum isn't reliably the version used in the dep graph. The only way to get that information reliably is via go list. Unfortunately.