Changes between Initial Version and Version 1 of Ticket #2024


Ignore:
Timestamp:
2013-07-17T15:16:20Z (11 years ago)
Author:
daira
Comment:

Replying to warner:

A simpler rule would probably work too: any zero-length reads are grounds to reject the share.

That wouldn't work against a malicious server that, say, returns 1 byte.

The workaround I recommended for markb's work in #1382 is to just refrain from corrupting those four num_leases bytes. Once we fix this ticket, we should go back to test_download.py and remove that workaround.

+1.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #2024

    • Property Keywords download hang denial-of-service security added

  • Ticket #2024 – Description

    initial v1  
    77A simpler rule would probably work too: any zero-length reads are grounds to reject the share. We do some speculative reads (based upon assumptions about the segment size), so we'd need to look carefully at that code and make sure that the speculation cannot correctly yield zero bytes. In particular I'm thinking about the UEB fetch from the end of the share: its offset depends upon the size of the hash trees, so if our guessed segment size is too small, the UEB fetch might return zero bytes, but the correct thing to do is to re-fetch it from the correct place once we've grabbed the offset table.
    88
    9 The workaround I recommended for markb's work in #1382 is to just refrain from corruption those four {{{num_leases}}} bytes. Once we fix this ticket, we should go back to {{{test_download.py}}} and remove that workaround.
     9The workaround I recommended for markb's work in #1382 is to just refrain from corrupting those four {{{num_leases}}} bytes. Once we fix this ticket, we should go back to {{{test_download.py}}} and remove that workaround.