<div dir="ltr"><div dir="ltr"><p>Hi Colin,</p><p>Thank you again for the detailed guidance.</p><p>I took up your suggestion and prepared a revised patch that avoids string <code dir="ltr">eval</code> for the dynamic debconf plugin-loading paths instead of only validating immediately before the eval.</p><p>The patch introduces a small reusable <code dir="ltr">Debconf::Plugin</code> helper. It validates the original plugin name before converting it into a module path, then loads the resulting <code dir="ltr">.pm</code> file with <code dir="ltr">require</code>. I intentionally validate the original name rather than only the constructed path, since validating the path alone would still allow names containing <code dir="ltr">/</code> to become valid path segments after <code dir="ltr">catfile</code>.</p><p>The patch currently covers the original Format/DbDriver paths as well as the related frontend-loading paths you mentioned:</p><ul><li><code dir="ltr">Debconf::Db</code></li><li><code dir="ltr">Debconf::DbDriver::{File,Directory,Pipe}</code></li><li><code dir="ltr">Debconf::AutoSelect::make_frontend</code></li><li><code dir="ltr">Debconf::FrontEnd::_loadelementclass</code></li></ul><p>I also adjusted the helper contract so that <code dir="ltr">Debconf::Plugin::load</code> consistently throws on both validation and <code dir="ltr">require</code> failures. This preserves the normal caller idiom:</p><pre dir="ltr"><code dir="ltr">eval { Debconf::Plugin::load(...) };</code></pre><p>and keeps <code dir="ltr">$@</code> visible to existing warning/error paths.</p><p>Tests added:</p><ul><li>valid plugin/module names are accepted;</li><li>invalid names with path traversal, slashes, dots, spaces, and metacharacters are rejected;</li><li>malformed Format/DbDriver names do not execute constructed Perl code;</li><li>the existing <code dir="ltr">$@</code> behavior through caller-side <code dir="ltr">eval</code> is preserved.</li></ul><p>Validation performed:</p><ul><li><code dir="ltr">git apply --check</code> against pristine upstream: OK</li><li><code dir="ltr">perl -c</code> on modified files: OK</li><li><code dir="ltr">prove -lr t</code>: 98 tests passing</li><li>trailing whitespace check: clean</li></ul><p>Patch attached:</p><p><code dir="ltr">0001-debconf-avoid-string-eval-when-loading-plugin-module.patch</code></p><p>Please let me know if you would prefer a different module name/location for the helper or a narrower first patch covering only the Format/DbDriver paths.</p><p>Best regards,<br>Jeremy</p></div><br><img width="0" height="0" class="mailtrack-img" alt="" style="display:flex" src="https://mailtrack.io/trace/mail/9f272531231ee9519fb6155ffcc9caffadb6f673.png?u=13483695"><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">El dom, 10 may 2026 a las 14:37, Colin Watson (<<a href="mailto:cjwatson@debian.org">cjwatson@debian.org</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Control: tag -1 - security<br>
<br>
[Please drop team@security from CCs in replies, for the reasons given <br>
below.]<br>
<br>
On Sat, May 09, 2026 at 12:16:30PM -0500, Sebastian EM wrote:<br>
>Package: debconf<br>
>Version: 1.5.92<br>
>Severity: important<br>
>Tags: security patch<br>
>X-Debbugs-Cc: <a href="mailto:team@security.debian.org" target="_blank">team@security.debian.org</a>,<br>
><a href="mailto:debconf-devel@lists.alioth.debian.org" target="_blank">debconf-devel@lists.alioth.debian.org</a><br>
><br>
>Dear debconf maintainers,<br>
><br>
>I would like to report an input-validation issue in debconf 1.5.92,<br>
>confirmed at runtime in a fresh debian:sid container.<br>
><br>
>Several debconf database driver initialization paths interpolate<br>
>attacker-influenced format or driver names into Perl eval STRING:<br>
<br>
In general, debconf doesn't attempt to implement any kind of security <br>
boundary, and an unprivileged user being able to control DEBCONF_* <br>
environment variables would already be a significant problem on its own: <br>
they would be able to substitute their own answers to debconf questions <br>
asked by packages, which could have arbitrarily complex consequences. <br>
Any arrangements that allow users to run debconf in privileged contexts <br>
_must_ forbid them from setting those environment variables.<br>
<br>
Therefore, I'm not inclined to treat poor validation of those <br>
environment variables, which already must not be allowed to be set at <br>
all by unprivileged users, as a security problem. I'm happy to treat it <br>
as a quality-of-implementation problem, though.<br>
<br>
>The patch touches:<br>
><br>
> Debconf/DbDriver/File.pm<br>
> Debconf/DbDriver/Directory.pm<br>
> Debconf/DbDriver/Pipe.pm<br>
> Debconf/Db.pm<br>
<br>
I'd like to see if we can avoid the string eval entirely. All other <br>
things being equal, it's usually better to avoid the need for validation <br>
in the first place; this is analogous to the well-known reasons that <br>
it's better to avoid system()-style interfaces (where one has to <br>
sanitize shell metacharacters first) in favour of things with an <br>
execve()-style interface.<br>
<br>
So, how about using this sort of construct (which I've tested lightly at <br>
an interactive prompt, but not in any detail) instead of string eval?<br>
<br>
use File::Spec;<br>
<br>
my @parts = split /::/, $this->{format};<br>
my $module = File::Spec->catfile('Debconf', 'Format', $this->{format});<br>
eval { require "$<a href="http://module.pm" rel="noreferrer" target="_blank">module.pm</a>"; };<br>
<br>
Of course, that has a path traversal vulnerability: you could supply a <br>
format beginning with "../../" and then load whatever module you like. <br>
(Or add further "../" and potentially get anything on the system, <br>
although this would be hard to do much with since you'd need something <br>
with the ".pm" suffix.) So that becomes something like:<br>
<br>
use File::Spec;<br>
<br>
my @parts = split /::/, $this->{format};<br>
my $module = File::Spec->catfile('Debconf', 'Format', $this->{format});<br>
if ($module !~ m{\A[A-Za-z0-9/_]+\Z}) {<br>
$this->error("Invalid plugin name: $this->{format}");<br>
return;<br>
}<br>
eval { require "$<a href="http://module.pm" rel="noreferrer" target="_blank">module.pm</a>"; };<br>
<br>
Now, that's taken us right back to doing up-front validation, which I <br>
just said I wanted to avoid! Still, I think it's worth avoiding string <br>
eval on general principles anyway, so maybe this is worth the effort.<br>
<br>
This is enough code that it would definitely need to go into a utility <br>
module somewhere. There's no very obvious existing module that would <br>
suit, but if the code were generalized a little bit then it could go <br>
into a new Debconf::Plugin module. As well as the code your patch <br>
already touches, this could potentially be used in <br>
Debconf::AutoSelect::make_frontend and <br>
Debconf::FrontEnd::_loadelementclass.<br>
<br>
What do you think? If this is too much refactoring then I'm happy to do <br>
it, but I thought I'd give you the opportunity.<br>
<br>
Thanks,<br>
<br>
-- <br>
Colin Watson (he/him) [<a href="mailto:cjwatson@debian.org" target="_blank">cjwatson@debian.org</a>]<br>
</blockquote></div></div>