ruby-actionpack-page-caching / CVE-2020-8159

[Brian May <bam@debian.org>]

After reading the notes for this project:

ruby-actionpack-page-caching (Brian May)                                         
  NOTE: 20200819: Upstream's patch on does not apply due to subsequent           
  NOTE: 20200819: refactoring. However, a quick look at the private              
  NOTE: 20200819: page_cache_file method suggests that the issue exists, as it   
  NOTE: 20200819: uses the path without normalising any "../" etc., simply       
  NOTE: 20200819: URI.parser.unescap-ing it. Requires more investigation. (lamby)

It seems like the best thing is to run the test case first.

But had lots of problems getting "get" to call the custom URL that is
defined in the test.

The code in stretch uses:

with_routing do |set|

But apparently this is not sufficient for the "get" function to work.

https://stackoverflow.com/questions/27068995/with-routing-test-helper-doesnt-work-for-integration-tests

So I ended up copying the test file from the sid/bullseye file and using
it. And ignoring the other tests failing (I imagine these might be easy
to fix). For the test in question, I still ended up with the get command
unable to find the route.

In desperation, I changed the line:

get :ok, params: { id: "#{get_to_root}../pwnd" }

To:

get :ok, id: "#{get_to_root}../pwnd"

Now I get the test failure:

  5) Failure:
PageCachingTest#test_cache_does_not_escape [/tmp/brian/tmpzof0zyk7/build/amd64/source/test/caching_test.rb:198]:
Expected ["/tmp/brian/tmpzof0zyk7/build/amd64/source/test/pwnd.html",
"/tmp/brian/tmpzof0zyk7/build/amd64/source/test/pwnd.html.gz"] to be
empty?.

Which seems to indicate that the code is vulnerable, and that my id
passing is working correctly.

I added also added the following line, just before the assert that fails:

Find.find(File.join(project_root, "test")) { |e| puts e }

Which lists the files as:

/tmp/brian/tmpx4w5mn7g/build/amd64/source/test
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/abstract_unit.rb
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/caching_test.rb
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/log_subscriber_test.rb
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/pwnd.html
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/pwnd.html.gz
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/tmp
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/tmp/test_cache
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/tmp/test_cache/page_caching_test
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/tmp/test_cache/page_caching_test/ok

Which I think is a definite fail.

But sometimes the test passes and these files don't exist. So I can't
help but wonder if there is some weird race condition here. For example
on one test run I got these files instead:

/tmp/brian/tmptvp61kg5/build/amd64/source/test
/tmp/brian/tmptvp61kg5/build/amd64/source/test/abstract_unit.rb
/tmp/brian/tmptvp61kg5/build/amd64/source/test/caching_test.rb
/tmp/brian/tmptvp61kg5/build/amd64/source/test/log_subscriber_test.rb
/tmp/brian/tmptvp61kg5/build/amd64/source/test/tmp
/tmp/brian/tmptvp61kg5/build/amd64/source/test/tmp/test_cache

Which is fine. Will continue investigating at a later date when I am
more awake.
-- 
Brian May <bam@debian.org>