TOCTOU Vulnerability and mktemp

[junaruga]

When I ran a lint tool for bootsnap for Fedora RPM packaging.

I got below issue (vulnerability) about mktemp function used in bootsnap.

$ rpmlint -i ./*.spec /var/lib/mock/fedora-rawhide-x86_64/result/*.rpm
...
rubygem-bootsnap.x86_64: E: call-to-mktemp /usr/lib64/gems/ruby/bootsnap-1.3.0/bootsnap/bootsnap.so
This executable calls mktemp. As advised by the manpage (mktemp(3)), this
function should be avoided. Some implementations are deeply insecure, and 
there is a race condition between the time of check and time of use (TOCTOU).
See http://capec.mitre.org/data/definitions/29.html for details, and contact
upstream to have this issue fixed.

It seems that this vulnerability is related to predictable temporary file path. [1][2]
Right now the created temp file path might look hard to predict.

$ bundle exec ruby -e "require 'bootsnap'; Bootsnap.setup(cache_dir: '/tmp/foo', autoload_paths_cache: false)"

=>
ext/bootsnap/bootsnap.c
atomic_write_cache_file tmp_path is /tmp/foo/bootsnap-compile-cache/c9/1fac3dd22d6c1c.tmp.5EfzIQ

But have you considered about the vulnerability?
How do you think about the vulnerability?

I tried to implement with mkstemp instead of mktemp.
Though I have no idea about how to access the directory later in the case like below code.

    Bootsnap::CompileCache::Native.fetch(@tmp_dir, file, TestHandler)
    data = File.read(Help.cache_path(@tmp_dir, file))

junaruga@0dbd8c3

[1] https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use
[2] https://www.owasp.org/index.php/Insecure_Temporary_File

[burke]

Sorry for the extreme delay in implementing this. I've opened a PR to address this; I'm going to close this issue just to get the backlog cleaned up, happy to discuss over there.