linux-kernel - Re: Incorrect handling of . and .. files

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YbbskNBJI8Ak1Vl/@angband.pl>
Date:   Mon, 13 Dec 2021 07:47:44 +0100
From:   Adam Borowski <kilobyte@...band.pl>
To:     Pali Rohár <pali@...nel.org>
Cc:     Sean Young <sean@...s.org>, Namjae Jeon <linkinjeon@...nel.org>,
        Sungjong Seo <sj1557.seo@...sung.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Incorrect handling of . and .. files

On Sat, Dec 11, 2021 at 03:04:53AM +0100, Pali Rohár wrote:
> I tried to find some information what is allowed and what not.
> 
> On Monday 27 September 2021 12:19:48 Sean Young wrote:
> > Windows allows files and directories called "." and ".." to be created
> > using UNC paths, i.e. "\\?\D:\..". Now this is totally insane behaviour,
> > but when an exfat filesytem with such a file is mounted on Linux, those
> > files show up as another directory and its contents is inaccessible.
> > 
> > I can replicate this using exfat filesystems, but not ntfs.
> 
> Microsoft exFAT specification explicitly disallow "." and "..", see:
[...]
> On the other hand Microsoft FAT32 specification can be understood that
> file may have long name (vfat) set to "." or ".." but not short name.
[...]
> OSTA UDF 2.60 specification does not disallow "." and ".." entries, but
[...]
> So it means that "." and ".." entries could be stored on disk as valid
> file names.

It doesn't matter one whit what the specification says.  Anyone with a disk
editor can craft a filesystem containing filenames such as "." or "..", "/"
"foo/bar" or anything else we would like to ban.

> > So, in Linux cannot read "." or ".." (i.e., I can't see "Hello, World!"). I
> > don't know what the correct handling should be, but having two "." and two
> > ".." files does not seem right at all.
> 
> This is really a bug in Linux kernel. It should not export "." and ".."
> into VFS even when filesystem disk format supports such insane file
> names.

This.

Otherwise, every filesystem driver would need to contain redundant code for
checking for such bad names.

> So either Linux needs to completely hide these insane file names from
> VFS or translate them to something which do not conflict with other
> files in correct directory.

Escaping bad names has the problem of the escaped name also possibly
existing -- perhaps even recursively.  Plus, the filesystem might be using
hashed or tree indices which could go wrong if a name is altered.

But then, I once proposed (and I'm pondering reviving) a ban for characters
\x01..\x1f and possibly others, and if banned, they can still legitimately
occur in old filesystems.

> I guess that hiding them for exfat is valid thing as Microsoft
> specification explicitly disallow them. Probably fsck.exfat can be teach
> to rename these files and/or put them to lost+found directory.

fsck fixing those is a good thing but we still need to handle them at
runtime.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀                                       -- <willmore> on #linux-sunxi
⠈⠳⣄⠀⠀⠀⠀