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

uplink(fix): Fix use-after-free bug in edge::Gateway #80

Merged
merged 1 commit into from
Nov 13, 2024

Conversation

GodTamIt
Copy link
Contributor

@GodTamIt GodTamIt commented Nov 11, 2024

Previously, from_ffi_credentials_result() would free the underlying memory of the strings stored in Gateway (the FFI EdgeCredentialsResult) upon success, resulting in a use-after-free error for anyone trying to access those strings.

Unfortunately, this will be a breaking change.

@GodTamIt
Copy link
Contributor Author

fyi @ifraixedes - this is potentially a security vulnerability.

@ifraixedes ifraixedes self-requested a review November 11, 2024 14:44
Copy link
Collaborator

@ifraixedes ifraixedes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@GodTamIt good catch!

I detected these issues when I wrote one of the first integration tests. When I realized the problem, I changed all of them to types that Rust owns rather than dragging references to C pointers.

I changed all of those structs that I found however, I missed some that I changed when later I realized (e.g. 9bb1cfb).

I missed this one. One of the reasons is that there is no integration test for it https://github.com/storj-thirdparty/uplink-rust/blob/main/uplink/tests/edge_test.rs#L8

Thank you very much for your contribution.

uplink/src/edge/credentials.rs Outdated Show resolved Hide resolved
@GodTamIt
Copy link
Contributor Author

GodTamIt commented Nov 11, 2024

@ifraixedes yep, all done!

Thanks for the quick reviews :)

Aside: for some of the memory freeing code paths, what's your opinion on using something like scopeguard so that memory always gets cleaned up (RAII style)?

@GodTamIt GodTamIt changed the title bug: Fix use-after-free bug in edge::Gateway uplink(fix): Fix use-after-free bug in edge::Gateway Nov 11, 2024
@ifraixedes
Copy link
Collaborator

Aside: for some of the memory freeing code paths, what's your opinion on using something like scopeguard so that memory always gets cleaned up (RAII style)?

I got a suggestion when I talked about building this in a meetup. They said:

Because you cannot implement the Drop trait for the types generated by bindgen, you could implement a wrapper type for each of them and implement the Drop trait.

I stated it as a good idea. Unfortunately, I didn't think about it when I implemented it 😬

Did I respond to your question?

@GodTamIt
Copy link
Contributor Author

Aside: for some of the memory freeing code paths, what's your opinion on using something like scopeguard so that memory always gets cleaned up (RAII style)?

I got a suggestion when I talked about building this in a meetup. They said:

Because you cannot implement the Drop trait for the types generated by bindgen, you could implement a wrapper type for each of them and implement the Drop trait.

I stated it as a good idea. Unfortunately, I didn't think about it when I implemented it 😬

Did I respond to your question?

Yeah that does. If I have some time, I could explore doing something like that. Otherwise, the library is working as intended so not critical. Just helps prevent leaks and bugs :)

@ifraixedes
Copy link
Collaborator

@GodTamIt the build fails because of unrelated issues. I'm addressing them

@ifraixedes
Copy link
Collaborator

You'll need to rebase once I merge #82
I'm waiting for reviews.

@ifraixedes
Copy link
Collaborator

@GodTamIt it's merged.

Previously, `from_ffi_credentials_result()` would free the underlying
memory of the strings stored in `Gateway` (the FFI
`EdgeCredentialsResult`) upon success, resulting in a use-after-free
error for anyone trying to access those strings.

Unfortunately, this will be a breaking change.
@GodTamIt
Copy link
Contributor Author

@ifraixedes it's rebased

@ifraixedes ifraixedes merged commit c543bd7 into storj-thirdparty:main Nov 13, 2024
2 checks passed
@ifraixedes
Copy link
Collaborator

ifraixedes commented Nov 13, 2024

@GodTamIt I will make a new release later today or tomorrow.
Thank you for your contribution.

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 this pull request may close these issues.

2 participants