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]
Date: Tue, 02 Jan 2018 01:57:10 +0000
From: Gynvael Coldwind <gynvael@...dwind.pl>
To: debug <debug.net@...il.com>
Cc: fulldisclosure@...lists.org
Subject: 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
test
>type "asdf. . . ... .. . ..... .        "
test

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

$ cat asdf
test
$ 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
directory):

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

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

>dir /b asdf*
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
working).

A fun trick ;)

Cheers,
[1]
https://googleprojectzero.blogspot.ch/2016/02/the-definitive-guide-on-win32-to-nt.html
-
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@...il.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
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ