-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/pkgsite: links can point at source code that may not match what is served by the module proxy #66653
Comments
a variation may be: the proxy and pkgsite uses a clean tagged version, but the source repo later moves the tag. pkgsite source links use tags when available. this may only become visible if someone tries to build with GOPROXY=direct. |
Alternatively, should pkgsite use services like https://go-mod-viewer.appspot.com for source link, instead of attempting to link to the repository? go-mod-viewer.appspot.com does not offer rich UIs like VCS hosting sites, but it shows the source code as included in the module zip file. |
@hyangah Who owns the service you propose? |
@Merovius Could you not achieve the same by discriminating using pkgsite idiosyncrasies and serving everyone else but the pkgsite a malicious Git repository? Without an authoritative ground truth you trust, you can never be sure two requests are semantically compatible. Thus, I think the indication you request is fundamentally impossible unless you install a browser plugin which is attached to sum.golang.org. The real problem is that the malicious package is already the ground truth, since |
I'll also note that I'm not sure if and how But yes, it's always going to be imperfect. That does not mean we can't improve it. |
FWIW another interesting response to this might be for |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@jfrech I'm sorry, but I'm genuinely not sure how to engage with what you are saying. The basic nature of what I'm reporting here is that it is possible for a module to contain malicious code, while everyone importing and using it will come to the reasonable conclusion that they get served the verified and vetted content of a well-known git repository. Given that we just experienced a supply chain attack that was (in part) based on exactly such a mechanism, it seems a reasonable question to pose whether we can do anything to make it more likely that such an attempt gets discovered. Especially given that we theoretically have the ability to determine automatically whether a given source tree was used to create a given module zip. You are correct that there are other vectors - besides the one I demonstrated - for a malicious module to create such an illusion. But how does that change the fact, that I think there are mechanisms we can come up with to improve the situation here. For example
But also, perhaps the Go team just feels there is no action needed here. That's their prerogative, of course. It still seems like a reasonable thing to ask. |
FTR I think Go's situation here is vastly better than most other language's, because
The thing I'm proposing is to consider a way to put these pieces together. The way open source is usually vetted is by following the commit log. Currently, there exists no link from that to the checksum database. I'm proposing to consider whether we can perhaps build such a link - even if it is only limited to a probabilistic one. |
As I understand it, this has been used to hide actual malware. |
cc @golang/security |
see #68669 for a related proposal of verifying a repo checkout |
What is the URL of the page with the issue?
https://pkg.go.dev/gonih.org/xzpoc
What is your user agent?
Mozilla/5.0 (X11; Linux x86_64; rv:124.0) Gecko/20100101 Firefox/124.0
Screenshot
(not super relevant)
What did you do?
I served a
go-import
meta-tag with vcsmod
pointing at a personal proxy fromgonih.org/xzpoc
. The proxy is serving a valid, but "malicious" version of a package that contains aGreeting
function returning the string "gotcha pwned".It also contains a
go-import
meta-tag with vcsgit
pointing at a GitHub repo containing a module with the same package and API, but returning the stringHello world!
from that function. Thev1.0.0.info
file points at the "clean"v1.0.0
tag and commit, even though the code contained in thev1.0.0.zip
file does not match the content of that repository.Here is a playground link to demonstrate what happens when that package is imported.
For your convenience, this is what is served by my "infected" proxy:
xzpoc.tar.gz
What did you see happen?
pkg.go.dev
links to the "clean" version in the repository, both from the side-bar and in the individual links for the exported API, giving the impression that the module, when imported, will contain the "clean" code. But if anyone actually depends on that module, they will download and use the "malicious" version (regardless of whether they use the public mirror, or bypass it withGOPROXY=direct
, as both will download the module from my "infected" proxy). It is only by inspecting the downloaded code, that they can detect the "malware".What did you expect to see?
Some kind of indication, that the code in the repository does not accurately reflect the cached version.
The text was updated successfully, but these errors were encountered: