💾 Archived View for rawtext.club › ~sloum › geminilist › 006878.gmi captured on 2024-03-21 at 16:12:46. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Malicious Links

nothien at uber.space nothien at uber.space

Fri Jul 9 23:25:47 BST 2021

- - - - - - - - - - - - - - - - - - -

In Gemini, the restriction that information can only be sent to a serverby performing a request is considered a feature. However, this canbackfire by removing the need for user interaction, even when it isabsolutely necessary. Below, I provide an example to show why thisfeature, combined with the existence of malicious links, can prevent (orat least hinder) the sole use of TLS certificates in account-based siteson Gemini.

Consider a website, gemini://example.org, where users can set upaccounts. It uses TLS certificates for authentication and providesimportant settings through the Gemini interface. For example, one candelete their account by visiting a certain URL: perhapsgemini://example.org/account/delete. Although this makes sense, you mayalready begin to understand the problem at hand.

Malicious Gemini pages (or parts thereof) can contain links to suchlocations. Depending upon the user's Gemini client configuration, itmay not show them the URL they are going to (e.g. Amfora, I think), andthey may accidentally delete their account at gemini://example.org (orperform any other action involuntarily) this way.

Note that simple workarounds such as responding by asking the user totype 'YES' can be avoided trivially, by adding the 'YES' to the querystring in the URL of the malicious link.

One possible workaround is to require the user to provide their password(through a response 11) for every such action. Presumably, the attackerdoesn't know the user's password, and so cannot craft a URL which woulddelete the user's account without interaction from them. Sites wouldhave to re-state the action being performed within the prompt attachedto the response 11, and give context (so the prompt may look somethinglike "Are you sure you want to delete the account atgemini://example.org? Type in your password to continue."). However,if the user is performing many actions which require passwordverification, this is going to get irritating. In addition, it forcessites into using and storing passwords, even when they use TLScertificates.

Another workaround is to require the user to provide a randomlygenerated string. For example, upon visitinggemini://example.org/account/delete, the user is requested to type insome words that were generated at that moment ("correct horse batterystaple") to authorize the action. This removes the need for a passwordin addition to the TLS certificate, but forces sites to keep track ofthe random words for each user whenever they request such an action(this functionality will likely have to be implemented by hand, andthere are complications like timeouts to consider). This preventsattackers from crafting the necessary URL, but once again performingaccount-related actions through Gemini would become irritating.

It would also be possible to avoid this issue by using a special URLformat when sensitive input needs to be included. Sites requiringauthorization (even just a 'YES' string) could use the sensitive inputresponse, and clients would not allow the sensitive input string to beautomatically provided (instead, the user would be required to type itby hand). This provides a minimal level of necessary user interaction.Although it still suffers from the repetition problem of the aboveworkarounds, it seems to reduce the amount of work necessary, andbetter share it between server, client, and user. However, it wouldnecessitate a breaking change in protocol (or, perhaps, a new statuscode and convention for 'sensitive query strings').

The reason that HTTP/HTML does not suffer from this problem is twofold.Firstly, HTML is interactive, and so whenever such an action isperformed, the user can be interactively requested to confirm theirintention. Secondly, when the action is performed directly (e.g. byusing HTTP POST to the relevant URL), the attacker doesn't have accessto the necessary cookies to authorize the action. TLS certificates areproblematic in comparison because they apply for all interactions withthe site, and so automatically authorize any interaction; cookies for acertain site are only available to the HTML/CSS/JS of that site, and sothe site can interactively verify the user's intention beforeauthorizing the action. The access control with cookies also avoids therepetition problem, and allows users to authorize once to performmultiple actions.

With any of the above workarounds, account management on sites throughGemini becomes difficult, both for hosters/admins and for users. Infact, this extends to just about any account-based interaction with anysite; for example, sites where comments can be uploaded are affected,because a malicious link can cause an unpleasant comment to beinvoluntarily submitted.

What does the Gemini community think? How big of a problem is this?Are there any other feasible workarounds? Which major (and minor) sitesare affected? Does this call for some sort of change in protocol?

~nothien

P.S: I'm not sure what ML category this fits into. [spec], maybe?[tech]? No clue.