linux-ext4 - Re: [f2fs-dev] [PATCH] fscrypto: fix to null-terminate encrypted filename in fname

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 29 Aug 2016 15:08:03 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Chao Yu <chao@...nel.org>
Cc:     jaegeuk@...nel.org, linux-f2fs-devel@...ts.sourceforge.net,
        linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
        Chao Yu <yuchao0@...wei.com>
Subject: Re: [f2fs-dev] [PATCH] fscrypto: fix to null-terminate encrypted
 filename in fname_encrypt

On Mon, Aug 29, 2016 at 10:55:47PM +0800, Chao Yu wrote:
> Hi Ted, Jaegeuk,
> 
> Since encryption functionality in ext4/f2fs was exported to vfs as fscrypot
> module, more filesystems can use it, I'm not sure, maybe other fs will traverse
> encrypted filename directly.
> 
> So, could we set this null character in fname_encrypt in advance in order to
> avoid hitting random characters behind target filename when traversing it?

The encrypted filename is only used by the file system; it's not
anything which is visible outside of the file system --- if it does,
such as passing it to the security subsystem, it's a bug.

Secondly, remember that the encrypted filename is a binary blob, and
may contain hex 00 as part of the encrypted filename.  So ***any***
code that tries to use NULL termination for the encrypted filename by
definition is a bug.  In other words, you must use memcpy, and not
strcpy.  If you use strcpy, even if you did add a NUL character to the
end of the encrypted filename (which is a bit of a misnomer because it
is a binary blob, not an ASCII string, so NUL is really not
technically correct), there will be encrypted filenames where strcpy
will stop early, because there is a 0x00 byte in the encrypted
filename.

Hence, other file systems MUST NOT traverse the encrypted filename
directly, because treating it as a NUL-terminated string when it is
really a binary blob of bits that can include a 0x00 byte is by
definition a BUG.

Cheers,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html