You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// Keep in sync with src/cmd/go/internal/work/buildid.go:updateBuildID
f, err:=os.Open(file)
iferr!=nil {
log.Fatal(err)
}
matches, hash, err:=buildid.FindAndHash(f, id, 0)
If the buildid of a binary is modified manually to be empty, ie "" then the FindAndHash routine will exhaust system memory and DOS the compiler. The issue is that the matches array built up here:
will search with IdBytes equal to an empty array. This empty array will match every single time returning and idx of 0 and so every loop iteration will append into the temporary. To fix this a guard simple need to be added before calling FindAndHash to verify that the id is != ""
When is this actually an issue? Probably never, but malicious attackers do modify binaries after compilation and if anyone re-uses this code (such as I do) then they will be exposed to this bug. So essentially most common cases will not exercise this logic flaw but it does exist, so a guard should be added regardless imho.
The text was updated successfully, but these errors were encountered:
mknyszek
changed the title
OOM in buildid computation when buildid is stripped
cmd/buildid: OOM in buildid computation when buildid is stripped
Aug 20, 2021
rsc
changed the title
cmd/buildid: OOM in buildid computation when buildid is stripped
cmd/internal/buildid: FindAndHash loops forever with empty id
Aug 20, 2021
Hello the code in question is here:
go/src/cmd/buildid/buildid.go
Lines 35 to 50 in 2ebe77a
If the buildid of a binary is modified manually to be empty, ie "" then the FindAndHash routine will exhaust system memory and DOS the compiler. The issue is that the matches array built up here:
go/src/cmd/internal/buildid/rewrite.go
Lines 57 to 66 in 2ebe77a
will search with IdBytes equal to an empty array. This empty array will match every single time returning and idx of 0 and so every loop iteration will append into the temporary. To fix this a guard simple need to be added before calling FindAndHash to verify that the id is != ""
When is this actually an issue? Probably never, but malicious attackers do modify binaries after compilation and if anyone re-uses this code (such as I do) then they will be exposed to this bug. So essentially most common cases will not exercise this logic flaw but it does exist, so a guard should be added regardless imho.
The text was updated successfully, but these errors were encountered: