[dpdk-stable] [dpdk-dev] [PATCH] vhost: fix insecure temporary file

[Bruce Richardson]

On Tue, Nov 26, 2019 at 11:19:00PM +0800, Jin Yu wrote:
> When using mkstemp(), remember to safely set the umask
> before to restrict the resulting temporary file
> permissions to only the owner.
> 
> Coverity issue: 350367
> Fixes: d87f1a1cb7b6 ("vhost: support inflight info sharing")
> Cc: stable at dpdk.org
> 
> Signed-off-by: Jin Yu <jin.yu at intel.com>
> ---
>  lib/librte_vhost/vhost_user.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
> index 0cfb8b792..1a68e23e3 100644
> --- a/lib/librte_vhost/vhost_user.c
> +++ b/lib/librte_vhost/vhost_user.c
> @@ -1342,6 +1342,7 @@ inflight_mem_alloc(const char *name, size_t size, int *fd)
>  	RTE_SET_USED(name);
>  #endif
>  	if (mfd == -1) {
> +		mode_t mask = umask(0600);
>  		mfd = mkstemp(fname);

Setting the umask is unnecessary, as if you read the man page for mkstemp:

"The file is created with permissions 0600, that is, read plus write for
owner only."

I am aware that coverity flags this as a potential issue, but if you
follow the link from the coverity issue to CWE-377 on cwe.mitre.org, you
can find the following at the end of the "Notes" section:

"Finally, mkstemp() is a reasonably safe way create temporary files. It
will attempt to create and open a unique file based on a filename template
provided by the user combined with a series of randomly generated
characters. If it is unable to create such a file, it will fail and return
-1. On modern systems the file is opened using mode 0600, which means the
file will be secure from tampering unless the user explicitly changes its
access permissions. However, mkstemp() still suffers from the use of
predictable file names and can leave an application vulnerable to denial of
service attacks if an attacker causes mkstemp() to fail by predicting and
pre-creating the filenames to be used."

So it seems that for creating temporary files, mkstemp() is probably the
best function we can use. Therefore, I recommend not trying to patch this
issue and just mark the issue as "ignore" in coverity.

Regards,
/Bruce