Broken captcha requires ImageMagick configuration

[moneytoo]

I followed the installation guide and installed diaspora on CentOS 7. The only issue is ImageMagick related one:

[2016-05-11T23:42:47] INFO  PID-20323 TID-3527460 Rails: Started GET "/users/sign_up" for 85.50.100.200 at 2016-05-11 23:42:47 +0200
[2016-05-11T23:42:47] INFO  PID-20323 TID-3527460 ActionController::Base: Processing by RegistrationsController#new as HTML
  Rendered simple_captcha/_simple_captcha.haml (10.9ms)
  Rendered registrations/_form.haml (426.0ms)
  Rendered registrations/new.haml within layouts/with_header (443.0ms)
  Rendered layouts/_header.html.haml (145.0ms)
  Rendered layouts/_open_graph.haml (245.7ms)
  Rendered layouts/application.html.haml (710.9ms)
[2016-05-11T23:42:48] INFO  PID-20323 TID-3527460 ActionController::Base: Completed 200 OK in 1403ms (Views: 1314.1ms | ActiveRecord: 32.8ms)
[2016-05-11T23:42:49] INFO  PID-20323 TID-3527460 Rails: Started GET "/simple_captcha?code=108cb4e548dcf9d02fe1efa1326143208e715afc&time=1463002967" for 85.50.100.200 at 2016-05-11 23:42:49 +0200
[2016-05-11T23:43:28] INFO  PID-20321 TID-3527460 Rails: Started GET "/users/sign_up" for 85.50.100.200 at 2016-05-11 23:43:28 +0200
[2016-05-11T23:43:28] INFO  PID-20321 TID-3527460 ActionController::Base: Processing by RegistrationsController#new as HTML
  Rendered simple_captcha/_simple_captcha.haml (0.2ms)
  Rendered registrations/_form.haml (26.3ms)
  Rendered registrations/new.haml within layouts/with_header (27.6ms)
  Rendered layouts/_header.html.haml (2.8ms)
  Rendered layouts/_open_graph.haml (4.0ms)
  Rendered layouts/application.html.haml (33.9ms)
[2016-05-11T23:43:29] INFO  PID-20321 TID-3527460 ActionController::Base: Completed 200 OK in 74ms (Views: 64.6ms | ActiveRecord: 1.4ms)
[2016-05-11T23:43:29] INFO  PID-20323 TID-3527460 Rails: Started GET "/simple_captcha?code=b833e64b465867571b3c4bda2c6af5108b6cabf9&time=1463003008" for 85.50.100.200 at 2016-05-11 23:43:29 +0200
[2016-05-11T23:43:29] FATAL PID-20323 TID-3527460 Rails: 
StandardError (Error while running convert: convert: not authorized `33627' @ error/constitute.c/ReadImage/454.
convert: no images defined `jpeg:-' @ error/convert.c/ConvertImageCommand/3046.
):
  lib/rack/internet_explorer_version.rb:34:in `call'
  lib/unicorn_killer.rb:35:in `call'

The default ImageMagick policy (in /etc/ImageMagick/policy.xml) prevents generating captcha. Removing all the rules makes everything work again.

I'm not sure if the current policy.xml contains some extra rules because of the latest exploits or if these are permanent but maybe someone can shed some more light on this and something also could be mentioned on the wiki page.

[denschub]

Please share your policy.xml with us...

[moneytoo]

This is the default policy:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policymap [
<!ELEMENT policymap (policy)+>
<!ELEMENT policy (#PCDATA)>
<!ATTLIST policy domain (delegate|coder|filter|path|resource) #IMPLIED>
<!ATTLIST policy name CDATA #IMPLIED>
<!ATTLIST policy rights CDATA #IMPLIED>
<!ATTLIST policy pattern CDATA #IMPLIED>
<!ATTLIST policy value CDATA #IMPLIED>
]>
<!--
  Configure ImageMagick policies.

  Domains include system, delegate, coder, filter, path, or resource.

  Rights include none, read, write, and execute.  Use | to combine them,
  for example: "read | write" to permit read from, or write to, a path.

  Use a glob expression as a pattern.

  Suppose we do not want users to process MPEG video images:

    <policy domain="delegate" rights="none" pattern="mpeg:decode" />

  Here we do not want users reading images from HTTP:

    <policy domain="coder" rights="none" pattern="HTTP" />

  Lets prevent users from executing any image filters:

    <policy domain="filter" rights="none" pattern="*" />

  The /repository file system is restricted to read only.  We use a glob
  expression to match all paths that start with /repository:

    <policy domain="path" rights="read" pattern="/repository/*" />

  Let's prevent possible exploits by removing the right to use indirect reads.

    <policy domain="path" rights="none" pattern="@*" />

  Any large image is cached to disk rather than memory:

    <policy domain="resource" name="area" value="1GB"/>

  Define arguments for the memory, map, area, and disk resources with
  SI prefixes (.e.g 100MB).  In addition, resource policies are maximums for
  each instance of ImageMagick (e.g. policy memory limit 1GB, -limit 2GB
  exceeds policy maximum so memory limit is 1GB).
-->
<policymap>
  <!-- <policy domain="system" name="precision" value="6"/> -->
  <!-- <policy domain="resource" name="temporary-path" value="/tmp"/> -->
  <!-- <policy domain="resource" name="memory" value="2GiB"/> -->
  <!-- <policy domain="resource" name="map" value="4GiB"/> -->
  <!-- <policy domain="resource" name="area" value="1GB"/> -->
  <!-- <policy domain="resource" name="disk" value="16EB"/> -->
  <!-- <policy domain="resource" name="file" value="768"/> -->
  <!-- <policy domain="resource" name="thread" value="4"/> -->
  <!-- <policy domain="resource" name="throttle" value="0"/> -->
  <!-- <policy domain="resource" name="time" value="3600"/> -->
  <policy domain="coder" rights="none" pattern="EPHEMERAL" />
  <policy domain="coder" rights="none" pattern="HTTPS" />
  <policy domain="coder" rights="none" pattern="HTTP" />
  <policy domain="coder" rights="none" pattern="URL" />
  <policy domain="coder" rights="none" pattern="FTP" />
  <policy domain="coder" rights="none" pattern="MVG" />
  <policy domain="coder" rights="none" pattern="MSL" />
  <policy domain="coder" rights="none" pattern="TEXT" />
  <policy domain="coder" rights="none" pattern="LABEL" />
  <policy domain="path" rights="none" pattern="@*" />
</policymap>

The captcha breaking rule seems to be this one <policy domain="coder" rights="none" pattern="LABEL" />.

[piraz]

The policy is there because of ImageMagick CVE-2016–3714. The info is in this site.

My captcha image is not being generated right after a system update from last week.

I'll solve this issue and post here. I was wondering why users were not registering on the pod.

[piraz]

Here is ImageMagick anouncement: https://www.imagemagick.org/discourse-server/viewtopic.php?f=4&t=29588.

[piraz]

So the policy blocking everything is LABEL. I'm commenting that on my pods right now.

It seems like if you give read and right for the JPEG codec and read to http then the PNG will fail and JPEG will run, as I don't like the first error working, I'm going with this configuration:

<policymap>
  <!-- <policy domain="system" name="precision" value="6"/> -->
  <!-- <policy domain="resource" name="temporary-path" value="/tmp"/> -->
  <!-- <policy domain="resource" name="memory" value="2GiB"/> -->
  <!-- <policy domain="resource" name="map" value="4GiB"/> -->
  <!-- <policy domain="resource" name="area" value="1GB"/> -->
  <!-- <policy domain="resource" name="disk" value="16EB"/> -->
  <!-- <policy domain="resource" name="file" value="768"/> -->
  <!-- <policy domain="resource" name="thread" value="4"/> -->
  <!-- <policy domain="resource" name="throttle" value="0"/> -->
  <!-- <policy domain="resource" name="time" value="3600"/> -->
  <policy domain="coder" rights="none" pattern="EPHEMERAL" />
  <policy domain="coder" rights="read" pattern="HTTPS" />
  <policy domain="coder" rights="none" pattern="HTTP" />
  <policy domain="coder" rights="none" pattern="URL" />
  <policy domain="coder" rights="none" pattern="FTP" />
  <policy domain="coder" rights="none" pattern="MVG" />
  <policy domain="coder" rights="none" pattern="MSL" />
  <policy domain="coder" rights="none" pattern="TEXT" />
  <!--policy domain="coder" rights="read | write" pattern="LABEL" /-->
  <policy domain="path" rights="none" pattern="@*" />
  <policy domain="coder" rights="read | write" pattern="JPEG" />
  <policy domain="coder" rights="read | write" pattern="PNG" />
</policymap>

I don't know how secure is that configuration but I think this is a temporary solution. Maybe we can check a way to apply the policy to a certain directory or context.

I'll put more investigation on that.

[piraz]

By the way this ImageMagick Is On Fire — CVE-2016–3714 is not a trivial issue, maybe we should alert the podmin community.

Let me just add this link here. There are lots of helpful commands.

[us3r1d]

This is still a problem on a fresh install on CentOS 7.

The ImageMagik policy.xml change suggested above did not work for me.

[mdsystems]

Same here. I have just tried the above and I still have a broken captcha. If someone more knowledgeable could point me in the right direction, I may be able to look into replacing how the captcha is generated, or constructing a working policy. At present, no one can sign up on my pod.

[denschub]

@SuperTux88 we should likely pin simple_captcha2 to a tagged git revision upstream. I'm almost certain most issues would be fixed with https://github.com/pludoni/simple-captcha/commit/00143b8c2fb44ce00b3ca12e5236a3d641262579, but that has not yet seen a release. Thoughts?

[jhass]

Well, looks like they forgot to push the gem? https://github.com/pludoni/simple-captcha/commit/00cd0f349348e51d0eddca2fec5bc117ccbbbbf0

[denschub]

Well, the previous version got yanked and never re-released. But hey, we can try..! https://github.com/pludoni/simple-captcha/issues/66

[mdsystems]

Is this a case of waiting until the updated version is pushed to RubyGems, or could this be done manually on my Diaspora instance?

[denschub]

Well, you could manually patch your Gemfile,

-gem "simple_captcha2", "0.4.3", require: "simple_captcha"
+gem "simple_captcha2", git: "https://github.com/pludoni/simple-captcha.git", require: "simple_captcha"

and run bundle update simple_captcha2, but I wouldn't really recommend it, as we have no idea if this works or not. If you decide to go that route, please proceed on your own risk!

One alternative would be to disable public registrations, disable the captcha, and place a note on the registration form with your email address, asking people to send you a short mail if you want to sign up. You could reply with an invitation link, which will work even if public signups are disabled, and if you have disabled captchas, they would be able to sign up.

[mdsystems]

Thanks for the suggestion. I'll take the invitation link approach for the time being.

[mdsystems]

I have a workaround for this problem, specifically on CentOS 7. If you examine what is generated by the simple captcha, the chances are it may contain error output from Imagick. In my case, it was missing fonts. If the fonts are installed in the appropriate location, the captcha works again. This is with all of the Imagick policies in place as per the default.