Re: CVE-2024-28085: Escape sequence injection in util-linux wall

["Alexander E. Patrakov" <patrakov () gmail com>]

On Thu, Mar 28, 2024 at 7:04 AM Demi Marie Obenour
<demi () invisiblethingslab com> wrote:
> On Wed, Mar 27, 2024 at 10:30:41PM +0100, Jakub Wilk wrote:
> > While looking through upstream git for a fix for this¹, I stumbled upon
> > another write(1)/wall(1) control character injection vulnerability,
> > introduced last year in util-linux v2.39.
> >
> > The offending commits are:
> >
> > * https://github.com/util-linux/util-linux/commit/8a7b8456d1dc0e7c
> >   ("write: correctly handle wide characters")
> > * https://github.com/util-linux/util-linux/commit/aa13246a1bf1be9e
> >   ("wall: use fputs_careful()")
> >
> > The added comment says:
> >
> > > The locale of the recipient is nominally unknown,
> > > but it's a solid bet that the encoding is compatible with the author's.
> >
> > Alas the bet is not that solid when writer's locale encoding is controlled
> > by an attacker.
> >
> > We can exploit this against terminal emulators that recognize C1 control
> > characters, such as Linux VTs or screen(1):
> >
> >    $ printf '\302\23331mMOO\302\2330m\n' | LC_ALL=kk_KZ wall
> >
> > I don't see any good way to fix this on the util-linux's side. It should be
> > fixed on the terminal emulators' side by disabling C1 support.
> >
> >
> > ¹ https://github.com/util-linux/util-linux/commit/404b0781f52f7c04
> >   ("wall: fix escape sequence Injection [CVE-2024-28085]")
>
> Would enforcing UTF-8 validity (regardless of user locale) be a
> solution?

No, as UTF-8 validation does not make sense in non-UTF-8 locales.
Enforcing ASCII for non-UTF-8 locales and UTF-8 for UTF-8 locales
would help.

-- 
Alexander E. Patrakov