4 ms·

I'm a bit confused here, perhaps because I don't really understand Rails (possibly also the HTML spec). I was under the impression the 'Accept:' header is a li

by anitil 8y ago

I'm a bit confused here, perhaps because I don't really understand Rails (possibly also the HTML spec). I was under the impression the 'Accept:' header is a list of media types, so why would that be making filesystem calls? Or does Rails implicitly organize assets in a filesystem structure (something like ~/assets/audio or ~/assets/text)?

tptacek 8y ago
Because the media types are parsed and used to select layout templates (layout.html.erb vs layout.xml.erb, etc).
- anitil 8y ago
  Aaaah Thankyou!
- Something1234 8y ago
  So why wouldn't we just have a mapping between mime-types and extensions for look ups? Why bother examining the accept header beyond splitting and searching within the list? Like in such a way that we're opening arbitrary files with it?
  - tptacek 8y ago
    That's essentially what the patch does; the "symbol" call only resolves for known-good mime types.
    - Something1234 8y ago
      Where would this code be in the rails code base? I usually don't touch ruby. I'm mildly curious what was there originally.
      - tptacek 8y ago
        In the template resolver in ActionView. It's spread over multiple files and a bit hard to follow, which no doubt contributed to the problem.
        lostapathy 8y ago
        Unfortunately a lot of rails internals are like this :(.
archgoon 8y ago
The technical analysis (from the article), complete with a step by step trace walkthrough, is here: https://chybeta.github.io/2019/03/16/Analysis-for%E3%80%90CVE-2019-5418%E3%80%91File-Content-Disclosure-on-Rails/ https://chybeta.github.io/2019/03/16/Analysis-for%E3%80%90CV... Also, if interested, direct link to patch fix: https://github.com/rails/rails/commit/f4c70c2222180b8d9d924f00af0c7fd632e26715 https://github.com/rails/rails/commit/f4c70c2222180b8d9d924f...
- anitil 8y ago
  Thanks for that, I was missing the step that assets are named $filename.$mime-type.erb in Rails. I was missing the high-level view

by anitil 8y ago

tptacek 8y ago

Because the media types are parsed and used to select layout templates (layout.html.erb vs layout.xml.erb, etc).

anitil 8y ago
Aaaah Thankyou!
Something1234 8y ago
So why wouldn't we just have a mapping between mime-types and extensions for look ups? Why bother examining the accept header beyond splitting and searching within the list? Like in such a way that we're opening arbitrary files with it?
- tptacek 8y ago
  That's essentially what the patch does; the "symbol" call only resolves for known-good mime types.
  - Something1234 8y ago
    Where would this code be in the rails code base? I usually don't touch ruby. I'm mildly curious what was there originally.
    - tptacek 8y ago
      In the template resolver in ActionView. It's spread over multiple files and a bit hard to follow, which no doubt contributed to the problem.
      - lostapathy 8y ago
        Unfortunately a lot of rails internals are like this :(.

archgoon 8y ago

The technical analysis (from the article), complete with a step by step trace walkthrough, is here: https://chybeta.github.io/2019/03/16/Analysis-for%E3%80%90CVE-2019-5418%E3%80%91File-Content-Disclosure-on-Rails/ https://chybeta.github.io/2019/03/16/Analysis-for%E3%80%90CV... Also, if interested, direct link to patch fix: https://github.com/rails/rails/commit/f4c70c2222180b8d9d924f00af0c7fd632e26715 https://github.com/rails/rails/commit/f4c70c2222180b8d9d924f...

anitil 8y ago
Thanks for that, I was missing the step that assets are named $filename.$mime-type.erb in Rails. I was missing the high-level view