cloud backend: denial of service attacks against XML parser #2192

Closed
opened 2014-02-17 00:06:11 +00:00 by daira · 1 comment
daira commented 2014-02-17 00:06:11 +00:00
Owner

A malicious cloud service could easily cause a DoS against the storage server using some of the attacks described in https://pypi.python.org/pypi/defusedxml/. This is not a particularly serious attack as long as one storage server is associated with each cloud service and that server is running in its own virtual machine, since then the cloud service can only affect its associated storage server's virtual machine. OTOH, switching to a library that prevents these attacks would probably be straightforward.

A malicious cloud service could easily cause a DoS against the storage server using some of the attacks described in <https://pypi.python.org/pypi/defusedxml/>. This is not a particularly serious attack as long as one storage server is associated with each cloud service and that server is running in its own virtual machine, since then the cloud service can only affect its associated storage server's virtual machine. OTOH, switching to a library that prevents these attacks would probably be straightforward.
tahoe-lafs added the
code-storage
minor
defect
cloud-branch
labels 2014-02-17 00:06:11 +00:00
tahoe-lafs added this to the undecided milestone 2014-02-17 00:06:11 +00:00
exarkun commented 2020-10-30 12:35:44 +00:00
Author
Owner

The established line of development on the "cloud backend" branch has been abandoned. This ticket is being closed as part of a batch-ticket cleanup for "cloud backend"-related tickets.

If this is a bug, it is probably genuinely no longer relevant. The "cloud backend" branch is too large and unwieldy to ever be merged into the main line of development (particularly now that the Python 3 porting effort is significantly underway).

If this is a feature, it may be relevant to some future efforts - if they are sufficiently similar to the "cloud backend" effort - but I am still closing it because there are no immediate plans for a new development effort in such a direction.

Tickets related to the "leasedb" are included in this set because the "leasedb" code is in the "cloud backend" branch and fairly well intertwined with the "cloud backend". If there is interest in lease implementation change at some future time then that effort will essentially have to be restarted as well.

The established line of development on the "cloud backend" branch has been abandoned. This ticket is being closed as part of a batch-ticket cleanup for "cloud backend"-related tickets. If this is a bug, it is probably genuinely no longer relevant. The "cloud backend" branch is too large and unwieldy to ever be merged into the main line of development (particularly now that the Python 3 porting effort is significantly underway). If this is a feature, it may be relevant to some future efforts - if they are sufficiently similar to the "cloud backend" effort - but I am still closing it because there are no immediate plans for a new development effort in such a direction. Tickets related to the "leasedb" are included in this set because the "leasedb" code is in the "cloud backend" branch and fairly well intertwined with the "cloud backend". If there is interest in lease implementation change at some future time then that effort will essentially have to be restarted as well.
tahoe-lafs added the
wontfix
label 2020-10-30 12:35:44 +00:00
exarkun closed this issue 2020-10-30 12:35:44 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#2192
No description provided.