💾 Archived View for gemi.dev › gemini-mailing-list › 000902.gmi captured on 2024-08-19 at 02:30:31. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
A couple of days ago I've found and fix a path traversal issue in the dezhemini (aka dʒɛmɪni) gemini server software. A specially crafted URL will allow an attacker to read arbitrary files from the host file system. The issue is fixed in commit 2dba1ee1c875b07ca2e04f8bf2d03bfc5b2afc5f. All versions prior to this commit are vulnerable to this type of intrusion. Please upgrade as soon as possible.
On 13/05/2021 07:46, Remco wrote: > A couple of days ago I've found and fix a path traversal issue in the > dezhemini (aka dʒɛmɪni) gemini server software. A specially crafted URL > will allow an attacker to read arbitrary files from the host file > system. > > The issue is fixed in commit 2dba1ee1c875b07ca2e04f8bf2d03bfc5b2afc5f. > All versions prior to this commit are vulnerable to this type of > intrusion. Thanks for notifying everyone! This seems to be a common security issue with Gemini servers. A question to everybody reading the list, how badly would it break the spec to simply block any request whose URLs contain ".." as a standalone path-element? ~almaember
On Sat, 15 May 2021 at 12:09, Almaember <almaember@disroot.org> wrote: > > A question to everybody reading the list, how badly would it break the > spec to simply block any request whose URLs contain ".." as a standalone > path-element? > I don't think it would break anything, seems perfectly logical to me to block `..` as a part of a path. Blocking `~` and `.` as well would be good. -Oliver Simmons
2021/05/15 13:09, Almaember: > A question to everybody reading the list, how badly would it break the > spec to simply block any request whose URLs contain ".." as a > standalone path-element? Simply blocking ".." won't catch all problems. Of instance, dezhemini actually blocks all request containing ".." in the URL and returns a 59 (bad request). This particular case is a problem in the Racket standard library used to parse URLs. This library splits a path in parts (string and symbols) with 'up (a symbol) for ".." but not when the dots are escaped with %, it would yield "..". Dezhemini only blocked on 'up, auch.. Also, blocking ".." will break my lang=morse site! ;-) ..///.-../---/...-/.///--././--/../-./.. Cheers, Remco
I agree that simply blocking URLs with “..” won’t solve the problem. The string doesn't always show up in a segment on its own. Also, there are legitimate uses for a “..” segment when URLs are formed relative to a resource deeper down in a hierarchy. A server should sanitize / normalize every incoming request URL to its simplest, unencoded form. Then it can more easily detect attempts to escape the server’s document root or other shenanigans. > On May 15, 2021, at 9:18 AM, Remco <me@rwv.io> wrote: > > > 2021/05/15 13:09, Almaember: > >> A question to everybody reading the list, how badly would it break the >> spec to simply block any request whose URLs contain ".." as a >> standalone path-element? > > Simply blocking ".." won't catch all problems. Of instance, dezhemini > actually blocks all request containing ".." in the URL and returns a 59 > (bad request). This particular case is a problem in the Racket standard > library used to parse URLs. This library splits a path in parts (string > and symbols) with 'up (a symbol) for ".." but not when the dots are > escaped with %, it would yield "..". Dezhemini only blocked on 'up, > auch.. > > Also, blocking ".." will break my lang=morse site! ;-) > > ..///.-../---/...-/.///--././--/../-./.. > > Cheers, > Remco
---
Previous Thread: [users] Tina, an aggregator for the Italian Geminispace