[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [FD] "." (period) in file extension(s) in windows

Hi there,

It's the same with spaces btw (see also James Forshaw's mention of this in
his post [1]):

>echo test > asdf
>type asdf
>type "asdf. . . ... .. . ..... .        "

Reading doesn't seem to work with Windows Subsystem for Linux (Windows 10)
though :(

$ cat asdf
$ cat "asdf . ... . .... . .    "
cat: 'asdf . ... . .... . .    ': No such file or directory
$ cat < "asdf .. .  . ... "
bash: asdf .. .  . ... : No such file or directory

Creating a file with spaces/dots from WSL does work (in the same mapped

$ echo test2 > "asdf . . . . .   ... "
$ cat "asdf . . . . .   ... "

And the file is listable on Windows (i.e. not WSL) too:

>dir /b asdf*
asdf . . . . .   ...

Removing it, as you said, is pretty funny (actually the "asdf" file is
removed in this example):

>del "asdf . . . . .   ... "
>dir /b asdf*
asdf . . . . .   ...

Neither Total Commander nor Windows Explorer were able to remove the file.
That said, Total Commander DID successfully rename the file (even if there
were several "weird" files in the directory, it was able to correctly
rename the right one) - props to TC ;) (Explorer was not able to do it).
(This probably means that the space/dot stuff is implemented in WinAPI, but
TC uses NTAPI for some reason; well, I guess James did explain this in [1])

I've also tested Virtual Box's folder sharing - I expected it to behave the
same way Windows does (i.e. not WSL), and it's pretty similar. When
creating files in a shared folders the dots/spaces are ignored, but when
trying to read a file with a weird name it just doesn't work.

Anyway, WSL makes this interesting, but it's not the end of the world. In a
2008 article (for hakin9 out of all places [2]) I've also mentioned the
dot/space removal behavior might be problematic when doing file name
blacklists on Windows (well, just another argument for blacklists not

A fun trick ;)

search for "space"
[2] "Niebezpieczne nazwy plików" (hakin9 Nr 01/2008) - yeah, in Polish, sry

On Tue, Jan 2, 2018 at 2:05 AM debug <debug.net AT gmail.com> wrote:

> So I tried to rename a file to something like "hi..." and it would revert
> back to "hi" no matter how many periods i put after the name (last
> character must be a period for this to work). This got me to wonder if I
> was to create a file using POSIX software or say by mounting the drive in
> Linux and creating the file on the drive directly; what could one do?
> Because of the way Windows handles extensions differently than the name of
> the file itself, extensions cannot contain a period and therefore the file
> when specially created, becomes inaccessible through any builtin windows
> methods. This could be exploited by hiding data on a windows system in
> plain sight and making it impossible to delete unless one deletes the
> entire folder it is in (rd /q/s works great in my test). This could still
> be defeated by using bash from Cygwin or any Linux distro mounting the
> drive directly but if one works in a business environment where external
> tools are not allowed and a system is exploited then this could frustrate
> administrators until they are able to get approval for external software to
> fix the issue. Or this could cause other issues if something is being
> referred to by this "invalid" name (Windows reports it as missing or
> inaccessible), so if a certain service keeps track of what files names are
> changed to while the operating system is up an running and its name is
> changed to this "invalid" format, a system could be DoS or other vectors of
> compromise.
> _______________________________________________
> Sent through the Full Disclosure mailing list
> https://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/

Sent through the Full Disclosure mailing list
Web Archives & RSS: http://seclists.org/fulldisclosure/