-
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
proposal: encoding/csv: limit record size with Reader.MaxRecordSize #67536
Comments
You might want to look at |
@randall77 I don't know. Probably. I am just a bug bounty hunter with very limited knowledge in golang. Maybe someone with more experience can take a look? I am just trying to work out the reasoning on why this wasn't considered a vulnerability, even though the other bug (the CVE) was even though they have the exact same exploitation mechanism behind them. |
cc @golang/security |
Thanks for the report. For future reference, the best way to report potential Go security issues is by sending mail to security@golang.org (https://go.dev/doc/security/policy#reporting-a-security-bug). This ensures the Go security team will see it. I've taken a look at The
If the A This is not something that we would consider a vulnerability, however, because the allocation is inherent in the design of the We could set a default cap on the maximum size of a field, but any cap is going to either be too small or break existing users depending on the ability to parse CSV records with many fields. In contrast, CVE-2023-24534 applies to a case where MIME header parsing could allocate substantially more memory than the amount required to hold the parsed data. This does not apply here; I do think we should consider adding the ability to limit the size of records to |
Go version
go version go1.22.3 linux/amd64
Output of
go env
in your module/workspace:What did you do?
The encoding/csv readRecord function has this line:
Here is a golang program which demonstrates this bug: https://go.dev/play/p/u7OUTS71q2Y
This bug is very similar to this: GHSA-8v5j-pwr7-w5f8 (aka CVE-2023-24534)
I reported this through google bug bounty, but this was considered to not have big enough impact to be considered a vulnerability.
What did you see happen?
The program allocates enormous amounts of memory based on attacker controlled input.
What did you expect to see?
I expected the csv reader to limit the arguments passed to "make", such that the program doesn't allocate too much memory.
The text was updated successfully, but these errors were encountered: