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

Issue F. Tip Files Can Be Downloaded Without Authenticating #826

Closed
fpietrosanti opened this Issue Mar 3, 2014 · 6 comments

Comments

Projects
None yet
3 participants
@fpietrosanti
Copy link
Contributor

fpietrosanti commented Mar 3, 2014

Synopsis: GlobaLeaks does not check if the user is authenticated when downloading files. The files are
protected only with a string generated by uuid4(), which might be predictable (see Issue K: Secrets
Generated with Non-CSPRNG), or vulnerable to side-channel attacks (see Issue J: Attacker May Be Able To Extract Secrets Through Side-Channel Attacks).
Impact: An attacker can access the files associated with a Tip.

@fpietrosanti fpietrosanti added this to the LeastAuthorityPentest milestone Mar 3, 2014

@evilaliv3 evilaliv3 changed the title Issue F. Confidential Issue F. Tip Files Can Be Downloaded Without Authenticating Apr 16, 2014

@evilaliv3

This comment has been minimized.

Copy link
Contributor

evilaliv3 commented Apr 16, 2014

@defuse : globaleaks/GLBackend-outdated@8069794

with this commit we removed entirely the concept of the download token and we implemented simply a POST authentication.

as you can see at line 501 of that commit, the post authentication works exactly as the HEADER based authentication already audited, but instead of handling X-Session header we handle x-session POST variable.

can this ticket be considered closed?

@defuse

This comment has been minimized.

Copy link

defuse commented Apr 16, 2014

@evilaliv3

It looks like the code is checking that the one sending the POST request is logged in as a receiver, which is an improvement, but I don't see it check anywhere that they are the correct receiver. In other words, it looks like a receiver who is not supposed to have access to the tip can download the files as long as they know the file id.

Is that the case, or did I overlook an authentication check somewhere?

@evilaliv3

This comment has been minimized.

Copy link
Contributor

evilaliv3 commented Apr 16, 2014

allright ok i'm going to add also this check :)

@evilaliv3

This comment has been minimized.

Copy link
Contributor

evilaliv3 commented Apr 16, 2014

@defuse: here you are

now a strict auth validation is done so that the download for single files or file collection is granted only to the precise logged user and nor a whatever user logged and apart of the link.

globaleaks/GLBackend-outdated@f9c9b8b

@defuse

This comment has been minimized.

Copy link

defuse commented Apr 17, 2014

@evilaliv3 I think there is a problem with the download_file() one:

From the POST request, the user provides the tip_id and rfile_id variables. Inside download_file() these become tip_id and file_id. Now, there's an access check with access_tip() on the user_id and tip_id, which ensures that the user has access to the Tip. However, it is not checked that the file_id file is actually part of that Tip -- they could give the file_id from a file in a different Tip and it would still download.

So there needs to be an additional check to make sure the file_id is actually a file for that tip_id.

@evilaliv3

This comment has been minimized.

Copy link
Contributor

evilaliv3 commented Apr 17, 2014

yep, right comment.

applied the fix suggested:
globaleaks/GLBackend-outdated@df1b7fc

@evilaliv3 evilaliv3 closed this Apr 20, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment