[Bug 1586295] Review Request: rubygem-bootsnap - Boot large ruby/ rails apps faster

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=1586295



--- Comment #12 from Pavel Valena <pvalena@xxxxxxxxxx> ---
(In reply to Jun Aruga from comment #10)
> How about using mkstemp instead of mktemp? Though I am not confident for
> that? or asking security guys?
> 
> https://www.owasp.org/index.php/Insecure_Temporary_File
> > Finally, mkstemp() is a reasonably safe way to create temporary files.

In case you consider the implementation insecure, I think it's imperative to
contact upstream and solve the issue with them. Fedora is no such place and in
the end this needs to be resolved upstream anyway.

> Are you sure?
> It seems that the method "atomic_write_cache_file" which mktemp is called in
> is expecting as a attomic.
> But seeing the actual logic, I think the logic [2] is not related to the
> called method atomic_write_cache_file. As you know, Mutex itself is used for
> native thread. But it does not guarantee atomic access if lock is not used.
> It depends on the implementation.

Yes, like I wrote the mutex is used on Ruby level, not on C level. Whether
that's secure or not is not for me to decide. However, there are two more
conditions that'd have to be met for this to be a successfull attack, like I
wrote already:

> Furthermore, reading CAPEC[3], as suggested by rpmlint, none of the Attack Prerequisites are not met AFAICT.
> [3] http://capec.mitre.org/data/definitions/29.html

________________

> For example it seems that when below logic is called several times at same
> timing, it does not guarantee the atomic access.
> 
> ```
> irb(main):001:0> require 'bootsnap'
> irb(main):006:0> Bootsnap.setup(cache_dir: '/tmp/foo', autoload_paths_cache:
> false)
> => :load_file
> ```

Disregarding the attack vector, for the sake of the argument -
  Actually, I think it should be safe. Because when you use native Ruby Threads
(like in a rails app), Bootsnap runs `@mutex.synchronize { ... }` everywhere[*]
and the requests should not collide.

[*]
https://github.com/Shopify/bootsnap/blob/684acfd9b8c1298a026dd6b9c2ffeb173d11e949/lib/bootsnap/load_path_cache/cache.rb#L11

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
_______________________________________________
package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx/message/UWSFG3VO2HO6MQ6EQMXQS2MGQT2OHGJ6/




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite Conditions]     [KDE Users]

  Powered by Linux