Information disclosure vulnerability in version 0.8.5 and earlier

[keksa]

There is a chroot option, which should prevent dompdf from accessing files outside of configured root. However this option affects only the check for initial load of HTML in the "loadHtmlFile" method.

I can use the file protocol to load images (and stylesheets) outside of configured root without problems. For example <img src="file:///usr/lib/node_modules/npm/node_modules/qrcode-terminal/example/basic.png"> will load and display the image in generated PDF even though chroot is set to /usr/src/myapp/vendor/dompdf/dompdf.

This is a problem for us, because we allow (authenticated) users to configure their own PDF templates (for example for invoices). Meaning if someone inputs an image with a file protocol URL, they can access images that don't belong to them.

[bsweeney]

We'll review the information you provided and get back to you.

[keksa]

Hey @bsweeney, is there any update with this? 🙂

[bsweeney]

Not yet but we are looking at it for the next release. Life is ... hectic ... right now.

[bsweeney]

The parsing logic has been updated with extra security. The adapter class and the bundled CPDF library are excluded because the parsing logic intermediates calls to those classes. A user should only have access to the CPDF class/adapter if they can execute PHP directly, in which case the extra security we've added is pointless.

[bsweeney]

@keksa thanks for bringing this issue to our attention. I have a few more things to look at related to resource handling, but the changes currently posted in PR #2215 should address your concerns. If you have time please take a look.

I'll update this ticket with details on the issue once the 0.8.6 release is ready.

[keksa]

@bsweeney I can confirm this fixes the issue with our usecase, thank you.

[peter-gribanov]

This is a serious problem, but why did you break backward compatibility? You've broken a lot of your clients' code. Why was it impossible to add deprecation warnings and break backward compatibility at least in the minor version?
Please do not break backward compatibility in the patch anymore.

[bsweeney]

@peter-gribanov this has been brought up elsewhere. This was an oversight on my part and I apologize. We will try to do better in the future.

[stollr]

@bsweeney I have extended the documentation so that it is easier for users to spot their issues with this restriction: https://github.com/dompdf/dompdf/wiki/Usage#security-restrictions-for-local-files

I hope this will help.

[bsweeney]

Thanks for that @Naitsirch! I'm still hoping to build out a bit more documentation around the issue and any help is appreciated.

[stollr]

Three further things may help:

1. Add the chroot option setting to the first usage example in the wiki. This will teach the users to specify that setting as soon as they start using dompdf.
2. Add the method to the method summary.
3. Search for code snippets in stackoverflow.com and add the chroot option setting.