An unauthenticated visitor can access a path like .../settings/userexport

[AlfredSK]

• I have searched open and closed issues for duplicates

Bug Description

I saw some weird and suspicious lines in the PHP error log. On the Friendica forum node there are no user accounts I don't own. But still, the errors indicated that someone was trying to export a user account. So I checked if I can access the userexport path in a private browser window. Yep. I can.

Well, the export doesn't work because the system doesn't know which user account to export when the visitor is clicking on the link "export account". But this really looks like a dangerous habit to allow the access to that page for unauthenticated visitors.

From the PHP log:

PHP Notice:  Trying to access array offset on value of type null in .../src/Module/Settings/UserExport.php on line 93
PHP Fatal error:  Allowed memory size of 218103808 bytes exhausted (tried to allocate 8192 bytes) in .../src/Database/Database.php on line 927

Steps to Reproduce

1. open .../settings/userexport in a private browser window (unauthenticated access)
2. well, you'll see the problem

Actual Result:

Expected Result:

Access denied error page.

Platform Info

Friendica Version:
2021.03-rc

Friendica Source:
git

PHP version:
7.4

SQL version:
MariaDB 10.3

[MrPetovan]

Thanks, I need to move this module to the new folder system, I'll take of this in the same effort.

[AlfredSK]

Do you think this could be a security issue? I am thinking of some URL parameter forgery.

[MrPetovan]

No, the feature still requires a valid authentication cookie even if the route is accessible to non-logged users.

[MrPetovan]

I just got the CVE number CVE-2021-30141 for this issue.

[MrPetovan]

Post-mortem: After investigation this security vulnerability proved to be less harmful than initially feared. Accessing the user export as an anonymous user enabled to export data with uid = 0 from the user, contact and post database tables.

• The only user row with uid = 0 is Friendica's dummy system account created on install. It isn't possible to log in with this user and the exposed cryptographic key pair exposed is only used when interacting with relay servers and fetching public content from remote servers. It doesn't allow to impersonate any local node user nor allows to authenticate outgoing message from the compromised server.
• The contact rows with uid = 0 contain the public information about local and remote contacts. It doesn't contain any relationship information with local users.
• The post rows with uid = 0 contain the information about public local and remote posts. It doesn't include posts with a restricted visibility or private messages nor delivery information to local users.

Given the size of the result set for the two latter tables on most nodes, the requested fraudulent export for contacts and all data is likely to fail by hitting the PHP memory limit on the node's server anyway.

So, a big scare, but nothing serious in the end. Thanks to @AlfredSK for the initial report and @urbalazs for the escalation even if it didn't prove harmful.

[AlfredSK]

Thank you for the update and for the details about the issue.