Re: Addressing Mojolicious CVE-2024-58134 and CVE-2024-58135 in sid

[Marc SCHAEFER <schaefer@alphanet.ch>]

Hello,

On Thu, May 22, 2025 at 10:49:56AM +0100, Sean Whitton wrote:
> It seems that Mojolicious upstream take the view that application
> authors are responsible for configuring a secure session secret and so
> the fact these the defaults are not cryptographically secure is not
> something to fix upstream.[1]  Therefore, we probably can't expect a fix
> for CVE-2024-58134 to arrive upstream.

It has to be noted that if you do not set a secret and use the signed cookie,
Mojolicious has always displayed a warning, for example that code:

#! /usr/bin/env perl

use Mojolicious::Lite -signatures;

get '/' => sub ($c) {
   $c->render(text => 'Hello World!');

   $c->flash('yep' => 'ok');
};

app->start;

   [2025-05-22 12:34:42.72129] [67465] [trace] Your secret passphrase needs to be changed (see FAQ for more)

And the FAQ says for years now (so many years that actually the default
passphrase is not what is documented there):

   https://docs.mojolicious.org/Mojolicious/Guides/FAQ#What-does-Your-secret-passphrase-needs-to-be-changed-mean

Also, it was pretty clear that that secret was used to sign cookies, which is
the way Mojolicious authenticates sessions (there is NO context on the server
side), and thus must be chosen securely.

> What do you think should happen in Debian?  It seems like we could patch
> in secure key generation without too much difficulty.  What do you think
> about doing that?

Security research has indeed shown that

   1) sometimes people deploy production applications without setting the
      secret, which makes it often easy to guess the actually used secret

   2) sometimes people use easy-to-guess secrets (that can be
      brute-forced with a dictionnary approach similar to
      /etc/shadow with john or crack, or even using GPUs to
      try a lot of not long enough passwords)

Should Debian add distribution-specific code that fixes 1), or even that
breaks the ability to set a weak secret to fix 2) above ?

I know that Debian has the possibility to document "wontfix" (or similar) in
the security-tracker.  Something that could be useful would be to, every now
and then, create a security advisory that lists those recent "wontfix" and the
rationale behind them?   That would be an interesting reminder to look at the
security tracker?

Have a nice day.