Skip to content
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

[EXT-SEC-AUDIT] Architecturally insecure type declarations #2810

Closed
pro-wh opened this issue Apr 1, 2020 · 0 comments · Fixed by #2813
Closed

[EXT-SEC-AUDIT] Architecturally insecure type declarations #2810

pro-wh opened this issue Apr 1, 2020 · 0 comments · Fixed by #2813

Comments

@pro-wh
Copy link
Contributor

pro-wh commented Apr 1, 2020

Issue transferred from an external security audit report.

Severity: Medium
Type: Data Validation
Target: go/staking/api/commission.go
Difficulty: High
Finding ID: TOB-OL-108

Description

Int is set based on the architecture on a specific machine. MaxRateSteps and
MaxBoundSteps could be converted incorrectly between 32-bit and 64-bit machine
architectures.

Figure TOB-OL-108.1: shows https://github.com/oasislabs/oasis-core/blob/f3dec8e8bc17d0bae64b636bddc9a3100abc6866/go/staking/api/commission.go#L15-L20

Exploit Scenario

A 64-bit machine sets MaxBoundSteps to a value greater than the maximum value of a
32-bit architecture int ( 2,147,483,647) . MaxBoundSteps is read on a 32-bit machine and the
value is not what was originally set.

Recommendation

Convert to an architecture independent type (e.g. int32 , int64 ) for any int that could be a
large value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant