Dancer 1.3400 released to CPAN - security fix, bugfixes and minor improvements
Hi all, I'm pleased to say Dancer 1.3400 has just been released to CPAN. it contains one security-related improvement, several bugfixes, and a couple of minor enhancements. Nothing groundbreaking, but the security update is worth updating for if you use a session engine where the session ID from the client is used in a way where injection is possible. One thing to be aware of is the changes to how request->body gets you the raw request. In the past, we used to keep a copy of the request body in RAM, which could of course be very inefficient for huge requests. In PR #1134, I stopped us doing so, replacing request->body with a convenience method which would read & return the body from the temp file that HTTP::Body writes it to, so if you need the raw body, you can still get it, but otherwise don't have the RAM overhead. *However*, that led to confusion, because HTTP::Body only keeps the raw request body in a temp file for certain types of request. So, now, we have a new setting, raw_request_body_in_ram, which controls the original "keep a copy of the request body as we parse it" behaviour. If it's true, then a copy is kept, you suffer the memory hit, but request->body will always return you the raw request body. If you don't need access to it, though, set that setting to false and enjoy lower memory usage. For more details see https://github.com/PerlDancer/Dancer/pull/1178 Summary of changes: [SECURITY] - Validate session IDs read from client - GH #1172 - potential security risk if the session provider in use passes the session ID in a way where injection is possible. [BUGFIXES] - Avoid accidental route matches if a previous successful match had left %+ populated (GH 1187, PR 1188, bigpresh, reported by skington) - Avoid request body truncation in hand-assembled requests in tests (PR 1148, skington) - require MIME::Types 2.17, as 2.16 has some funny ideas, like responding to a ZIP file with 'application/vnd.easykaraoke.cdgdownload' - Fix YAML-related test failures if YAML::XS not installed (GH 1184, PR 1189, bigpresh) - Avoid tests failing when "localhost" doesn't resolve (PR 1142, gbarco) - Avoid test failures due to race condition in selecting a port to listen on by using 127.0.0.10 instead (more of a hacky workaround than a fix, but should help (bigpresh) - Try to use 127.0.0.11 for listen tests, fall back to 127.0.0.1 on systems that don't have 127/8, e.g. FreeBSD (GH 1183, PR 1185, bigpresh) - More temp directory handling fixes (Issue #1147) - Fix YAML session handler under taint mode (chrisjrob) [ENHANCEMENTS] - Let Dancer::Test::dancer_response() handle supplying multiple params with the same name - Issue 1116 (bigpresh) - Add environment var hint to cookbook (PR 1161, castaway) - Make it possible to switch out YAML for YAML::XS for config parsing and serialisation (there was already an attempt at this in place, and it was documented as posisble, but didn't work) (PR 1164, 1nickt) - New test method response_redirect_like (PR 1159, 1nickt) - New config option raw_request_body_in_ram, which controls whether the raw request body is available via request->body or not. See Issue #1140 for the problems the previous approach, of getting it from the temp file that HTTP::Body might (or might not) have written it to. - Better doc for forward_for_address (PR 1146, Relequestual) Cheers Dave P
On Jun 15, 2018, at 4:30 PM, David Precious <davidp@preshweb.co.uk> wrote:
- Validate session IDs read from client - GH #1172 - potential security risk if the session provider in use passes the session ID in a way where injection is possible.
Is there a list of session providers known to do this? I don’t expect it to be complete, but I suspect that, like me, most people will have no way to evaluate whether their session providers are vulnerable. Obviously new systems still based on D1 will go out with this new version. The question is, do we go back and patch all of those already deployed? In our world, that’s not especially easy, so we’re not going to do it if we’re not actually vulnerable.
On Fri, 15 Jun 2018 19:15:39 -0600 Warren Young <warren@etr-usa.com> wrote:
On Jun 15, 2018, at 4:30 PM, David Precious <davidp@preshweb.co.uk> wrote:
- Validate session IDs read from client - GH #1172 - potential security risk if the session provider in use passes the session ID in a way where injection is possible.
Is there a list of session providers known to do this? I don’t expect it to be complete, but I suspect that, like me, most people will have no way to evaluate whether their session providers are vulnerable.
OTTOMH, I believe it was Memcached-powered ones. There was also a mention of Storable-powered sessions, because loading Storable data from untrusted sources can be dangerous - but the Storable data loaded is the session file which was written by the application, the session ID passed through should not reach Storable, so I'm not entirely sure there, I'd like to have seen a PoC. Cheers Dave P --
participants (2)
-
David Precious -
Warren Young