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

Mutable objects, such as database connections cause overtaint #58

Open
JustusAdam opened this issue Sep 29, 2023 · 0 comments
Open

Mutable objects, such as database connections cause overtaint #58

JustusAdam opened this issue Sep 29, 2023 · 0 comments
Labels
enhancement New feature or request flow-analysis Concerns the PDG construction component

Comments

@JustusAdam
Copy link
Collaborator

Mutable objects introduce flows. Which can be unwanted when the mutable object doesn’t actually transport information, or if the information transport is captured in some other way.

Concretely this occurs with the backend object in websubmit. This object represents the database connection. Its semantics are explicitly modeled in the environment model. As a result the backend object may introduce flows that are not actually there.

fn submit(backend: Backend, lecture: u8, apikey: ApiKey, data: Submission) {
    backend.insert(
        "submissions", 
                vec![
                        ("lecture", lecture.into()), 
                        ("user", apikey.id.into()), 
                        ("data", submission)
                ]);

        let presenters = backend.select(
                "SELECT email FROM presenters where lecture = ?", 
                vec![lecture.into()]
        );
        
        email::send(presenters, format!("user {} submitted {}", user.name, submission));
}

This is a much reduced (and with some creative editing) example of what happens in websubmit. The problem that occurs here is that this flow means the send call is blessed, even if we do not teach our model what presenters are. The reason is that both insert and select take an &mut self. As a result insert creates a flow from apikey to backend and select creates a flow from backend to presenters and, due to transitivity, from apikey to presenters. Because apikeyis blessed (it represents the user itself) this means that presenters is blessed. Basically the system now thinks that presenters is the user’s email address.

This is of course mitigated once we do the “all sources” sort of properties, but it will still cause an issue for users, because it will be flagged as a potential source.

@JustusAdam JustusAdam added flow-analysis Concerns the PDG construction component enhancement New feature or request labels Sep 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request flow-analysis Concerns the PDG construction component
Projects
None yet
Development

No branches or pull requests

1 participant