-
Notifications
You must be signed in to change notification settings - Fork 272
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
Add disclaimer about limited slow retrieval attack protection #928
Add disclaimer about limited slow retrieval attack protection #928
Conversation
75e5351
to
5203754
Compare
We may also want to exclude (or add a comment to) the section about slow retrieval attacks in the tutorial-like ATTACKS.md document. |
Thanks, @lukpueh! Just want to make it clearer that this limitation is not due to our code... |
docs/SECURITY.md
Outdated
@@ -20,7 +20,8 @@ snapshot metadata, and thus new updates could never be downloaded. | |||
|
|||
* **Endless data attacks**. An attacker responds to a file download request with an endless stream of data, causing harm to clients (e.g. a disk partition filling up or memory exhaustion). | |||
|
|||
* **Slow retrieval attacks**. An attacker responds to clients with a very slow stream of data that essentially results in the client never continuing the update process. | |||
* **~~Slow retrieval attacks~~**. An attacker responds to clients with a very slow stream of data that essentially results in the client never continuing the update process.\ | |||
**_NOTE: The TUF reference implementation currently provides only limited protection against slow retrieval attacks (see [tuf#781](https://github.com/theupdateframework/tuf/pull/781))._** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we be trying to fix this upstream in request? Is that sensible? If so, should we link to that discussion instead?
The issue we refer to here has a lot going on, I'd prefer we had something clearer to point to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I guess we should at least file an issue that points to slow loris attacks.
Since theupdateframework#781 we only provide limited protection against slow retrieval attacks. So far this has only been discussed in above issue and hinted at by a disabled test and a code comment in that test. This change adds a corresponding disclaimer to a more prominent place, i.e. the list of attacks in SECURITY.md. Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu> Co-Authored-By: Trishank K Kuppusamy <33133073+trishankatdatadog@users.noreply.github.com>
fec30ca
to
42a4cee
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Is the failing test a race condition / Heisenbug? I would merge otherwise |
It's a timeout issue, which seems to happen fairly often for tests on appveyor/windows (less often on travis/linux too). In any case, the fail here is impossibly related to the change in this PR. I say it's safe to merge. |
Fixes issue #:
None. Related to #781.
Description of the changes being introduced by the pull request:
Since #781 we only provide limited protection against slow retrieval attacks. So far this has only been discussed in above issue and hinted at by a disabled test and a code comment in that test.
This change adds a corresponding disclaimer to a more prominent place, i.e. the list of attacks in SECURITY.md.
Please verify and check that the pull request fulfills the following
requirements: