requests for pastes with non-base64-alphabet ids leak unrelated pastes

[Nic321]

Pretty sure this isn't supposed to happen:

https://ptpb.pw/.ssh

https://ptpb.pw/.svg

https://ptpb.pw/.svn

Is there a quick fix?

[buhman]

Nice.

λ zack [~] → curl -X REPORT https://ptpb.pw/.ssh
date: 2016-05-11T07:32:39.576000+00:00
digest: 17e0a67cb77f4d88f24de722e6e9e69c6c509276
long: ABfgpny3f02I8k3nIubp5pxsUJJ2
short: UJJ2
size: 64855
status: found
url: https://ptpb.pw/UJJ2

[buhman]

Is there a quick fix?

This is something like a three-part bug:

• .ssh is a theoretically valid paste name according to the sid regex (incorrect behavior)
  • urlsafe_b64decode('.ssh') throws binascii.Error('Incorrect padding') (correct behavior)
  • the sid converter handles this by returning a None paste id (incorrect behavior)
  • the view does not validate the correctness of converter result, so it assumes None to be a valid paste sid value (correct-ish? behavior)
  • the view then generates the following query (correct behavior)
  • {'short': None, 'private': {'$exists': False}, 'namespace': {'$exists': False}}
  • paste.model._transform then helpfully transforms the query to:
  • {'private': {'$exists': False}, 'namespace': {'$exists': False}} (unexpected behavior)
  • there aren't enough tests for me to safely refactor that function

The resulting cursor represents all non-private pastes that are in the default namespace, sorted by creation date. The resulting response is "the most recent non-private paste in the default namespace".

Additional bugs:

• I call cur.count() which results in mongo evaluating the result of the entire query (slow). The correct thing to do is catch StopIteration on next(cur)

[buhman]

This is actually easy to "fix", at least superficially. I don't remember the historical reasons for the character group [A-Za-z0-9_~.-] (actually I do, it was for compatibility with the previous "base66" scheme, and several refactors later the extra two characters are no longer relevant), but ~. are not part of python's urlsafe alphabet.

[buhman]

Fixed in https://github.com/ptpb/pb/commit/488ecea135e90e59029b8728e9aebe71bd137789.

[buhman]

The example URLs now return flask 404 responses.

[buhman]

the most recent

Also notice how -X REPORT returned https://ptpb.pw/UJJ2, the least recent paste in the production pb database (created by me, you can tell by the unique cryptdevice=/dev/sda3:main:allow-discards cmdline), instead of the most recent. This is because sorting by date is not applied correctly to all find() queries, including the one the report view uses.

If I was super interested, I'd spin this issue off into ~5 other bug reports.

[buhman]

represents all non-private pastes

I tested this again with 488ecea removed, and it was also possible to access private pastes with a url like this:

https://ptpb.pw/.aaaaaaaaaaaaaaaaaaaaaaaaaaa