mc uses predictable temp directory path

[Dylan]

Binary package hint: mc

The Midnight Commander VirtualFS will expand temporary files (EG: files in rar, zip, etc) to a temporary directory for operations like view, edit, copy, etc.

HOWEVER, while my TMP and TEMP are set to a subdir of my home directory, MC's virtual FS will expand things to a directory named /tmp/mc-$username -- IGNORING these settings! This causes quite a bit of trouble when things like /tmp are not writable, and when the /tmp directory has less space than required for copying the file (which is a precondition the VirutalFS does *not* test!).

Given the predictable naming and "silent failure" mode of the VirtualFS when it copies a file too large and fills /tmp, this appears to be a security bug as well since it could be used to DoS tmp.

[Kees Cook (kees)]

Thanks for the report! Reading the source, it seems the environment you want for the temp dir is TMPDIR rather than TMP or TEMP.

However, there does still appear to be a directory creation race condition for the temp directory, so I'll leave this bug open and change the title slightly.

[Maarten Bezemer (veger)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test it on a currently supported Ubuntu version. When you test it and it is still an issue, kindly upload the updated logs by running apport-collect 129133 and any other logs that are relevant for this particular issue.

[Launchpad Janitor (janitor)]

[Expired for mc (Ubuntu) because there has been no activity for 60 days.]

[Yury V. Zaytsev (zyv)]

There used to be a similar bug in Debian or upstream bugzilla if I remember correctly. They should be connected together and taken care of.

[Yury V. Zaytsev (zyv)]

This will be finally fixed in mc-4.8.32.

[Dylan (dylang)]

Thank you for addressing this 17 year old bug.

[Yury V. Zaytsev (zyv)]

Well, sadly none of us are paid to work on mc, so expedience is definitively not a word that I would use to describe our development process...

[Mark Esler (eslerm)]

Hi @zyw o/

_If_ your project wants, I'm happy to assign and publish a CVE for this.

[Yury V. Zaytsev (zyv)]

Hi Mark, thanks for the offer! However, I don't think a CVE is warranted because I don't agree that this is a security issue:

1. The temporary directory is created with permissions that only allow the user to read its contents. If a predictable filename is considered a security issue, then any application that uses fixed FHS-based directories in the user's home directory to store configuration data, including tokens and passwords, is vulnerable.

2. The DoS argument is equally far-fetched. How about creating a large file in the user's home directory until the entire disk is filled? Is that a DoS attack? Well, I'm afraid 99% of systems are vulnerable.

In general, I have a strong dislike for labeling arbitrary problems as security issues because you don't like the problem and hope it will get fixed faster if it's "security" related. This devalues the concept of security issues and creates noise in which problems of much higher severity can drown.

[Mark Esler (eslerm)]

Sounds good!

The impact does sound low. Mostly I recommend CVEs if you want to make sure that downstreams apply a security patch.

[Yury V. Zaytsev (zyv)]

> Mostly I recommend CVEs if you want to make sure that downstreams apply a security patch.

I totally agree with that! Thank you for your understanding. That was exactly the point that I was trying to make.