[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 28 Mar 2024 00:29:35 +0100
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Karel Zak <kzak@...hat.com>,
"Skyler Ferrante (RIT Student)" <sjf5462@....edu>
Subject: Re: CVE-2024-28085: Escape sequence injection in util-linux wall
Hi,
CC's added for upstream and reporter of the original issue, neither of
whom appears subscribed.
On Wed, Mar 27, 2024 at 07:00:02PM -0400, Demi Marie Obenour 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?
Not a complete solution. I'm currently not aware of a safe way to allow
multi-byte characters coming from concurrent writers, see:
https://www.openwall.com/lists/oss-security/2015/09/20/1
and the next message in that thread.
In fact, even plain ASCII isn't entirely safe if it just happens to be
injected into the middle of a control sequence that the target user's
program was printing, thereby altering its effect.
That said, perhaps write(1)/wall(1) just shouldn't allow bytes from both
C0 and C1 ranges (except for TAB, LF, space) regardless of locale
settings, at least when the programs are running SUID/SGID. That is,
unless the invoking user - which in this case is likely root - could
have directly written to the target user's tty anyway. In other words,
mostly revert those offending commits. Or just revert them completely.
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
